Skip to content

Archive

Browser Security

51 articles
Cybersecurity 23 Sep 2026 4 min read

The __Host- Cookie Prefix Constrains Cookie Scope

The __Host- Cookie Prefix Constrains Cookie Scope Cookie security depends on more than the value stored in a cookie. Scope determines which requests can carry it and which responses can attempt to replace it. For a sensitive session cookie, a broad domain rule can give sibling hosts influence that the application did not intend. The __Host- cookie name prefix gives supporting browsers a compact set of scope requirements. A cookie whose name starts with __Host- is accepted only when it is set with Secure, has Path=/, and omits the Domain attribute. The result is a host-only cookie available across paths on that host and restricted to secure transport.

Cybersecurity 23 Sep 2026 6 min read

Subresource Integrity Binds External Assets to Cryptographic Digests

Subresource Integrity Binds External Assets to Cryptographic Digests A web page can load JavaScript and CSS from an origin outside its own deployment boundary. That arrangement is convenient for shared packages and content delivery networks, but it also delegates part of the page’s execution or presentation path to the server that returns those resources. Subresource Integrity (SRI) adds a byte-level constraint to that dependency. The page supplies one or more cryptographic digests in an integrity attribute. A supporting browser fetches the resource, computes a digest with the declared algorithm, and accepts the response only when the bytes satisfy the integrity metadata.

Cybersecurity 23 Sep 2026 6 min read

Origin-Agent-Cluster Separates Origin-Keyed JavaScript Heaps

Origin-Agent-Cluster Separates Origin-Keyed JavaScript Heaps Web origins that share a site can still belong to different security principals. app.example.com and admin.example.com, for example, have distinct origins even though both sit beneath the same registrable domain. Browser process architecture has historically allowed related origins to share an agent cluster in some cases, which can place their JavaScript execution environments closer together than an origin-only model suggests. The Origin-Agent-Cluster response header gives a document a way to request origin-keyed clustering:

Cybersecurity 23 Sep 2026 6 min read

HTTP Strict Transport Security Pins HTTPS for Future Visits

HTTP Strict Transport Security Pins HTTPS for Future Visits TLS protects an HTTP connection only after the client is using HTTPS. A user who enters a bare hostname, follows an old http:// link, or reaches a redirecting HTTP endpoint can still begin with an unencrypted request. HTTP Strict Transport Security (HSTS) gives a supporting browser a persistent rule for that host. After receiving a valid Strict-Transport-Security header over HTTPS, the browser records the policy and rewrites later HTTP navigation to HTTPS while the policy remains active.

Cybersecurity 23 Sep 2026 5 min read

Fetch Metadata Adds Request Context to Server-Side Policy

Fetch Metadata Adds Request Context to Server-Side Policy A server often sees the same authenticated cookie on requests created by very different browser actions. A form submitted from another site, a same-origin API call, an image load, and a top-level navigation can all reach the same host. Cookies alone do not describe that request context. Fetch Metadata adds browser-generated request headers that describe where a request came from and how the browser intends to use the response. A server can incorporate those signals into an isolation policy before application logic handles a sensitive route.

Cybersecurity 23 Sep 2026 5 min read

Cross-Origin-Resource-Policy Limits No-CORS Embedding

Cross-Origin-Resource-Policy Limits No-CORS Embedding Many browser elements can request resources across origins without using CORS. Images, scripts, media, and other subresources can travel through no-cors fetch paths where the page does not receive normal script-level access to the response body. That restriction is useful, but an unwanted cross-origin load can still expose a resource to embedding or side-channel conditions. The Cross-Origin-Resource-Policy response header, commonly shortened to CORP, lets the resource owner state which site relationship is allowed for those no-cors loads.

Cybersecurity 23 Sep 2026 6 min read

Content Security Policy Nonces Control Script Execution

Content Security Policy Nonces Control Script Execution A Content Security Policy can turn script execution from a broad location rule into an explicit per-response decision. Instead of trusting every script served from an allowed host, the server places a fresh nonce in the policy and copies that value only onto script elements it intends to authorize. Content-Security-Policy: script-src 'nonce-r4nd0mBase64Value' <script nonce="r4nd0mBase64Value" src="/assets/app.js"></script> A script element without the matching nonce is not authorized by that directive. This makes injected markup less useful to an attacker when the injection cannot obtain a valid nonce.

Cybersecurity 22 Sep 2026 4 min read

X-Content-Type-Options Blocks MIME Type Sniffing

