How to handle CSRF validation without Twig (headless)

[engram-design]

I'll preface this entire discussion that you should probably use GraphQL mutations in order to POST data to Craft. I'm unsure if this isn't working by design or not.

Let's say I have a headless site on one domain, Craft CP on another. I want to create an entry from the front-end of the headless site, but can't be bothered with GraphQL and mutations. I go the simple route and use JS's fetch() (axios would also do). I quickly run into the issue of CSRF tokens and a 400 Bad Request. But I can grab that by querying actions/users/session-info and adding it to my request - but no luck.

So - diving into the internals of Yii and how it manages validation of tokens, it compares the supplied token to the "trueToken" and if they match. https://github.com/yiisoft/yii2/blob/e83a86fd302dfaa3667894be2d734a9fcc854076/framework/web/Request.php#L1827-L1843

For this JS request, refer to the below debugging:

clientSuppliedToken = 3O_n-nJJCPYnmwGx7T-eX8hleY2afi6EW3lc3rjp
trueToken  = 48RPPwtft3JmK5WkSKnZ4fKfQiQFyh9TKEBaCfRp

(do note that I'm comparing the unmaskToken equivalent of the tokens). And for a normal request via Twig:

clientSuppliedToken = HrU_qLdHEzlgR60FdV5MroP09rBLx7J7h3_D522u|c20498d76b56ddb43cd84d804f6745570936b3561a5787f9d397470be88d4111HrU_qLdHEzlgR60FdV5MroP09rBLx7J7h3_D522u|1|$2y$13$n.Q/AWR985RBX4XX5J0t3eXqw0Hm40/BqWrxkDTRAE.9diQdDHjRi

trueToken = HrU_qLdHEzlgR60FdV5MroP09rBLx7J7h3_D522u|c20498d76b56ddb43cd84d804f6745570936b3561a5787f9d397470be88d4111HrU_qLdHEzlgR60FdV5MroP09rBLx7J7h3_D522u|1|$2y$13$n.Q/AWR985RBX4XX5J0t3eXqw0Hm40/BqWrxkDTRAE.9diQdDHjRi

Which would explain the reason for the failure. Looking further into things, I can see that getting the trueToken uses a cookie which is saved when first requesting the CSRF token, and fetched on subsequent ones. This is the difference with a headless request being that the "cookie jar" is empty upon each request, which I suppose is the nature of how it works, as there's no tie back to the headless end.

So my question is - is this a bug or expected behaviour? Should this sort of thing be allowed, or not?

[engram-design]

As a quick way to get a demo setup, feel free to check out https://github.com/engram-design/craft-headless-fetch which is using Vite. Just a simple form to submit to try and create an entry.

async submitForm() {
    const baseUrl = 'http://craft.test/';
    const formData = new FormData(this.$refs.form);

    // Fetch a fresh CSRF token
    fetch(baseUrl + 'actions/users/session-info', {
        method: 'get',
        headers: {
            'Accept': 'application/json',
            'X-Requested-With': 'XMLHttpRequest',
        },
    }).then((response) => {
        console.log(response);

        response.json().then((data) => {
            fetch(baseUrl, {
                method: 'post',
                body: formData,
                headers: {
                    'Accept': 'application/json',
                    'X-Requested-With': 'XMLHttpRequest',
                    'X-CSRF-Token': data.csrfTokenValue,
                },
            }).then((response) => {
                console.log(response);
            });
        });
    });
},

Use npm install then npm run dev to get started.

[engram-design]

Aha! I think I've figured it out. So the first thing is to allow the client-side to maintain a cookie session with Craft, so that the CSRF cookie can be stored (on the server). This can be done using the following as a guide:

Client-side JS

You can maintain a Same-Site cookie with the following adjustments, namely

• Using HTTPS as the endpoint
• Adding credentials: 'include' to the fetch call

engram-design/craft-headless-fetch@77687ce

CORS directives

You'll also need to update your CORS directives

// The headless site you're requesting from. Cannot be wildcard `*`.
Access-Control-Allow-Origin = http://localhost:3001

// required for `credentials: 'include'` to work with `fetch()`
Access-Control-Allow-Credentials = true

Access-Control-Allow-Methods = GET,HEAD,OPTIONS,POST,PUT
Access-Control-Allow-Headers = Access-Control-Allow-Headers, Origin,Accept, X-Requested-With, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers, X-CSRF-Token

You can also mess around with the sameSiteCookieValue general.php config setting, but I found I didn't need to, as it's null by default.

I'd certainly appreciate a second opinion on this with regards to security. My thinking is despite an off-site being able to start a cookie session, it's restricted by the Access-Control-Allow-Origin domain.

[brandonkelly]

Anonymous form submissions aren’t a particularly attractive target for an attacker, so you might just want to disable CSRF validation entirely for guest users. You can do that by adding this to your controller’s beforeAction() method:

public function beforeAction($action)
{
    if ($action->id === 'submit' && Craft::$app->user->isGuest) {
        $this->enableCsrfValidation = false;
    }

    return parent::beforeAction($action);
}

[engram-design]

This would be in the context of a plugin, where I don't believe you can add this sort of hook for, and disabling CSRF validation site-wide seems heavy handed.

Hopefully the above will be a resource if anyone needs it!