@jasonvarga Just tagging you here to ensure you take a look at it before the release of v6 as it introduces a couple of small breaking changes.

@aerni It looks like there's a couple of merge conflicts. Would you be able to take a look?

Done. I had to move the code from PR #11650 from the getCsrfTokenJs() to the new getNocacheJs() method. Functionally, it should be the same.

Thanks!

I could be entirely wrong, but isn't the whole point of CSRF that you can't get a token so you can't make backend requests from other domains? Wouldn't this allow anyone to request a CSRF token and then make cross site requests?

The csrf token is only for that user. Its attached to their session. If you hit that route to get a new csrf token, it would be yours and attached to your session.

To follow up, I think in theory this allows this attack:

// On attacker.com
fetch('https://statamic.com/!/csrf', {
    credentials: 'include',
})
.then(r => r.json())
.then(data => {
    fetch('https://statamic.com/any-malicious-request', {
        method: 'POST',
        credentials: 'include',
        headers: {
            'X-CSRF-TOKEN': data.token
        }
    });
});

This is the kind of attack CSRF is meant to protect against.

Unless you explicitly allow it, CORS will prevent cross-site requests to these routes.

(I was attacking from statamic.com.test, which is different from statamic.test - sorry, I should have picked more different domains for this example)

Unless you explicitly allow it, CORS will prevent cross-site requests to these routes.

No, I think that's a browser side prevention. You can still make those requests manually via something like Postman or curl. If we need to move this discussion to Discord for more rapid response we can. I am spinning up a proof of concept as I think this might be a bigger security issue.

This has been this way for a long time. This PR isn't really introducing anything new. If you want to consider this a security issue please send it appropriately and not just as a public comment. Thanks!

Being in the browser is kind of the point though. That's what it's protecting against. If you do it through postman/curl, you will not have the user's session. You'd just have your own. No different from you manually visiting the site.