CSRF
Definition
Cross-Site Request Forgery - attack that tricks users into performing unwanted actions on websites, posing security risks to web applications.
Use Cases
- GitHub: Protecting authenticated user actions (for example, changing account settings or creating/deleting resources) from being triggered by a malicious third-party website. — GitHub’s Rails-based application stack uses built-in anti-CSRF protections (authenticity tokens) so state-changing requests must include a valid per-session token. Requests missing or failing token validation are rejected, reducing the risk that a user’s logged-in browser can be abused to perform unintended actions. (Reduced risk of unauthorized state changes initiated from external sites, improving account safety and integrity of user actions.)
- Shopify: Securing merchant/admin actions in a browser session (for example, updating store settings or managing apps) against cross-site request forgery attempts. — Shopify’s web applications rely on standard CSRF defenses common in modern web stacks: per-request/per-session CSRF tokens for unsafe HTTP methods, strict cookie settings (for example, SameSite), and server-side validation to ensure requests originate from legitimate sessions and contexts. (Lower likelihood of fraudulent administrative actions executed through a merchant’s authenticated browser session, strengthening platform trust and reducing security incidents.)
Frequently Asked Questions
- What’s the difference between CSRF and XSS?
- CSRF tricks a logged-in user’s browser into sending an unwanted request to a site where the user is already authenticated (the attacker doesn’t need to read the response). XSS (Cross-Site Scripting) is when an attacker injects malicious script into a trusted website so it runs in the victim’s browser; XSS can often be used to steal data (like session tokens) or perform actions as the user. In short: CSRF abuses the browser’s automatic credential sending; XSS injects code into the site’s pages.
- When should I use CSRF protection?
- Use CSRF protection for browser-based applications that rely on cookies for authentication and have state-changing endpoints (POST/PUT/PATCH/DELETE), such as updating profiles, changing passwords, or transferring money. If your API is used by non-browser clients and uses Authorization headers (for example, OAuth2 bearer tokens) rather than cookies, CSRF risk is typically much lower, but you should still review any endpoints that accept cookie-based auth or are callable from a browser context.
- How much does CSRF protection cost?
- CSRF protection is usually low-cost because it’s commonly built into web frameworks (for example, token generation/validation) and implemented in application code and configuration. Costs mainly come from engineering time, testing, and any supporting security tooling (for example, a WAF subscription, additional logging/monitoring, or security reviews). Runtime overhead is typically minimal (extra token checks and sometimes an extra cookie/header).
Category: security
Difficulty: intermediate
Related Terms
See Also