Cross-Site Request Forgery (CSRF)

Ambient browser authority

Cross-site request forgery occurs when a browser automatically attaches a credential, such as a session cookie, to a request caused by an untrusted origin and the receiving application performs an unwanted action. The attack does not require the other origin to read the response. It relies on causing the request.

The target must have a state-changing operation, ambient credentials, a request shape the attacker can cause, and no effective intent check.

Request intent controls

Use an unpredictable CSRF token bound to the user's session and verify it on every state-changing request that uses cookie authority. A synchronizer token can be stored server-side. A signed double-submit token can bind a value to session context without a second server record. Do not use an unbound cookie and request value that an attacker can set together.

For browser APIs, require a custom request header and configure CORS narrowly. Validate the Origin header for sensitive requests where the deployment can define the expected origin. Use Sec-Fetch-Site and related Fetch Metadata as defense in depth. Reject state changes over safe methods such as GET and HEAD.

Cookie and action design

Use SameSite as a strong additional control, with Secure and suitable host or path scope. Understand required cross-site sign-in, embedded, or federated flows before selecting Strict, Lax, or None. Do not treat cookie behavior as the only CSRF control for sensitive operations.

Require fresh authentication or transaction confirmation for high-impact actions. Bind confirmation to the exact target, amount, role, or change. This limits both CSRF and misuse of a stolen session.

Failure and residual risk

Cross-site scripting can usually bypass CSRF controls because injected code runs under the trusted origin. A permissive CORS policy can let an attacker send or read credentialed requests. Login CSRF can bind a victim to the attacker's account even before a sensitive action. Alternate content types, method overrides, and legacy endpoints can bypass a control applied only to JSON APIs.

Pomerium boundary

Pomerium manages its own authentication flow and access session. The upstream application still owns its state-changing requests, CSRF tokens, origin checks, cookies, and transaction confirmation. A valid Pomerium session proves route access. It does not prove that the user intended a specific application action.

Evaluation checklist

• Which operations change data, authority, credentials, configuration, or external side effects?
• Which browser credentials attach without explicit application code?
• Does every cookie-authenticated state change require a session-bound intent signal?
• Are safe HTTP methods free of state changes and method overrides controlled?
• Are Origin, Fetch Metadata, CORS, and SameSite settings consistent with required flows?
• Do high-impact actions show and bind the exact transaction before execution?