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