Skip to content

Archive

HTTP Headers

11 articles
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 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 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 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 6 min read

Referrer-Policy Limits URL Data Sent Across Requests

Referrer-Policy Limits URL Data Sent Across Requests A URL can contain more information than a destination needs. Paths and query strings may expose document identifiers, search terms, workflow state, or other context. When a browser follows a link or fetches a resource, referrer handling determines how much of the source URL can accompany that request in the HTTP Referer header. Referrer-Policy gives the response an explicit rule for that disclosure. It does not encrypt URLs or remove data already sent elsewhere. Its role is narrower: constrain referrer information emitted by the browser for subsequent requests.

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

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.