Cybersecurity

Cybersecurity / 22 Sep 2026 / 6 min read

CAA Records Constrain Certificate Authority Issuance

CAA Records Constrain Certificate Authority Issuance A certificate authority can validate control of a domain and still face a separate policy question: is this CA authorized by the domain operator to issue for that name? Certification Authority Authorization, or CAA, gives the DNS namespace a record type for expressing that constraint. CAA operates before certificate issuance. A participating public CA checks the relevant DNS CAA policy and evaluates whether its issuer identity is authorized. The mechanism does not make a certificate trusted, revoke an existing certificate, or tell a browser to reject a certificate after issuance. It narrows the set of issuers that should create new certificates for the domain.

Cybersecurity DNS

Cybersecurity / 21 Sep 2026 / 5 min read

WebAuthn RP ID Scopes Credential Use

WebAuthn RP ID Scopes Credential Use A WebAuthn credential is not a reusable key that any website can request from an authenticator. Registration and authentication are tied to a relying party identifier, or RP ID, while the browser also evaluates the calling origin. That pairing creates a domain boundary around public-key credentials. For a conventional deployment at https://login.example.com, an RP can use the host itself as the RP ID: origin: https://login.example.com RP ID: login.example.com It can also use a registrable domain suffix such as example.com when the deployment needs credentials to serve eligible subdomains:

Cybersecurity WebAuthn

Cybersecurity / 21 Sep 2026 / 5 min read

Trusted Types Put DOM Injection Sinks Behind Policies

Trusted Types Put DOM Injection Sinks Behind Policies DOM-based cross-site scripting often appears at the last step of a data flow. A value moves through application code as an ordinary string, then reaches an API that interprets it as HTML, script, or a script URL. The dangerous boundary is not the string alone; it is the moment that string enters an injection sink. Trusted Types changes that boundary. In supporting browsers, an application can require covered sinks to receive objects such as TrustedHTML, TrustedScript, or TrustedScriptURL instead of raw strings. Those objects are created through policies defined by the application.

Cybersecurity Web Security

Cybersecurity / 21 Sep 2026 / 6 min read

TLS Must-Staple Turns OCSP Stapling into Certificate Policy

TLS Must-Staple Turns OCSP Stapling into Certificate Policy OCSP stapling lets a TLS server deliver certificate-status evidence inside the handshake instead of making each client contact the certificate authority’s OCSP responder. That arrangement reduces an extra network dependency for the client, but ordinary stapling is optional: the absence of a stapled response does not, by itself, prove that the certificate is invalid. The X.509 TLS Feature extension changes that condition when it advertises status_request. Commonly called Must-Staple in this use, the certificate states that the server is expected to provide the corresponding TLS feature. A client that both requests the feature and enforces the certificate extension can reject a connection when the required status response is missing.

Cybersecurity TLS

Cybersecurity / 21 Sep 2026 / 5 min read

TLS Delegated Credentials Limit Front-End Key Exposure

TLS Delegated Credentials Limit Front-End Key Exposure A large TLS deployment often terminates connections on machines far from the system that manages its certificate private key. Copying that long-lived key to every front end simplifies handshakes, but it also enlarges the set of systems whose compromise can expose the certificate key. RFC 9345 defines delegated credentials for TLS and DTLS 1.3. A certificate holder can sign a separate, short-lived credential containing another public key. A compatible endpoint then uses the delegated credential and its private key for handshake authentication while the certificate private key can remain in a more restricted environment.

Cybersecurity TLS 1.3

Cybersecurity / 21 Sep 2026 / 5 min read

The __Host- Cookie Prefix Narrows Session Cookie Scope

The __Host- Cookie Prefix Narrows Session Cookie Scope A session cookie can carry a strong random identifier and still have an unnecessarily broad scope. The Domain attribute can make a cookie available across subdomains, while a path-specific cookie can coexist with another cookie of the same name. Those details matter when several applications share a registrable domain but do not share the same security boundary. The __Host- cookie-name prefix gives supporting user agents a compact rule set for a stricter cookie. A cookie whose name begins with __Host- must be set from a secure origin with Secure, must use Path=/, and must omit Domain. A user agent that implements the prefix rejects a prefixed cookie that violates those constraints.