X-Content-Type-Options Blocks MIME Type Sniffing HTTP responses carry a Content-Type header that describes the media type of the representation. Browsers also have a history of inferring a type from response bytes when the declared type is absent, incorrect, or ambiguous. That inference can be useful for old content, but it creates an execution boundary that application operators may not intend. X-Content-Type-Options: nosniff narrows that boundary. For request destinations covered by the browser’s MIME checking rules, the response must have an acceptable declared type instead of relying on content sniffing. The header is small, but its effect depends on correct Content-Type values throughout the application.

Cybersecurity 22 Sep 2026 6 min read

Subresource Integrity Pins External Resources to Expected Bytes

Subresource Integrity Pins External Resources to Expected Bytes Loading a script or stylesheet from another host creates a direct dependency on the bytes that host returns. TLS protects the connection in transit, but it does not state that the response is the exact object the page operator intended to execute or apply. Subresource Integrity (SRI) adds that byte-level condition. An HTML element can carry integrity metadata containing one or more cryptographic digests. A supporting browser fetches the resource, computes the relevant digest, and uses the response only when the result satisfies the metadata.

Cybersecurity 22 Sep 2026 7 min read

Subresource Integrity Pins Browser-Loaded Assets to Approved Bytes

Subresource Integrity Pins Browser-Loaded Assets to Approved Bytes A web page can load executable code from infrastructure outside the application’s deployment boundary. A <script> URL may point to a CDN, a package distribution endpoint, or another origin operated under a separate release process. TLS protects the connection to that endpoint, but a valid HTTPS response can still contain bytes different from the version the page author intended to run. Subresource Integrity, commonly shortened to SRI, adds a content check at the browser. The document carries cryptographic digest metadata for a resource. After fetching the resource, the browser computes the applicable digest and compares it with the metadata before accepting the resource for the protected use.

Cybersecurity 22 Sep 2026 5 min read

SameSite Cookies Restrict Cross-Site Credential Sending

SameSite Cookies Restrict Cross-Site Credential Sending Cookies are ambient credentials: once stored, a browser can attach them to matching requests without application code explicitly supplying each value. That convenience also creates a security boundary. A page on one site may cause a browser to send a request to another site, and an authentication cookie attached to that request can make it act with the user’s session. The SameSite cookie attribute narrows that behavior. It tells the browser when a cookie is eligible to accompany requests whose site context differs from the site that set the cookie. The attribute is useful against classes of cross-site request forgery, but it is not a complete authorization mechanism and does not replace CSRF tokens or server-side request checks where those controls are required.

Cybersecurity 22 Sep 2026 5 min read

Referrer-Policy Reduces Referrer Data on Outbound Requests

Referrer-Policy Reduces Referrer Data on Outbound Requests A browser can attach a Referer request header when a document navigates to another page or fetches a subresource. Without a suitable policy, that header can expose more of the source URL than the destination needs. Paths can contain internal object names, routing details, campaign parameters, or other context that should not cross a trust boundary. Referrer-Policy gives a site control over that disclosure. The policy determines which referrer information the browser may attach to eligible requests. It does not authenticate the destination, encrypt traffic, or replace URL design discipline. Its role is narrower: reduce the source URL data released by the browser.

Cybersecurity 22 Sep 2026 5 min read

Permissions-Policy Narrows Browser Feature Access

Permissions-Policy Narrows Browser Feature Access A web document can sit close to powerful browser capabilities. Depending on browser support, context, user permission, and policy, code may request access to features such as geolocation, camera, microphone, or fullscreen. An embedded document can also inherit access to some features from the page that contains it. Permissions-Policy adds a server-controlled restriction layer. A response can declare which origins are eligible to use selected features in a document and its frame tree. The policy does not grant a user permission and does not make an origin trustworthy. It removes capability from contexts that do not need it.

Cybersecurity 22 Sep 2026 6 min read

Permissions Policy Constrains Browser Feature Access

Permissions Policy Constrains Browser Feature Access A web document can contain first-party code, third-party scripts, and embedded frames that execute within different origins. Browser APIs then add another boundary: some features expose sensors, media devices, display state, or other capabilities that a site may not want every embedded context to use. Permissions-Policy lets a response declare which origins may use selected browser features in the document and its descendants. The policy is a capability boundary, not a replacement for the permission prompt shown to a person. A feature can be permitted by policy and still be denied by browser permission state, platform settings, secure-context requirements, or other API-specific conditions.

