Advanced security headers: effects and maturity

Match each addition to its purpose

The foundations of HSTS, CSP and COOP/COEP/CORP remain separate topics. This article concerns their boundaries and suitable additional mechanisms.

Origin-Agent-Cluster: grouping, not a process guarantee

Origin-Agent-Cluster: ?1

?1 is the boolean true value in a Structured Field. The current foundational RFC is RFC 9651, which superseded RFC 8941. The HTML Standard allows a document in a secure context to use this header to request an origin-keyed agent cluster. An origin consists of scheme, host and port. HTML Standard, RFC 9651

When origin keying is active, document.domain can no longer relax the same-origin boundary. Exchanging a WebAssembly.Module with a document of another origin is also restricted. This can affect old applications that joined, for example, app.example.com and login.example.com through document.domain. Plan to use the same origin or narrowly defined messaging with validation of the sender's origin and the message format.

The browser still determines the actual processes and threads. Neither setting ?1 nor observing window.originAgentCluster === true proves a separate process or complete protection against Spectre. Conversely, an absent header does not prove that two subdomains share a process. Browser defaults may already enable origin keying. Chrome introduced such a default from version 115; older opt-outs and enterprise policies are not a lasting architectural solution. Chrome on document.domain

Apply the chosen policy consistently to affected documents. Within a browsing context group, the previously loaded history for the same origin also influences the assignment; adding a header later cannot arbitrarily reassign existing documents. Testing therefore needs fresh contexts and the real frame and window flows. In the documented local Chromium 147 test, origin keying was already active without the header. ?1 prevented the old DOM access arrangement; the explicitly tested Chromium variant ?0 allowed it. This is an observation of that browser, not a general recommendation to use ?0.

Fetch Metadata: information for server-side decisions

Fetch Metadata consists of browser request headers. These are not response headers to copy into a server configuration:

An application can use these signals, for example, to shield sensitive endpoints from unexpected browser requests initiated by other sites. A blanket block on every cross-site request would also break ordinary links, embedded resources and some login return paths. Decide according to route, method and purpose. An intentionally public image request needs different rules from a change to a customer account. Furthermore, same-site does not necessarily mean that every involved subdomain is trustworthy.

Ordinary page JavaScript cannot freely set these Sec- headers. Arbitrary HTTP clients outside the browser can reproduce them, however; they are not a user identity or a replacement for authentication, permission checks or an appropriate CSRF design. Missing headers need deliberate handling for older clients, bots and non-browser integrations. A proxy must not undermine the assessment through uncontrolled overwriting.

Start with bounded observation of the real request paths and introduce rules per endpoint. If the response depends on Fetch Metadata, the cache configuration must account for that selection, using appropriate Vary fields where necessary. Otherwise, a shared cache may reuse a response created for a different context. Fetch Metadata draft, §§ 2, 4, 5

Integrity-Policy: require SRI metadata

Subresource Integrity checks a resource against the specified hash. Integrity-Policy adds a requirement for certain resources to have suitable integrity metadata in the first place. A limited example for the observation phase is:

Reporting-Endpoints: integrity="https://reports.example/integrity"
Integrity-Policy-Report-Only: blocked-destinations=(script), endpoints=(integrity)

Before use, replace the placeholder domain with your own configured receiver. The Report-Only variant does not block under this policy. Consider an enforced Integrity-Policy only after checking the resource inventory, reports and functional paths. Reporting support and receipt also need verification; see the reporting article.

The policy concerns external resource requests, not a general inspection of all JavaScript content. A classic script can be blocked despite a correct hash if it is requested in no-cors mode. For a <script>, crossorigin="anonymous" may therefore be necessary even for the same origin to use the appropriate mode. For another origin, its CORS response must also be suitable. The documented limited Chromium test confirmed this: missing metadata and the no-cors case were blocked, while the case with a matching hash and CORS mode ran.

The SRI draft lists the destinations script and style; this does not establish identical support. The browser data read on 27 September 2026 lists Chrome 138, Firefox 145 and Safari 26 for the header, but Firefox does not process the reporting endpoints. For style, it lists no regular support in Chrome or Safari and only an opt-in Firefox preference. Do not copy a general policy for both scripts and styles without checking it. SRI draft, § 3.8, browser data

Document-Isolation-Policy: targeted testing, not a universal requirement

Document-Isolation-Policy describes another route to cross-origin isolation for a document. The WICG specification examined is a community draft, not a completed W3C standard. Google documents its introduction from Chrome 137 on desktop. An intention stated there to support Android is not evidence for your specific mobile target environment. Draft, Chrome introduction

The values isolate-and-require-corp and isolate-and-credentialless impose different conditions on resources from other origins. The first requires suitable permissions through CORS or CORP. The second particularly changes the handling of credentials for cross-origin no-cors subresources. Unlike the traditional COOP/COEP approach, it is intended to allow document-level isolation without the same requirements for all child frames and popup relationships.

This may be useful for an application that needs features dependent on isolation and whose embeddings complicate the existing approach. It does not justify a blanket replacement of a working COOP/COEP configuration. Check self.crossOriginIsolated, resources, window communication and the desired features in the actual target environments. The header's presence alone is insufficient. The documented desktop Chromium test confirmed isolation and different loading behaviour for a cross-origin image under the two values; it did not test a mobile platform or a complete application.

Arrange HTTPS redirects and host variants correctly

For addresses that have moved permanently, 301 and 308 are permanent redirects. 302 and 307 describe temporary redirects. For historical reasons, with 301 and 302 a client may change a POST request to GET; 307 and 308 preserve the method. Choose according to permanence and the required method behaviour, rather than a universal security ranking. RFC 9110, § 15.4

Once the final canonical address is established, avoid unnecessary intermediate steps:

A 301 does not remove this initial HTTP risk. The claim that ‘302 is never cached’ is also incorrect; cache rules and response information affect reuse. Already known or applicable preloaded HSTS can upgrade an HTTP destination to HTTPS before the network request. It does not replace arbitrary host normalisation, however, and a redirect first received over HTTP cannot give the browser trustworthy HSTS information.

Whether www.example.com or example.com is the main address depends on your architecture. Non-existent or deliberately separate hosts do not universally need consolidating. For actual aliases, redirects, internal links and canonical declarations should agree; paths and necessary parameters must be preserved. Google treats permanent redirects as a canonicalisation signal. This implies neither a guaranteed ranking improvement nor a general preference for non-www. Google on redirects

Review historical filters and software disclosures

Chrome removed its XSS Auditor in version 78. That is not a shared version boundary for every browser. Defences against XSS primarily include safe data handling, context-appropriate output and suitable browser policies such as CSP. Simply replacing a header name does not fix an application vulnerability. Chromium on the historical XSS Auditor

Distinguish findings, protection and compliance

In the reviewed implementation, the Web Security Check considers the visible OAC value and observed redirects. HTTP/HTTPS entry points and host variants are examined through limited additional requests. This does not test every path, every browser default or the server-side Fetch Metadata rules. The newer policies described here do not thereby automatically become fully tested scanner features.

A header scan establishes neither a complete security architecture nor general legal compliance. The relevant factors are the affected application, the actual effect and the documented decision. An absent additional header alone does not create a universal legal obligation to introduce it.