Cross Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is a vulnerability that allows an attacker to trick a user’s browser into performing unintended actions (eg. go to a website that can transfer money from your bank account,change password of your social media account). This happens when user is already logged into a trusted website beforehand.

The core issue is excessive trust in the browser:

• The browser automatically includes session cookies, authorization headers, or credentials with every request to a site.
• If the server does not properly verify who initiated the request, it cannot distinguish a legitimate user action from a forged one.

What Can CSRF Do?

• Account Takeover: Change passwords, emails, or security settings
• Financial Fraud: Transfer funds, make purchases
• Data Manipulation: Delete/modify sensitive data
• Privilege Escalation: Grant admin rights to attackers

Why CSRF Happens

1. No Server-Side Request Validation: The server does not verify whether the request was intentionally generated by the user and accepts any request that includes valid session credentials
2. Flawed Session Handling: Session tokens are valid but not tied to user intent and emain usable across sites and requests
3. Weak Cookie Policies: Cookies lack SameSite attributes which allows browsers to freely send them on cross-site requests
4. Reliance on Untrusted Headers: Using Referer or Origin headers alone. These headers can be missing or stripped

Mitigation

1. Use anti-CSRF tokens (unique token generated at server side) to validate user intent and embed it in forms or headers. Token must be tied to the user session
2. Use SameSite attribute for authentication cookies. it can be set to Strict (cookies sent only for same-site navigation) or Lax (Allows top-level navigation but blocks most CSRF)
3. Require re-authentication for sensitive actions like changing passwords, updating email or disabling MFA.
4. Use only POST requests for state changes. CSRF is easier to exploit when actions are exposed via GET req.
5. Avoid weak Referer validation like checking Referer and Origin headers. It can be helpful but should never be the sole protection.
6. Using a well-defined Content-Security Policy header is a supplementary security measure that can reduce attack surface significantly.