[3.x]: "Unable to verify your data submission" error when using CSRF token in an iframe

[KarlBishop]

What happened?

I need to embed a Craft form (using the Formie plugin) in an iframe on another website and, when I test it, the form submission hits a 400 error.

In the logs, it looks like this:

Jul 14 10:12:37 mycraftsite-php info 2023-07-14 10:12:36 [-][-][-][error][yii\web\HttpException:400] Unable to verify your data submission.
Jul 14 10:12:37 mycraftsite-nginx info 2023-07-14 10:12:36 [-][-][-][info][application] $_GET = []
Jul 14 10:12:37 mycraftsite-nginx info      
Jul 14 10:12:37 mycraftsite-nginx info     $_POST = [
Jul 14 10:12:37 mycraftsite-nginx info         'action' => 'formie/submissions/submit'
Jul 14 10:12:37 mycraftsite-nginx info         'handle' => 'myFormHandle'
Jul 14 10:12:37 mycraftsite-nginx info         'CRAFT_CSRF_TOKEN' => '••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••'
Jul 14 10:12:37 mycraftsite-nginx info         'siteId' => '1'
Jul 14 10:12:37 mycraftsite-nginx info         'fields' => [
Jul 14 10:12:37 mycraftsite-nginx info             'myField' => 'xxxx'
Jul 14 10:12:37 mycraftsite-nginx info         ]
Jul 14 10:12:37 mycraftsite-nginx info     ]
Jul 14 10:12:37 mycraftsite-nginx info      
Jul 14 10:12:37 mycraftsite-nginx info     $_FILES = []
Jul 14 10:12:37 mycraftsite-nginx info      
Jul 14 10:12:37 mycraftsite-nginx info     $_COOKIE = []
Jul 14 10:12:37 mycraftsite-nginx info Stack Trace:
Jul 14 10:12:37 mycraftsite-nginx info #0 /var/www/html/vendor/craftcms/cms/src/web/Controller.php(133): yii\web\Controller->beforeAction(Object(yii\base\InlineAction))
Jul 14 10:12:37 mycraftsite-nginx info #1 /var/www/html/vendor/verbb/formie/src/controllers/SubmissionsController.php(86): craft\web\Controller->beforeAction(Object(yii\base\InlineAction))
Jul 14 10:12:37 mycraftsite-nginx info #2 /var/www/html/vendor/yiisoft/yii2/base/Controller.php(176): verbb\formie\controllers\SubmissionsController->beforeAction(Object(yii\base\InlineAction))
Jul 14 10:12:37 mycraftsite-nginx info #3 /var/www/html/vendor/yiisoft/yii2/base/Module.php(552): yii\base\Controller->runAction('submit', Array)
Jul 14 10:12:37 mycraftsite-nginx info #4 /var/www/html/vendor/craftcms/cms/src/web/Application.php(293): yii\base\Module->runAction('formie/submissi...', Array)
Jul 14 10:12:37 mycraftsite-nginx info #5 /var/www/html/vendor/craftcms/cms/src/web/Application.php(602): craft\web\Application->runAction('formie/submissi...', Array)
Jul 14 10:12:37 mycraftsite-nginx info #6 /var/www/html/vendor/craftcms/cms/src/web/Application.php(272): craft\web\Application->_processActionRequest(Object(craft\web\Request))
Jul 14 10:12:37 mycraftsite-nginx info #7 /var/www/html/vendor/yiisoft/yii2/base/Application.php(384): craft\web\Application->handleRequest(Object(craft\web\Request))
Jul 14 10:12:37 mycraftsite-nginx info #8 /var/www/html/web/index.php(26): yii\base\Application->run()
Jul 14 10:12:37 mycraftsite-nginx info #9 {main}
Jul 14 10:12:37 mycraftsite-nginx info 122.58.155.255 - - [14/Jul/2023:09:12:36 +0000] "POST / HTTP/1.1" 400 155 0.039 "https://mycraftsite.ddev.site/myform" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/[114.0.0.0](http://114.0.0.0/) Mobile Safari/537.36" upstream

In Chrome dev tools, the Set-Cookie Response Headers for the iframe showed the warning:

This Set-Cookie header didn't specify a "SameSite" attribute and was defaulted to "SameSite=Lax," and was blocked because it came from a cross-site response which was not the response to a top-level navigation. The Set-Cookie had to have been set with "SameSite=None" to enable cross-site usage.

So, I found I can avoid the error using either of the following General Config settings:

1. 'sameSiteCookieValue' => 'None'
2. 'enableCsrfProtection' => false (it's also possible to disable CSRF tokens in Formie's Settings)

But I'm wondering: which of these options is the least insecure? Or is there a better option?

This blog post says when you set SameSite=None, "cookies...do nothing to protect you from CSRF attacks", so it seems like there's no point in using the first option and I should just disable the CSRF token. But I'd prefer not to compromise the security if there's another way around it...?

Craft CMS version

Craft Pro 3.7.61

PHP version

8.0.28

Operating system and version

Linux 5.10.0-0.deb10.17-amd64

Database type and version

MySQL 10.11.2

Image driver and version

Imagick 3.7.0 (ImageMagick 7.1.0-50)

Installed plugins and versions

• Amazon S3 1.3.0
• Asset Lockdown 1.0.0
• AsyncQueue dev-craft-3-backport-v2
• Blitz Recommendations 1.3.0
• CodeMirror 2.0.0
• Control Panel Body Classes 2.2.1
• Control Panel CSS 2.4.0
• Control Panel JS 2.4.0
• Dashboard Begone 1.0.1
• DB Dump 3.0.3
• Element API 2.8.6.1
• Formie 1.6.27
• Lockout 1.0.2
• MatrixMate 1.5.0
• Matrix Toolbar 1.0.6
• Reasons 2.3.1
• Redactor 2.10.10
• Relax 1.0.1
• Retcon 2.6.0
• SCSS 1.0.0
• Servd Assets and Helpers 2.9.6

[brandonkelly]

How exactly are you rendering the form? Is the iframe page being rendered by the same Craft CMS install?

[KarlBishop]

The iframe is hosted on an external, non-Craft, website. It's loaded by JavaScript, something like this:

const container = document.getElementById("iframe-container");
const iframe = document.createElement('iframe');
iframe.src = 'https://mycraftsite.ddev.site/myform';
container.appendChild(iframe);

Within the iframe we have the Craft site. We're setting a Content-Security-Policy header, so the iframe can render on the external site:

{% header "Content-Security-Policy: frame-ancestors 'self' https://myexternalsite.com;" %}

The form within the iframe is rendered like this:

{% set formieForm = craft.formie.forms({ handle: 'myForm' }).one() %}

<form id="{{ formieForm.handle }}">
  {{ actionInput('formie/submissions/submit') }}
  {{ hiddenInput('handle', formieForm.handle) }}
  {{ csrfInput() }}
  {{ hiddenInput('siteId', currentSite.id) }}

  {% for field in formieForm.getFields() %}
    ...
  {% endfor %}
</form>

The form submits to the same domain where it's hosted. It's submitted using the Fetch API, like this:

(async function () {
  try {
    const formData = new FormData(document.getElementById('{{ formieForm.handle }}'));

    const response = await fetch('/', {
      method: 'POST',
      headers: {
        'Accept': 'application/json',
        'X-Requested-With': 'XMLHttpRequest'
      },
      body: formData
    });

    if (!response.ok) throw new Error(`Response not OK, status: ${response.status}`);
    
    // Do stuff...

  } catch (error) {
    console.log('Fetch error: %o', error);
  }
})();

We're not currently caching the page, but I've tried including Formie's refresh-token code as well, in preparation for caching, and got the 400 error either way.

Weirdly, there's no error when testing in Firefox. But we have seen it on multiple devices using Chrome, Safari and Edge.

[brandonkelly]

Would it be possible to serve the form from the same domain (even if it’s a different subdomain) as the top-level site?

[KarlBishop]

No, can't do that unfortunately - the iframe needs to be embeddable on many external websites for which we don't own DNS settings.

I spoke to Formie's support team and they said they didn't think embedding in an iframe should be an issue, because I'm submitting the form on the same domain where the CSRF token was generated.

But they also said, it should be fine to switch off the Formie setting to "Enable CSRF Validation for Guests", because CSRF tokens are really only about protecting authenticated users and my form is intended for public (aka guest) submissions. So, seems like I can live without the CSRF token if it's not really adding anything.