Overview
CSRF specifically targets state-changing requests — actions that modify data or settings. Understanding why these are the target, and why safe (read-only) requests generally are not, clarifies where CSRF protection belongs. This lesson covers state-changing requests.
Learning objectives
- Distinguish state-changing from safe requests.
- Explain why CSRF targets state-changing actions.
- Connect HTTP method semantics to CSRF exposure.
Core concept
A state-changing request performs an action with side effects — transferring funds, changing a password or email, updating settings, deleting data. These are the meaningful targets for CSRF, because forging them causes real harm. Safe requests (like a GET that only reads data) do not change state, so forging them is generally pointless (barring information leakage). This is a core reason the HTTP method semantics matter: state-changing actions should use non-GET methods (POST/PUT/DELETE) and be protected against CSRF.
How it works
CSRF works by tricking the victim's browser into sending a state-changing request that carries the victim's session. If an application performs sensitive actions via GET (violating method semantics), those actions are trivially forgeable — a simple link or embedded resource triggers them. Using proper methods (POST/PUT/DELETE) for state changes is a prerequisite for CSRF defenses to apply cleanly, and it prevents the easiest forgery vectors. The protection itself (tokens/SameSite) is then applied to these state-changing endpoints, since read-only endpoints usually need no CSRF token.
Practical example
An account-settings page changes the user's email via a POST /account/email request. This is a state-changing action and thus a CSRF target — it must be protected (token/SameSite). By contrast, GET /account/profile merely reads data and is not a meaningful CSRF target. A poorly designed app that changed the email via a GET request would be especially exposed, since the action could be forged with a mere link or image tag. Correct method use plus CSRF protection on the state-changing endpoint is the right design.
Cybersecurity relevance
Identifying state-changing requests is essential both to attacking (a tester focuses CSRF probing on them) and defending (protection is applied there). A common design flaw — performing state changes via GET — makes CSRF trivial and also causes caching/logging problems (as noted in the HTTP methods lesson). Ensuring sensitive actions use appropriate methods and carry CSRF protection is the practical takeaway. Read-only endpoints generally need no CSRF token, so protection is targeted where it matters.
Common mistakes
- Performing state-changing actions via GET, making them trivially forgeable.
- Adding CSRF protection to read-only endpoints while missing an unprotected state-changing one.
- Assuming non-GET alone prevents CSRF — method choice helps but tokens/SameSite are still needed.
Key takeaways
- State-changing requests (transfers, password/email changes, deletes) are CSRF's targets; safe read-only requests generally are not.
- Sensitive actions should use non-GET methods (POST/PUT/DELETE) and carry CSRF protection; using GET for state changes makes forgery trivial.
- CSRF defenses are applied to state-changing endpoints; identifying these is key to both testing and defending.
Check your understanding
- Why does CSRF target state-changing requests rather than read-only ones?
- Why is performing a sensitive action via a GET request especially dangerous for CSRF?