| name | validating-csrf-protection |
| description | Validate CSRF protection implementations for security gaps. Use when reviewing form security or state-changing operations. Trigger with 'validate CSRF', 'check CSRF protection', or 'review token security'. |
| version | 1.26.0 |
| allowed-tools | Read, Write, Edit, Grep, Glob, Bash(security:*), Bash(scan:*), Bash(audit:*) |
| license | MIT |
| author | Jeremy Longshore <jeremy@intentsolutions.io> |
| tags | ["security","validating-csrf"] |
| compatibility | Designed for Claude Code, also compatible with Codex and OpenClaw |
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
${CLAUDE_SKILL_DIR}/
- Familiarity with the web framework in use (Express, Django, Rails, Spring, Laravel, etc.)
- Standard shell utilities and Grep/Glob available for codebase scanning
- Reference:
${CLAUDE_SKILL_DIR}/references/README.md for CSRF protection methods, OWASP CSRF Prevention Cheat Sheet, and framework-specific API examples
Instructions
- 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.
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.
- Check for CSRF bypass vectors: look for state-changing GET endpoints, JSONP endpoints, content-type sniffing (missing enforcement), and Flash/Silverlight crossdomain.xml files.
