News for hackers. Stuff that matters.
Re:Why do we have both CSRF protection and CORS? by jcmfernandes on Sunday March 02, 2025 @06:53PM (#43236645)
> Fun fact: you don't need CSRF protection at all if your API is strictly JSON-based, or uses any content type that isn't one of the built-in form enclosure types. The Powers That Be are talking about adding a json enclosure type to forms, but submitting it would be subject to cross-origin restrictions, same as it is with JS.

AFAIK, this is not totally accurate because the internet is a messy place. For example, the OAuth authorization code grant flow blesses passing the authorization code to the relying party (RP) in a GET request as a query parameter. The RP must protect against CSRF when receiving the authorization code.

Re:Why do we have both CSRF protection and CORS? by chuckadams on Sunday March 02, 2025 @07:01PM (#43236698)
Ah yes, good catch. That's what the `state` parameter is about, right? But I'll weasel out and say that lack of a content type (being a GET) is one of the built-in types too ;)
Re:Why do we have both CSRF protection and CORS? by jcmfernandes on Monday March 03, 2025 @04:04AM (#43239832)
That is correct :)
Re:Why do we have both CSRF protection and CORS? by catlifeonmars on Sunday March 02, 2025 @11:35PM (#43238339)
> The RP must protect against CSRF when receiving the authorization code

Is this via PKCE or (ID) token nonce validation?

Re:Why do we have both CSRF protection and CORS? by chuckadams on Monday March 03, 2025 @08:20AM (#43241451)
A nonce, kept in an extra query parameter named "state". https://stackoverflow.com/a/77029859 has some of the gory details (myself, I just hash the session's CSRF token to generate a state token)