CSRF and SameSite Cookie Review Checklist
CSRF exploits browser-supplied credentials on cross-site requests. SameSite reduces some cases, but it is not an authorization check and can break legitimate federation flows.
Identify state-changing routes
List cookie-authenticated POST, PUT, PATCH, and DELETE routes. Example: changing bank destination must require a server-verified token. Example: a logout route may be low impact but should not create confusing cross-site state.
Control decision table
| Flow | Primary control | Browser check |
|---|---|---|
| same-site form | synchronizer token | missing token rejected |
| JSON API | custom header plus CORS | cross-site cannot set header |
| third-party callback | exact origin and state | intended return works |
| cookie | explicit SameSite choice | cookie behavior observed |
OWASP’s CSRF guidance, Set-Cookie reference, and CWE-352 are direct references.
Decision rule: every cookie-authenticated state change needs an origin-bound server verification.
Remediation
Use per-session or per-request tokens where suitable, verify Origin on sensitive routes, and test embedded or SSO journeys before tightening SameSite. Token presence alone does not defend XSS. Web testing can exercise real browsers.
Verify intent before state change
List every cookie-authenticated non-safe method and its expected browser flow. Use framework CSRF defense where available. Otherwise issue unpredictable server-side synchronizer tokens or session-bound signed double-submit tokens, require explicit submission outside cookies, and verify before state mutation. Check Origin or Fetch Metadata as defense in depth with documented fallback. SameSite, Secure, and HttpOnly settings protect different properties and must be selected per flow.
Run a cross-site form attempt, missing-token request, wrong-session token request, CORS preflight case, and SSO or embedded return. Record whether state changed, not only status code. Owner: identity owner. Pass: forged requests fail with no state change while intended journeys work. Fail: browser credentials authorize an unverified request or hardening breaks required flow. Exceptions name route, required cross-site behavior, alternative verification, approver, remediation, and expiry.
Cookie decision record
State why each authentication cookie needs Lax, Strict, or None plus Secure; browser default is not a documented policy. A cross-site SSO return can require narrow exception, but it still needs state validation tied to initiating session. Preserve browser version and cookie capture because sending behavior is browser-mediated.
Mutation authorization record
Expected output: route, HTTP method, session mode, token issue ID, token verdict, Origin or Fetch Metadata value, cookie attributes, side-effect result. This mutation record proves browser credentials never authorized a forged action.
Worked failure: A cross-site form posts a valid session cookie but lacks a token. Server must reject before writing the transfer or preference change.
Edge case: An SSO callback may require SameSite=None with Secure. Validate state against initiating session and limit exception to callback route.
Closure test: Repeat the cross-site request in supported target browsers. Closure passes when no state changes and intended same-site flow remains functional.
Request-origin drill
Map mutation endpoints by authentication mechanism. Cookie sessions need CSRF handling; bearer-token APIs may need different cross-origin controls but still require authorization. For each cookie route, document token location, validation order, Origin policy, and behavior when headers are absent. A proxy can change perceived host or scheme, so configure trusted proxy boundaries explicitly and test generated target origin against deployed values.
Use browser automation or a controlled manual case to submit a hostile form from another origin. Inspect database and audit output after the response, because a friendly error page can still hide a completed mutation. Test back-button behavior if per-request tokens are used, and test concurrency if token rotation can invalidate another open tab. Sensitive actions such as changing recovery methods may need reauthentication in addition to CSRF controls.
Record whether rejected request created audit event without creating protected business event. Test token validation before expensive processing and before asynchronous enqueue. This avoids a forgery becoming a resource-consumption route even when mutation later fails.
CSRF logging must avoid token values and session identifiers. Record route category, verification failure category, browser-origin signal, and correlation ID instead. Repeated invalid submissions may indicate broken client integration rather than attack, so pair telemetry with release version and support diagnosis. Do not return token details in error response. After session renewal, test that old token behavior matches policy and that a new token is issued through intended response channel.
Final review ties each protected mutation to one observed rejection and one intended browser journey. Expected result: missing, cross-site, or stale proof causes no business write. Edge case: concurrent tabs can hold different token generations; verify documented behavior. Close only when cookie policy, token validation, and audit evidence agree for deployed routes.