High Level Overview

Cookie-authenticated APIs versus Authorization headers

What Is CSRF Protection for API Endpoints?

CSRF stands for Cross-Site Request Forgery. It’s a type of web attack where a malicious website tricks a logged-in user’s browser into sending unauthorized commands to another site where the user is authenticated.

How Does a CSRF Attack Work?

1. The user is logged into https://mybank.com in one browser tab, with a valid session cookie.
2. The user visits a malicious site like https://evil.com in another tab.
3. The malicious site silently sends a request to https://mybank.com/transfer-funds using the user’s cookie.
4. If the server does not verify the request’s origin, the transaction succeeds — without the user’s knowledge.

What Is CSRF Protection?

CSRF protection ensures that only legitimate requests from your own frontend can invoke protected actions. It does this by requiring a second secret token that:

• Is unique to the user’s session
• Is embedded in the frontend application
• Must be submitted with every state-changing request

If the CSRF token is missing or invalid, the server rejects the request — even if the session cookie is valid.

Do APIs Need CSRF Protection?

Yes — but only in specific cases:

Authentication Method	CSRF Protection Needed?
Cookie-based (session auth)	Yes
Token-based (e.g., Bearer JWT)	No

Cookie-authenticated APIs are vulnerable because browsers automatically send cookies with every request — even across domains. Token-authenticated APIs are generally safe, as browsers don’t attach Authorization headers to cross-site requests.

How to Implement CSRF Protection

1. Generate a CSRF token upon login or session start.
2. Send it to the client via a meta tag, response header, or JSON body.
3. The client stores it and sends it back in a custom header, like X-CSRF-Token.
4. The server checks:
   • The session cookie is valid
   • The CSRF token matches the session token

Example CSRF-Protected Request

POST /update-profile HTTP/1.1
Host: api.website.com
Cookie: session=abc123
X-CSRF-Token: 9f3a2cd8ea7b...
Content-Type: application/json

{
  "email": "new@email.com"
}

Detailed Example: How a Hacker Exploits CSRF

Target Scenario

Suppose your banking app at https://mybank.com uses session cookies to authenticate users and has no CSRF protection.

Attacker Setup

The attacker creates a malicious website at https://evil.com and embeds the following form:

<form action="https://mybank.com/transfer" method="POST">
  <input type="hidden" name="amount" value="1000">
  <input type="hidden" name="to_account" value="attacker123">
  <input type="submit">
</form>
<script>
  document.forms[0].submit();
</script>
  

Victim Action

A logged-in user visits https://evil.com while still authenticated at https://mybank.com. Their browser automatically sends their session cookie with the request.

What Happens

• The server at https://mybank.com sees a valid POST request with the session cookie.
• No CSRF token is required, so the request is accepted.
• $1000 is transferred from the victim’s account to the attacker’s account.

This entire transaction happens without the user ever clicking a button or being aware of it.

How to Prevent This

• Use a CSRF token with all POST, PUT, PATCH, DELETE requests.
• Verify both the session and the CSRF token on the server side.
• Use the SameSite=Strict or SameSite=Lax cookie attribute when possible.
• Switch to token-based authentication (e.g., JWT in the Authorization header) to eliminate CSRF vectors entirely.

Summary

• CSRF is a serious threat for cookie-authenticated APIs.
• APIs that rely on Authorization headers (e.g., Bearer tokens) are generally safe.
• To mitigate CSRF, validate a secret token on every write request.
• Consider switching to stateless token-based authentication to avoid CSRF altogether.