Secure-Session-Skipped header

A browser-to-server diagnostic signal that an otherwise applicable request intentionally proceeded without a bound credential because refresh was skipped. It is not sent by your server.

Syntax

An RFC 9651 List Structured Field. Members are coarse reason tokens with a required string session_identifier parameter.

Secure-Session-Skipped = sf-list
Secure-Session-Skipped: unreachable;session_identifier="session-42", quota_exceeded;session_identifier="session-43"

Inputs

Defined draft tokens
Item	Requirement / behavior
`unreachable`	Browser could not reach the refresh endpoint.
`server_error`	A server-side refresh failure such as 5xx.
`quota_exceeded`	Browser policy declined more signing/refresh work, for example a TPM quota.
`session_identifier`	String parameter identifying the session for that coarse reason.

Outputs

The browser can send the original request without the missing bound credential and with the Secure-Session-Skipped signal. Servers may use it to select a conservative fallback, such as a separate long-lived bootstrap cookie, but it does not prove a user or request authenticity.

Errors

Unknown tokens and malformed fields must not be trusted. Do not fail open merely because the header exists; it can be absent on a browser that does not implement DBSC. Current Chromium has internal transient signing-error handling and a TODO to expose it as a supported skipped token, so do not rely on undocumented tokens.

Context

This is request metadata emitted by user-agent policy after skipping a DBSC operation. An application cannot trigger it with JavaScript. It accompanies the originally deferred/applicable request, not necessarily the refresh endpoint POST.

Lifecycle

It appears only for a skipped attempt. A later request can refresh successfully; it is not logout or a permanent capability result. Servers should retain their ordinary unauthenticated/expired-session path and never make a skipped header a lasting authorization grant.

Fallback example

GET /sensitive HTTP/1.1
Host: app.example
Cookie: bootstrap=long-lived-recovery
Secure-Session-Skipped: unreachable;session_identifier="session-42"

# Server policy: bootstrap may issue a narrowly scoped recovery response,
# or require reauthentication. It must not treat the diagnostic as a proof.

Compatibility

DBSC availability and standards position
Item	Requirement / behavior
Chrome	DBSC availability, not page-layout support: ChromeStatus lists DBSC as in development, with Chrome desktop milestone 145. Its Android milestone is null/unknown; availability remains controlled by implementation and feature configuration.
Firefox	No signal; the Mozilla standards-position issue is the public evidence, not an implementation commitment.
Safari	No signal; the WebKit standards-position issue is the public evidence, not an implementation commitment.
Other engines	Unknown. The W3C document is an Editor’s Draft, not a final interoperable Recommendation.

Security and privacy

Use only coarse server decisions. Detailed reason-specific responses can become a fingerprint or account-state oracle. Keep fallback privileges narrower than the DBSC-protected cookie and preserve a reauthentication path.

Primary sources: skipped · algorithms · add-debug-header algorithm · chromium · chrome · rfc9651. External sources open in a new tab.