Cybersecurity HTTP

Cybersecurity / 21 Sep 2026 / 5 min read

Subresource Integrity Pins External Assets to Expected Content

Subresource Integrity Pins External Assets to Expected Content A page that loads JavaScript or CSS from another host gives that host a direct path into the page’s execution or presentation context. HTTPS protects the transfer against network tampering, but it does not tell the browser whether the server returned the exact asset the application intended to use. Subresource Integrity (SRI) adds a content check. The document carries cryptographic metadata for a resource. After fetching the bytes, the browser computes the relevant digest and compares it with the metadata before accepting the resource.

Cybersecurity Web Security

Cybersecurity / 21 Sep 2026 / 6 min read

SSH Host Key Verification Binds Connections to Server Identity

SSH Host Key Verification Binds Connections to Server Identity SSH encrypts a connection, but encryption alone does not establish that the endpoint is the intended server. During key exchange, the server proves possession of a host private key. The client then has to decide whether the corresponding public identity is trusted for that host. That decision is the host-authentication boundary. If a client accepts an attacker’s host key without a valid trust basis, the resulting channel can still be encrypted while terminating at the wrong machine. Passwords, commands, forwarded agents, and session data can then cross a boundary the operator did not intend.

Cybersecurity SSH

Cybersecurity / 21 Sep 2026 / 6 min read

SSH Certificates Shift Access Trust to a Signing Authority

SSH Certificates Shift Access Trust to a Signing Authority Public-key SSH access often starts with a simple mapping: place a user’s public key in authorized_keys, keep the private key with the user, and let the server accept possession of the matching private key. The model is direct and effective, but its administrative cost rises as people and hosts multiply. Every host can become another place where access state must be added, audited, and removed.

Cybersecurity SSH

Cybersecurity / 21 Sep 2026 / 6 min read

SSH Certificates Bind Identity to Principals and Constraints

SSH Certificates Bind Identity to Principals and Constraints A raw SSH public key answers a narrow question: does the connecting client possess the private key corresponding to this public key? Authorization still needs another mapping. A server commonly places accepted keys in authorized_keys, often with options that restrict what a particular key may do. OpenSSH certificates add a signed identity layer around a public key. A certificate can carry principals, a validity interval, critical options, extensions, a serial number, and a key identifier. A server configured to trust the signing CA can validate that certificate without storing the holder’s raw public key as a separate authorization entry.

Cybersecurity SSH

Cybersecurity / 21 Sep 2026 / 5 min read

SameSite Cookies Constrain Cross-Site Session Sending

SameSite Cookies Constrain Cross-Site Session Sending A session cookie is an ambient credential: once stored, the browser can attach it to matching HTTP requests without application code copying the value into each request. That convenience also creates a security boundary. A request initiated from another site can reach an application while carrying the user’s authenticated session unless cookie policy prevents it. The SameSite attribute gives the browser a rule for deciding whether a cookie may accompany a request in a cross-site context. It does not change the cookie value or authenticate the request by itself. It changes when the browser includes that cookie.

Cybersecurity HTTP

Cybersecurity / 21 Sep 2026 / 4 min read

Permissions Policy Limits Powerful Browser Features

Permissions Policy Limits Powerful Browser Features A web page can contain code from several trust domains while still sharing access to browser capabilities. First-party scripts, third-party widgets, and nested frames may all execute inside one application surface. Browser permission prompts remain important, but an application can narrow the set of documents that are eligible to request or use selected features before a prompt becomes relevant. Permissions Policy provides that boundary. A response header declares which origins may use controlled features in the document and its frame tree. The policy does not grant a user permission. It constrains feature availability within the browser.

Cybersecurity Web Security

