csrf-protection

Implement token-based and cookie-based CSRF defenses for state-changing endpoints.

Updated Mar 29, 2026
One-click install
npx skills add https://github.com/marquesfelip/agents-and-skills --skill csrf-protection-marquesfelip
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: csrf-protection
Source: https://github.com/marquesfelip/agents-and-skills/tree/main/skills/csrf-protection
Command: npx skills add https://github.com/marquesfelip/agents-and-skills --skill csrf-protection-marquesfelip

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

CSRF risks threaten state-changing operations in web apps by allowing attackers to perform actions on behalf of authenticated users when cookies are automatically sent.

Core Features & Use Cases

  • Token-based protection: synchronizer tokens in server-rendered forms and double-submit cookies for SPAs.
  • Cookie configuration: SameSite and Secure attributes to limit cross-origin risks.
  • Validation layers: origin and referer checks as defense-in-depth for sensitive endpoints such as password changes, payment actions, and logout.

Quick Start

Review your web application's CSRF defenses and implement token validation and SameSite cookies.

Frequently Asked Questions about csrf-protection

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement CSRF protection for state-changing endpoints like payments and logout?

CSRF protection for state-changing endpoints is implemented using synchronizer tokens for server-rendered forms and double-submit cookies for SPAs. These mechanisms ensure attackers cannot perform actions on behalf of authenticated users when cookies are automatically sent.

What is the difference between synchronizer token and double submit cookie patterns for CSRF defense?

Synchronizer token patterns store a server-side session token matched against submitted forms, while double submit cookie patterns send a random value in both a cookie and a request header. CSRF defense applies synchronizer tokens to server-rendered apps and double-submit cookies to SPAs.

Does setting SameSite cookies prevent CSRF attacks in single page applications?

SameSite cookie configurations limit cross-origin risks by restricting when cookies are automatically sent with requests. In SPAs, SameSite and Secure attributes provide CSRF defense alongside double-submit cookies, but origin and referer validation adds necessary defense-in-depth for sensitive endpoints.

Why do I need to validate origin and referer headers if I already use CSRF tokens?

Origin and referer validation provides defense-in-depth for sensitive endpoints like password changes and payment actions, verifying request sources even if token validation succeeds. CSRF tokens alone mitigate cross-site forgery, but layered validation ensures robust protection against sophisticated bypass attempts.

Can I use CSRF tokens with login and logout endpoints across server-rendered apps and SPAs?

CSRF tokens apply to login, logout, and sensitive account actions across both server-rendered apps and SPAs. Synchronizer tokens protect server-rendered forms while double-submit cookies secure SPA state-changing operations including POST, PUT, PATCH, and DELETE requests.

What are the limitations of relying only on cookie-based CSRF protection for web applications?

Cookie-based CSRF protection using SameSite attributes alone lacks comprehensive coverage without token rotation and constant-time comparisons. Limitations include browser compatibility variations and potential bypass scenarios, requiring layered token validation and origin checks for robust defense.