Validating CSRF Protection

Overview

Validate Cross-Site Request Forgery protection across web application endpoints,

forms, and API routes. This skill examines synchronizer token patterns,

double-submit cookie implementations, SameSite cookie attributes, Origin/Referer

header validation, and custom header requirements to identify state-changing

operations vulnerable to CSRF attacks.

Prerequisites

• Access to the target codebase and configuration files in ${CLAUDESKILLDIR}/
• Familiarity with the web framework in use (Express, Django, Rails, Spring, Laravel, etc.)
• Standard shell utilities and Grep/Glob available for codebase scanning
• Reference: ${CLAUDESKILLDIR}/references/README.md for CSRF protection methods, OWASP CSRF Prevention Cheat Sheet, and framework-specific API examples

Instructions

1. Inventory all state-changing endpoints by scanning for POST, PUT, PATCH, and DELETE route handlers using Grep. Include form action attributes in HTML templates, AJAX calls in JavaScript, and API route definitions.
2. For each state-changing endpoint, verify that at least one CSRF protection mechanism is in place: synchronizer token, double-submit cookie, SameSite cookie attribute, Origin validation, or custom header requirement.
3. Validate synchronizer token implementation: confirm tokens are generated server-side using a CSPRNG, bound to the user session, included in forms as hidden fields or request headers, and validated on every state-changing request. Flag tokens that are static, predictable, or reused across sessions as CWE-352 (Cross-Site Request Forgery).
4. Check double-submit cookie patterns: verify the cookie value matches the request body or header value, the cookie uses Secure and HttpOnly attributes, and the comparison is timing-safe to prevent token extraction.
5. Assess SameSite cookie attributes on session cookies: verify SameSite=Strict or SameSite=Lax is set. Flag SameSite=None without Secure as severity high. Note that SameSite=Lax permits top-level GET navigations, which may be insufficient for GET endpoints that trigger state changes.
6. Verify Origin/Referer header validation: check that the server validates the Origin header against an allowlist on state-changing requests. Flag implementations that fall back to no protection when the header is absent.
7. For API endpoints using token-based auth (JWT in Authorization header), confirm that cookies are not also sent -- if cookies are used alongside bearer tokens, CSRF protection remains necessary.
8. Check for CSRF bypass vectors: look for state-changing GET endpoints, JSONP endpoints, content-type sniffing (missing Content-Type enforcement), and Flash/Silverlight cr