Cybersecurity 22 Sep 2026 4 min read

Fetch Metadata Lets Servers Filter Cross-Site Requests

Fetch Metadata Lets Servers Filter Cross-Site Requests A server often receives enough HTTP data to process a request but not enough context to classify the browser action that produced it. Fetch Metadata request headers add that context. Supporting browsers send Sec-Fetch-* fields that describe the relationship between the initiator and target, the request mode, the destination, and whether a navigation was triggered by a user activation. These headers can support a resource-isolation policy at the server. An endpoint intended only for same-origin application traffic can reject requests whose metadata shows an unexpected cross-site context before application logic handles them.

Cybersecurity 22 Sep 2026 5 min read

CSP frame-ancestors Restricts Who Can Embed a Page

CSP frame-ancestors Restricts Who Can Embed a Page A web page can be security-sensitive even when an attacker cannot read its DOM. If another site can place that page inside a transparent or carefully positioned frame, the attacker may arrange visible controls so a user interacts with the framed application while believing they are interacting with something else. This class of UI redressing is commonly associated with clickjacking. The Content Security Policy directive frame-ancestors gives the framed response control over that boundary. Instead of trusting the embedding page to behave safely, the protected response declares which ancestors are permitted to contain it.

Cybersecurity 22 Sep 2026 6 min read

Cross-Origin-Resource-Policy Controls Resource Embedding

Cross-Origin-Resource-Policy Controls Resource Embedding A server can publish an image, script, font, or other resource at a URL without intending every site on the web to embed it. Network reachability alone does not express that boundary. A browser may be able to request a resource even when the response is not exposed to JavaScript through the same-origin policy. Cross-Origin-Resource-Policy (CORP) gives the resource server a response-side control for that case. The header tells supporting browsers which relationship between the requesting context and the resource is acceptable for relevant no-CORS requests. If the relationship violates the policy, the browser blocks use of the response body.

Cybersecurity 22 Sep 2026 5 min read

Cross-Origin-Opener-Policy Separates Top-Level Browsing Contexts

Cross-Origin-Opener-Policy Separates Top-Level Browsing Contexts A browser window is not isolated merely because it displays a document from another origin. Windows can retain relationships through mechanisms such as window.opener, and those relationships affect which browsing contexts occupy the same browsing context group. Cross-Origin-Opener-Policy (COOP) gives a top-level document control over that grouping boundary. It is delivered as an HTTP response header and can cause cross-origin documents to be placed in separate browsing context groups.

Cybersecurity 22 Sep 2026 5 min read

Cross-Origin-Embedder-Policy Requires Resource Opt-In

Cross-Origin-Embedder-Policy Requires Resource Opt-In A page can pull scripts, images, fonts, workers, frames, and other resources from origins outside its own. Those dependencies often cross an administrative boundary as well as an origin boundary. Cross-Origin-Embedder-Policy (COEP) lets a document require stronger conditions before the browser loads cross-origin resources into its context. The common restrictive value is: Cross-Origin-Embedder-Policy: require-corp With require-corp, a cross-origin resource loaded without CORS must explicitly permit the embedding context through Cross-Origin Resource Policy (CORP). Resources fetched in CORS mode can instead satisfy the relevant CORS checks.

Cybersecurity 22 Sep 2026 5 min read

Content Security Policy Nonces Authorize Individual Script Elements

Content Security Policy Nonces Authorize Individual Script Elements Inline JavaScript creates a difficult boundary for a strict Content Security Policy. A page may need a small bootstrap block generated by the application, while arbitrary inline script must remain blocked. Allowing all inline execution with 'unsafe-inline' removes much of the value of script-src. A nonce gives the response a narrower mechanism. The server generates an unpredictable value for that response, places it in the CSP source list, and attaches the same value only to script elements that are meant to execute.

Cybersecurity 22 Sep 2026 5 min read

Clear-Site-Data Resets Browser State for an Origin

Clear-Site-Data Resets Browser State for an Origin A logout endpoint can invalidate a server-side session and still leave browser state behind. Cached responses, cookies, DOM storage, and other client-side data may survive unless the application addresses them separately. That residue does not automatically create a vulnerability, but it matters when a security boundary depends on returning a browser profile to a cleaner state. The HTTP Clear-Site-Data response header gives a server a browser-enforced reset mechanism. A response names one or more data classes, and a supporting user agent clears the matching state associated with the response origin according to the header’s processing rules.

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 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 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.