CSRF , its mechanism and why do we need block disable csrf in REST API Security.

 CSRF (Cross-Site Request Forgery)

A browser-based attack where a malicious site tricks a user’s browser into sending a request (with cookies automatically attached) to your application.

---

When CSRF is enabled (default in Spring Security)

• Spring expects a CSRF token on every state-changing request (POST, PUT, DELETE).
• Token is generated server-side and must be sent back (header/form field).
• Protects against attacks that rely on browser + cookies.

Meaning:
Only requests coming from your legitimate frontend (which has the token) are accepted.

---

What “disable CSRF” means

http.csrf().disable();

• Spring stops validating CSRF tokens.
• Any request is accepted without CSRF token verification.

Impact:

• You lose protection against browser-based CSRF attacks.
• But only matters if your app uses cookies/session authentication.

---

Why it’s commonly disabled in REST APIs

Because REST APIs typically:

• Are stateless
• Use Authorization headers (JWT/Bearer tokens) instead of cookies

Key point:

CSRF attack depends on:

• Browser automatically sending cookies

If you use:

Authorization: Bearer <token>

• Browser does NOT auto-attach this → attacker cannot forge it
  → CSRF risk is effectively not applicable

---

When you SHOULD NOT disable CSRF

Keep CSRF enabled if:

• You use session-based login (JSESSIONID cookie)
• You have form login / browser clients
• Your app is accessed directly via browser with cookies

---

When it’s safe to disable

Disable CSRF if:

• Pure REST API
• Stateless authentication (JWT, OAuth2 access tokens)
• No reliance on cookies for auth

---

Simple mental model

• Cookies = vulnerable → need CSRF
• Authorization header = safe → CSRF not needed

---

Summary

• Disabling CSRF = “skip token validation”
• Safe for stateless APIs
• Dangerous for cookie/session-based apps

  1) How the attack actually works (step-by-step)

  Precondition:
  User is logged into your site → browser has a session cookie (e.g., JSESSIONID).

  Attack flow

  1. User logs into bank.com → server sets cookie:

     Set-Cookie: JSESSIONID=abc123
     

  2. User visits a malicious site (evil.com).

  3. That site silently triggers a request to your app:

     <img src="https://bank.com/transfer?to=attacker&amount=1000" />
     

     or:

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

  4. Browser behavior (critical part):
     • Automatically attaches cookies for bank.com

     • Sends:

       Cookie: JSESSIONID=abc123
       

  5. Server sees:
     • Valid session cookie
     • Legitimate authenticated user
  6. Result: request is accepted → money transferred

  ---

  Why this works

  • Browser automatically includes cookies for the target domain
  • Server cannot distinguish:
    • Legit request (user clicked button)
    • Malicious request (triggered from another site)

  ---

  2) CSRF token mechanism (how it prevents this)

  Core idea:

  Add a secret, unpredictable token that attacker cannot access.

  ---

  Flow with CSRF protection

  1. User loads your app page:

     • Server generates CSRF token:

       csrfToken = random_123
       

     • Sends it:
       • In HTML (hidden field), or
       • In a header (for SPA)

  2. Legit request must include:

     POST /transfer
     Cookie: JSESSIONID=abc123
     X-CSRF-TOKEN: random_123
     

  3. Server validates:
     • Cookie → user identity
     • CSRF token → request origin authenticity

  ---

  Why attacker fails

  From evil.com:

  • They can trigger request
  • But cannot read your site’s CSRF token

  So request becomes:

  POST /transfer
  Cookie: JSESSIONID=abc123
  (no CSRF token)
  

  → Server rejects it

  ---

  3) Key security principle

  CSRF token works because:

  • Cookies are automatically sent
  • Tokens are not automatically sent
  • And attacker cannot read your domain’s data (Same-Origin Policy)

  ---

  4) Why REST APIs don’t need CSRF (again, but deeper)

  If you use:

  Authorization: Bearer eyJhbGciOi...
  

  • Browser does NOT auto-attach this header
  • Malicious site cannot:
    • Read token
    • Add token

  So request becomes:

  POST /transfer
  (no Authorization header)
  

  → Rejected

  ---

  5) Important nuance (often missed)

  CSRF is not about stealing data, it’s about:

  “Performing actions on behalf of the user”

  It exploits:

  • Trust in browser
  • Automatic credential sending (cookies)

  ---

  6) Quick comparison

  Mechanism	Automatically sent by browser	Vulnerable to CSRF
  Cookies	Yes	Yes
  Authorization header	No	No

  ---

  Final takeaway

  • CSRF attack = “browser tricked into sending authenticated request”
  • CSRF token = “proof request came from your frontend”
  • Disable CSRF only when no automatic credentials (cookies) are involve
    
    
    
    CONCLUSION
  • When a user logs into bank.com, the server creates a session and the browser stores a cookie like Set-Cookie: JSESSIONID=abc123, which is then automatically attached to every request sent to bank.com because HTTP is stateless; if the user later visits a malicious site like attacker.com, that site can trigger a request such as <img src="https://bank.com/transfer?to=attacker&amount=1000" /> or a hidden form submission, and the browser will still send Cookie: JSESSIONID=abc123 because the request target is bank.com, even though it originated from another site, and since the server typically relies only on the session cookie, it may treat this as a legitimate authenticated request and process the transfer; this is a CSRF attack—not because the browser is confused, but because it automatically includes credentials without verifying request origin; to prevent this, the server generates a CSRF token like random_123, sends it to the legitimate frontend (e.g., <input type="hidden" name="_csrf" value="random_123"/> or via header), and requires it in every state-changing request such as POST /transfer with headers Cookie: JSESSIONID=abc123 and X-CSRF-TOKEN: random_123, and since a malicious site cannot read or include this token due to browser security restrictions, any forged request will only include the cookie but not the token and will be rejected by the server.