Q257: CSRF Threat Modeling and Mutation Protection

What Interviewers Want To Evaluate

Interviewers want to know whether you can explain CSRF as a browser credential-sending problem and connect it to cookies, SameSite, mutation design, and server verification.

They also want to see whether you can avoid the common mistake of treating CORS as CSRF protection.

Short Interview Answer

CSRF happens when a malicious site causes the browser to send an authenticated request to another site where the user already has credentials. The attacker usually cannot read the response, but they may trigger a state-changing action. Protection includes safe HTTP methods, SameSite cookies, CSRF tokens for risky cookie-authenticated mutations, origin or referer checks, idempotency, re-authentication for sensitive actions, and server-side authorization. CORS is not enough because simple cross-site form submissions do not require CORS read access.

Detailed Interview Answer

CSRF means Cross-Site Request Forgery.

The important word is "request."

The attacker does not need to read private data.

They only need the browser to send a request that carries the user's credentials.

If the server accepts that request as intentional, a mutation can happen.

Why Cookies Matter

Cookies are sent automatically by the browser when request rules match.

That makes session cookies convenient.

It also means a different site may be able to trigger a request that includes those cookies.

SameSite helps reduce this risk.

But SameSite is not the whole design.

Example Attack Shape

Imagine the user is logged into a banking app.

A malicious page includes:

<form action="https://bank.example/transfer" method="POST">
  <input name="amount" value="1000" />
  <input name="to" value="attacker" />
</form>

If the browser sends the banking session cookie and the server accepts the mutation, the attacker may succeed without reading the response.

Safe Methods

Use HTTP methods honestly.

Safe reads:

GET
HEAD
OPTIONS

Mutations:

POST
PUT
PATCH
DELETE

Never perform destructive actions with GET.

GET requests can be triggered by images, links, prefetching, crawlers, and browser behavior.

SameSite

SameSite=Lax blocks many cross-site subresource requests while allowing top-level navigation.

SameSite=Strict blocks more but may hurt normal flows.

SameSite=None allows cross-site cookies and requires Secure.

If your product uses SameSite=None, treat CSRF protection as especially important.

CSRF Tokens

A CSRF token is a value the attacker cannot guess and cannot obtain from their site.

Common patterns:

synchronizer token stored server-side
double-submit cookie pattern
signed token tied to session
per-form or per-request token for sensitive flows

The server checks the token on mutation.

If the token is missing or invalid, reject the request.

Origin Checks

Servers can inspect:

Origin
Referer
Sec-Fetch-Site
Sec-Fetch-Mode

Origin checks are useful defense-in-depth.

They should be implemented carefully because headers can be absent in some cases.

For high-risk mutations, combine checks rather than depending on one signal.

CORS Is Not CSRF Protection

CORS controls whether browser JavaScript can read a cross-origin response.

CSRF is about causing a request to be sent.

A simple form POST can trigger a request without needing CORS success.

That is why "our API has CORS" is not a complete CSRF answer.

API Design

Mutation APIs should consider:

authentication
authorization
CSRF protection
idempotency
validation
rate limiting
audit logs
confirmation for sensitive actions
rollback where possible

Frontend teams influence this through form design, request method choice, confirmation UX, and how tokens are attached.

SPA and Server Components

Single-page apps still need CSRF thinking if they use cookie-authenticated APIs.

Server-rendered apps still need CSRF thinking for forms and Server Actions.

The rendering model does not remove the browser credential behavior.

The question is whether a cross-site page can trigger an authenticated mutation.

Common Mistakes

Common mistakes include:

using GET for mutations
assuming JSON APIs are automatically safe
assuming CORS prevents CSRF
using SameSite=None without additional protection
checking only client state
forgetting admin actions need stronger confirmation
not testing form POST attack paths
not logging rejected suspicious mutations

Interview Example

If asked, "Do we need CSRF protection for a JWT API?"

Answer by asking how the token is stored and sent.

If the token is in an Authorization header manually attached by JavaScript, classic CSRF risk is lower because a random form cannot attach that header.

If the token or session is in automatically sent cookies, CSRF risk is relevant.

XSS risk may be higher or lower depending on storage.

Senior-Level Framing

The senior framing:

"I classify mutations by risk and credential behavior. If browser credentials are sent automatically, I protect state-changing operations with honest methods, SameSite, CSRF tokens or origin checks, server authorization, and user confirmation for high-impact actions."

Practice Prompt

Threat-model these actions:

save profile
change email
delete account
export PDF
mark question complete
purchase subscription

For each, decide whether CSRF protection, re-authentication, idempotency, or audit logging is required.

Final Mental Model

CSRF is not about stealing a response.

It is about tricking the browser into sending a trusted request.

Protect mutations where trust, credentials, and side effects meet.