Ferrite Docs

Security

Headers & Cookies

Return secure response headers and host-only cookies through Ferrite's typed response contract.

View as Markdown

Ferrite lets an app set approved response headers and cookies without exposing a raw proxy or accepting ambiguous header syntax. The Gateway validates metadata and emits the final response.

Authentication cookies should use the host-only prefix and the narrowest practical scope:

__Host-ferrite-auth-session=<opaque>; Secure; HttpOnly; Path=/; SameSite=Lax

Do not set Domain on a __Host- cookie. Rotate the opaque value at login, reauthentication, privilege change, and tenant change.

Add response security

Use the response metadata contract for:

Content-Security-Policy: default-src 'self'; frame-ancestors 'none'
Referrer-Policy: no-referrer
X-Content-Type-Options: nosniff
Permissions-Policy: camera=(), microphone=(), geolocation=()
Cross-Origin-Opener-Policy: same-origin

Choose a CSP that matches the application’s actual scripts, images, and connections. Avoid weakening it with broad wildcards merely to clear a console error.

CSRF

Cookie-authenticated unsafe methods require a session-bound CSRF token plus Origin or Referer validation. SameSite is defense in depth, not the only CSRF control. OAuth and OIDC callbacks need the expected cross-site navigation behavior; test them before tightening SameSite globally.

Prevent token leakage

After consuming an action link, redirect to a token-free URL and send Referrer-Policy: no-referrer. Never put session, reset, invitation, or magic link material in logs or agent-visible page content.

See Authentication and Routing.