Function security_headers 

async fn security_headers(
    strict_transport_security: Option<HeaderValue>,
    request: Request,
    next: Next,
) -> Response

The headers every response this server sends carries.

This process terminates its own TLS and renders its own pages, so there is nothing in front of it to add them: /oauth/authorize and /dashboard are HTML a browser is handed directly. The set is the one a layer can apply without knowing the route — a consent page that cannot be framed, a content type that is believed rather than sniffed, and a request that says nothing about where the reader came from.

Applied to every response rather than to the HTML routes alone: the JSON, the dashboard’s assets and a blob are each served with the content type they actually are, and none of them is meant to be put in a frame either.

frame-ancestors is the whole of the content security policy. A script-src here would have to admit the new Function and the WebAssembly that dashboard.js loads its field animation through, and a policy written to permit eval buys nothing; framing is what the consent page needs refused. X-Frame-Options says the same thing again for a browser that reads only that one.

A route that sets a policy of its own keeps it: getBlob sets a sandbox (see crate::blobs), and X-Frame-Options still refuses framing there.

no-referrer, where the static site sends strict-origin-when-cross-origin: /oauth/authorize’s own URL carries the authorization request, and no page here has a reason to pass its address to anything it links to.

Strict-Transport-Security is added when the deployment set one; see AuthState::strict_transport_security. Every response goes out over TLS, so it is never sent over plain HTTP.