Cybersecurity / 21 Sep 2026 / 5 min read

OCSP Stapling Delivers Revocation Status in TLS

OCSP Stapling Delivers Revocation Status in TLS Certificate validation answers more than one question. A client can verify signatures, names, validity periods, and trust anchors, yet a certificate that passes those checks may have been revoked after issuance. Revocation status therefore sits beside normal path validation rather than replacing it. The Online Certificate Status Protocol (OCSP) provides signed status responses for certificates. A client can query an OCSP responder directly, but that adds a third party to connection setup. OCSP stapling moves a suitable response into the TLS exchange: the server obtains the response and presents it to clients that request certificate status.

Cybersecurity TLS

Cybersecurity / 21 Sep 2026 / 6 min read

Mutual TLS Authenticates Both Sides of a Connection

Mutual TLS Authenticates Both Sides of a Connection A conventional HTTPS connection authenticates the server with a certificate while the client usually proves its identity later through an application mechanism such as a session cookie, bearer token, or password. Mutual TLS, commonly shortened to mTLS, adds certificate-based client authentication to the TLS exchange. The result is a transport channel in which each peer can verify a certificate chain and proof of private-key possession from the other side. That changes the authentication boundary, but it does not turn a certificate into an authorization policy. A valid client identity can still be denied access to a resource.

Cybersecurity TLS

Cybersecurity / 21 Sep 2026 / 5 min read

HSTS Pins HTTPS Policy in the Browser

HSTS Pins HTTPS Policy in the Browser An HTTPS redirect does useful work only after an HTTP request reaches the server. That first cleartext request remains a weak point: a network attacker able to alter traffic can interfere before the browser receives the redirect. HTTP Strict Transport Security, or HSTS, moves part of that decision into the browser. After receiving a valid Strict-Transport-Security header over HTTPS, a conforming user agent records a policy for the host. During the policy lifetime, later HTTP navigation to that host is rewritten to HTTPS before an HTTP connection is made.

Cybersecurity HTTPS

Cybersecurity / 21 Sep 2026 / 5 min read

HSTS Enforces HTTPS After a Host Policy Is Known

HSTS Enforces HTTPS After a Host Policy Is Known A redirect from HTTP to HTTPS moves a request onto TLS, but the first HTTP request still exists. If a browser starts with http://example.com, it can contact the HTTP endpoint before it receives the redirect. A network attacker positioned on that path can interfere before the browser reaches TLS. HTTP Strict Transport Security (HSTS), standardized in RFC 6797, changes later navigation behavior. A conforming user agent that receives a valid Strict-Transport-Security response over secure transport records an HTTPS-only policy for the host. While that policy remains active, an HTTP URL for the host is rewritten to HTTPS before an insecure request is sent.

Cybersecurity Web Security

Cybersecurity / 21 Sep 2026 / 5 min read

Fetch Metadata Headers Filter Cross-Site Requests

Fetch Metadata Headers Filter Cross-Site Requests A web server often receives requests that look valid at the HTTP layer even when they originated from an unrelated site. Cookies may accompany those requests, and a state-changing endpoint can be exposed if its defenses treat every browser request as equally trustworthy. Fetch Metadata gives the server additional context. Supporting browsers attach Sec-Fetch-* request headers that describe the relationship between the initiator and target, the request mode, the destination, and whether navigation resulted from direct user activation. A server can use that context as an early resource-isolation gate.

Cybersecurity Web Security

Cybersecurity / 21 Sep 2026 / 7 min read

DNSSEC Validates DNS Data Through Signed Delegations

DNSSEC Validates DNS Data Through Signed Delegations DNS normally answers questions about names and resource records without cryptographic proof that the returned data came from the zone operator. DNS Security Extensions (DNSSEC) add signatures and a delegation chain that a validating resolver can check before treating signed DNS data as authentic. The protection is specific. DNSSEC provides data-origin authentication and integrity for DNS data. It does not encrypt queries or responses, hide queried names, or authenticate the application reached after resolution. A valid signed A record can establish that the record is authentic within the DNSSEC chain; it does not establish that the server at that address is safe.

