Update: Document how to protect against Same-site CSRF

[nickchomey]

What is missing or needs to be updated?

I don't notice any text in the CSRF doc on how to protect against same-site CSRF, arising from malicious user-generated content. For example, a comment on a post, in a forum, etc includes a malicious link to the same site that invisibly mutates another user's state.

Escaping html output that might contain user-generated content is covered by the XSS doc, which is linked at the top of the CSRF doc. But escaping sn't always possible/desirable (and sometimes mistakes are made).

So, in the event something slips through, same site CSRF is possible. Though, is this only a problem if some GET requests can mutate state?

An exception to that is if you use a declarative JavaScript approach, as is now popular with htmx, Datastar, alpine etc, where you can create js post requests just via text

Eg <div data-on:click="@post('/pwned')"></div>

Though, I suppose that not escaping input is still a more fundamental issue than CSRF protection.

How should this be resolved?

Since the XSS docs already cover escaping, perhaps this is only an issue for GET mutations. Perhaps this can be called out more explicitly in the CSRF doc?

In particular, perhaps it should be made more clear that seemingly only CSRF tokens can protect against this, since Fetch Metadata, for example, would be same-origin/same-site?

@mkhanas, tagging you since you're interested in this topic as well.

[nickchomey]

I'm struggling to see how your comment is relevant to this issue. Did you post it in the wrong issue? Am I missing something?

[SuyashJain17]

Yeah my bad. I just posted on the wrong one. Sorry !!

[szh]

Please use the PR template. See CONTRIBUTING.md for details.

[nickchomey]

The contributing.md says PRs should be created after " the issue has been discussed and approved". That hasn't happened yet. Any thoughts?

[szh]

Sorry, my bad. I commented thinking this was a PR.

[prasunsrivastav123-lang]

hey ..
I’d like to help by improving the CSRF documentation based on this issue. My understanding is that the docs could more clearly explain same-site CSRF risks, especially when user-generated content or modern JS frameworks can trigger state-changing requests.

I’m planning to make a small documentation update to:

Clarify that GET requests should never change state

Explain where SameSite cookies and Fetch Metadata may not be sufficient

Emphasize when CSRF tokens are still required

Please let me know if this approach is correct before I open a PR. Thank you!

[nickchomey]

That does not sound relevant to this issue, or even productive - I think that all of what you mentioned is already documented. Please don't submit a PR - you don't understand the issue. In fact, the issue and what to do about it hasn't even been discussed/established yet, so a PR is grossly immature at this point.

Moreover, there's been numerous students recently, seemingly all from India, trying to make contributions here. One even somehow succeeded in making a mess of the CSRF documentation that I and others worked very hard on previously.

I beg whoever is sending you here to stop doing so. There's endless productive ways to get experience and contribute to open source - submitting uninformed PRs about security is not one of them. (I am not part of the OWASP team, so dont speak for them. But I have to figure that they are aligned with this)

[jmanico]

Closing this out. Thank you folks.