HTTP Headers on Nalar

Clear-Site-Data Resets Browser State for an Origin

Tue, 22 Sep 2026 00:00:00 +0000

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.

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

Tue, 22 Sep 2026 00:00:00 +0000

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.

Permissions Policy Constrains Browser Feature Access

Tue, 22 Sep 2026 00:00:00 +0000

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.

Referrer-Policy Limits URL Data Sent Across Requests

Tue, 22 Sep 2026 00:00:00 +0000

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.

Referrer-Policy Reduces Referrer Data on Outbound Requests

Tue, 22 Sep 2026 00:00:00 +0000

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.