Cybersecurity DNS

Cybersecurity / 21 Sep 2026 / 6 min read

DNSSEC DS Records Link Parent and Child Trust

DNSSEC DS Records Link Parent and Child Trust DNSSEC signs DNS data, but a signature is useful to a validator only when the signing key can be connected to a trusted starting point. That connection has to cross zone boundaries. A resolver validating data below a delegation cannot treat a child zone’s DNSKEY as authentic merely because the child publishes it. The DS resource record supplies the link. It is authoritative data in the parent zone and identifies DNSKEY material in the delegated child. Once the parent side is authenticated, a matching DS can authenticate the corresponding child key, allowing validation to continue into the child zone.

Cybersecurity DNSSEC

Cybersecurity / 21 Sep 2026 / 5 min read

DNS CAA Narrows Which CAs May Issue Certificates

DNS CAA Narrows Which CAs May Issue Certificates A publicly trusted certificate authority can issue a certificate only after completing the validation required by its policy and the applicable ecosystem rules. DNS Certification Authority Authorization (CAA) adds another control: a domain can publish which CAs are authorized to issue certificates for that DNS namespace. CAA does not replace domain-control validation, certificate transparency, or certificate verification by clients. It constrains issuance at the CA side. A CA processing a request checks the relevant CAA policy before issuance and must not issue when the policy forbids it.

Cybersecurity PKI

Cybersecurity / 21 Sep 2026 / 6 min read

CSP Nonces Bind Inline Scripts to Individual Responses

CSP Nonces Bind Inline Scripts to Individual Responses Inline JavaScript creates an awkward boundary for a strict Content Security Policy. A policy that allows every inline script with 'unsafe-inline' gives injected script blocks the same execution privilege as intended code. A nonce provides a narrower mechanism: the server generates an unpredictable value for one response, places that value in the policy, and attaches it only to script elements that are meant to run.

Cybersecurity Content Security Policy

Cybersecurity / 21 Sep 2026 / 5 min read

CSP frame-ancestors Restricts Page Embedding

CSP frame-ancestors Restricts Page Embedding Clickjacking does not require an attacker to replace the target application’s interface. A hostile page can place the real application inside a transparent or carefully positioned frame, then arrange decoy controls so a user’s click lands on an authenticated action in the framed page. The frame-ancestors directive in Content Security Policy moves the embedding decision to the response being framed. The target declares which ancestors are acceptable. A conforming browser checks the ancestor chain before allowing the protected resource to load in a nested browsing context.

Cybersecurity CSP

Cybersecurity / 21 Sep 2026 / 5 min read

Cross-Origin-Resource-Policy Controls no-cors Embedding

Cross-Origin-Resource-Policy Controls no-cors Embedding Web pages routinely embed resources without granting JavaScript direct access to their response bytes. Images, classic scripts, media, and other subresources can use no-cors request mode, where the browser permits forms of cross-origin loading while keeping the response opaque to script. That default is useful for the web, but a resource owner may need a tighter boundary. Cross-Origin-Resource-Policy (CORP) is an HTTP response header that tells the browser which origins or sites may consume a response through the policy’s no-cors path.

Cybersecurity Web Security

Cybersecurity / 21 Sep 2026 / 6 min read

Cross-Origin-Opener-Policy Separates Window Relationships

Cross-Origin-Opener-Policy Separates Window Relationships A browser window can hold a reference to another top-level window. window.open() returns a WindowProxy, and an opened document may receive a window.opener reference. The same-origin policy restricts what cross-origin windows can inspect, but the relationship itself can still expose useful state and communication surfaces. Cross-Origin-Opener-Policy (COOP) adds a boundary around that relationship. The response header influences whether a top-level document remains in a compatible browsing context group (BCG) or moves into a new one. When policies require separate groups, references between opener and opened document are severed.

Cybersecurity Web Security