[MajesticHobo2]

Not sure I agree with this part:

> Allow all GET, HEAD, or OPTIONS requests.

> These are safe methods, and are assumed not to change state at various layers of the stack already.

Plenty of apps violate this assumption and do allow GET requests to alter state.

[chrisfosterelli]

IMO apps that do this have a bug, and possibly a security one. This causes issues with prefetching, bot traffic, caching, CSRF, and just plain violates HTTP standards.

[pinoy420]

Not really. If I have a service where I need one click to perform an action and store data. It has to be a GET. You can’t post from a url… purist dogma for the sake of purist dogma

[FireInsight]

One click to perform an action and store data? Have you heard of HTML forms with method="post"?

[pstuart]

Agreed. Those methods should be treated as idempotent.

[almog]

> Those methods should be treated as idempotent

Idempotency still implies it can change state on the initial call, which to me feels wrong in the context of GET/HEAD/OPTIONS.

[Mavvie]

Indeed, the correct term here is nullipotent.

[simonw]

Those apps are beyond helping already. They need to fix theselves.

[cryptonector]

This is on the server side, on the app. If your supposedly-safe methods aren't safe, then CSRF may not be your biggest problem.

[paulhodge]

That’s bad because visiting an evil site can easily trick your browser into performing one of those requests using your own credentials. CORS doesn’t stop the backend state effect from happening.

[MajesticHobo2]

That's exactly why I don't agree that GETs should be broadly exempted from CSRF protections. I'm not talking about CORS at all.

[motorest]

> Plenty of apps violate this assumption and do allow GET requests to alter state.

Yeah, that's not a justification. From a RESTful API design perspective, this just means plenty of apps are buggy/critical design problems. A bug in a random app does not mean HTTP verb lose their semantics.

[nchmy]

The entire WordPress ecosystem says hello