Holds session cookies
Remember CSRF
Full name: Cross-Site Request Forgery
Memory aid: Cross-site Requests are Forged using the browser's session.
Anti-CSRF protection differs from output encoding used against XSS.
Study area: Threats & application security · Batch 3
Relevant study for: CompTIA Security+ SY0-701 · ISC2 CISSP 2024 outline · CompTIA CySA+ · CompTIA PenTest+
Practice with exam flashcards →DevOps & Tooling / Knowledge library
Cross-Site Request Forgery (CSRF)
Causes a browser to submit an unwanted authenticated request
Why learn Cross-Site Request Forgery (CSRF)?
Understanding it guides same-site cookies and anti-forgery tokens
The problem it solves
It prevents another site from abusing ambient browser credentials
Where it came from
Cross-Site Request Forgery (CSRF) is a security concept that causes a browser to submit an unwanted authenticated request. Its guarantees and tradeoffs depend on the concrete implementation and operating context.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Define Cross-Site Request Forgery (CSRF) and distinguish it from a neighboring concept.
- Choose a realistic task where Cross-Site Request Forgery (CSRF) is appropriate.
- Identify a failure mode caused by misusing Cross-Site Request Forgery (CSRF).
- Interpret a small design or result involving Cross-Site Request Forgery (CSRF).
- Explain one tradeoff or limitation of Cross-Site Request Forgery (CSRF).
Documentation and sources
- OWASP Developer Guide: Security Principles (devguide.owasp.org)
Connect the ideas
Explore next
Real World Example
Banking Portal Transaction Integrity
Online banking platforms that allow authenticated users to perform sensitive fund transfers.
The business problem
An attacker tricks an authenticated user's browser into submitting an unauthorized state-changing request, such as a wire transfer, by leveraging the user's existing session cookies.
How this topic solves it
Implementing unique, cryptographically strong anti-CSRF tokens for every state-changing request ensures that the server only processes requests that include a secret, unpredictable value known only to the legitimate client application.
- Generate a cryptographically secure, unique token for the user session upon login.
- Embed this token as a hidden field in all HTML forms or as a custom header for AJAX requests.
- Configure the server to validate the presence and correctness of this token before executing any sensitive business logic.
- Reject any request that lacks a valid token or contains a mismatch, returning a 403 Forbidden error.
The flow shows how the server validates the request origin using a secret token.
Attempts malicious request
Validates anti-CSRF token
Protected resource
- User Browser → Sends request with valid token → Banking Server
- Attacker Site → Sends request without token → Banking Server
- Banking Server → Authorized state change → Account Ledger
- Banking Server → Rejects unauthorized request → Attacker Site
Expected business outcome
The application effectively prevents unauthorized actions because the attacker cannot predict or retrieve the secret token required to complete the request.
Limitations and checks
The primary limitation is that tokens must be managed carefully across distributed systems; if the token generation logic is weak or the token is leaked via insecure channels like HTTP or logs, the protection is bypassed. Check for this by auditing token entropy and ensuring they are transmitted only over TLS.