Advisory: Webflow's recently-released bot protection may break "complex" sites

Initial disclaimer

This likely won’t apply to most of Webflow sites, but I’m leaving this post here for anyone that might have a similar edge-case. I’m also going to use this this post as a report that I will later send to Webflow.

High-level of the issue
Webflow’s recently-released bot protection acts on the client-side, and if your form gets “detached” from the DOM and later reattached (example: a form inside a vue app), and you run Webflow’s reinitialization sequence (window.Webflow && window.Webflow.destroy(); , ...ready(), ...init() ...), the form will forever be disabled, preventing not only submissions to Webflow, but also to any other service and any JS listener that waits for the form’s submit event.

Abstract steps-to-reproduce

  1. Create a webflow project
  2. Add a div with id vue-app
  3. Inside that div, add a form
  4. To the form element, add a event listener with an attribute: v-on:submit=handleFormSubmission
  5. Import Vue2 to your site (ex: <script src="https://cdn.jsdelivr.net/npm/vue@2.7.16"></script>)
  6. Create the JS code necessary to create a vue app, and set it to be rendered on the #vue-app container:
  var app = new Vue({
    el: '#vue-app',
    mounted(){
      // Reinitializing Webflow animations and etc after initial render;
      window.Webflow && window.Webflow.destroy();
      window.Webflow && window.Webflow.ready();
      window.Webflow && window.Webflow.require('ix2').init();
      document.dispatchEvent(new Event('readystatechange'));
    },
    methods: {
      handleFormSubmission(e){
        e.preventDefault();
        e.stopPropagation();

        console.log("'Hello Webflow!'")
      }
    }
  })

If you run the steps above and go check your website, you will notice that the form can no longer be submitted, and you get some Turnstile-related errors in the console.

Read-only and live link available.

The error seems tightly connected to some “timing” aspect as well: Live link will only show you the error if you have the console window opened and you disable debugging breakpoints in the sources tab.

The possible solutions

  • Webflow either implements some cleanup of Turnstile inside the Webflow.destroy method as well; or
  • Webflow reworks their implementation of Cloudflare Turnstile (what they use for Bot Protection) to something that would never disable the form, but only act inside the submission handler from Webflow JS. This way, what Webflow implemented would only protect Webflow’s “area”, and not prevent the form-submission event being sent to other services that might rely on the submission event as well, such as the website’s own code, or submission handlers from third parties such as CustomerIO form listeners.
3 Likes

Hey Jean, thanks for the post. Could you point me in the direction of any place where Webflow mentions their Turnstile integration? We are having some issues with it but can’t find documentation o reference.

In our case it is sending a Turnstile hash or encrypted string along with the actual form responses to our CRM.

Hey @carlos.zaldivar, Webflow generally doesn’t document any internal mechanisms like Webflow.js features, and Turnstile is a very new addition as well.

For your situation, you might be able to switch off bot control, or you might just need to filter that field out in an automation, it depends on how your integration with your CRM is setup.

1 Like

We have an automated script that goes through one of our forms to ensure its working all the time, this change breaks it so now we’re unsure how to fix this…

In a way, that script is a bot, so it makes sense it won’t work. What you could do is make the script remove the disabled attribute from the form submit button, and test things… And account that you will likely receive an error, but as long as that error is a bot-related error, you’re fine

2 Likes

Thanks @Jeandcc!

It also appears any sites using Finsweet filters/integration, combined with the Webflow Bot Protection toggled on - will also result in the Cloudflare Turnstile Error loop. Turning Bot Protection off obviously resolves the issue.

3 Likes

This is BIG Craig! Lots of people have that setup! Thanks for flagging it. I’ll add this to the original post.

1 Like

Hi @Jeandcc! Would you be able to watch this Loom and let me know if this aligns with what you are seeing? From my perspective this is a Turnstile issue but let me know if that is what you are seeing.

In general these are my testing steps:

  1. Open your browser developer tools
  2. Go to Vue page example (this site has turnstile on)
  3. You’ll see a debugger statement be hit (this is from Turnstile)
  4. Click “Play” to continue execution
  5. Check your browser console
  6. You will see [Cloudflare Turnstile] Error: 600010.
  7. Close your browser dev tools
  8. Reload the page
  9. You can now submit the form because there is no turnstile error

Wow, I’ve had this problem with my site and several of my features breaking. I’m so glad you mentioned this issue too. I use Finsweet a lot and can confirm that turning off Bot protection in site settings resolved my problems.

Is there a better solution? There have to be a lot of sites that have come upon this problem.

At present there is no workaround other than turning bot protection off. Alternatives would be to either use another javascript library (as opposed to Finsweet), or use a third-party form builder (as opposed to Webflow’s native forms).