flawopen.com/CSRF/GET requests
CSRF tokens for GET requests: when are they needed?
If GET only retrieves data, it should not change server state and normally does not need a CSRF token. Browsers, crawlers, previews, and embedded resources may trigger GET without an intentional click, so put actions such as deleting or purchasing behind an unsafe method and protect cookie-authenticated changes against CSRF. A legacy GET that changes state is still vulnerable and needs a temporary defense while you migrate it.
Why GET must remain a safe method
RFC 9110 defines GET as safe: the client does not request a state change. Safe does not mean the server has no incidental effects, such as logging. GET is also idempotent, but those are separate properties. Browsers, prefetchers, crawlers, and link previews can issue safe requests without a deliberate user action. A cross-site <img src="..."> can also cause a browser to send a GET with the user's cookies. If that endpoint deletes an item or changes account settings, it violates GET's semantics and can be triggered by ordinary page content.
Put CSRF defenses on state-changing requests
- ✓Keep GET, HEAD, and OPTIONS free of requested state changes; use POST, PUT, PATCH, or DELETE for mutations
- ✓Protect cookie-authenticated unsafe methods with the framework's CSRF defense or a validated token; use SameSite and Origin/Fetch Metadata checks as additional layers
- ✓Treat any state-changing GET as a method-semantics bug; add a temporary CSRF defense if needed, then migrate the action and remove secrets from URLs
CSRF tokens on GET: common questions
Treat it as vulnerable. Temporarily require a server-validated CSRF defense (for example, a synchronizer token plus Origin or Fetch Metadata checks where supported), audit caching and referrers, and migrate the action to POST, PUT, PATCH, or DELETE. Avoid putting tokens in query strings: URLs can appear in browser history, logs, and referrer data. A token check is only a bridge until the endpoint follows safe-method semantics.