Conflict with Cloudflare Web Application Firewall

[swissspidy]

If you are coming from the support forums or encounter the following issue, please read carefully.

This is a tracking ticket for the work on ensuring Web Stories for WordPress does not cause issues with the Cloudflare Web Aplication Firewall (WAF) or similar solutions.

Rules that so far have been identified as possibly causing conflicts:

• Cloudflare Specials > 100173 XSS, HTML Injection - Script Tag
• OWASP mod_security ruleset 981176

A similar conflict exists with Sucuri's WAF.

Who's affected?

The Cloudflare WAF is available to Pro, Business, and Enterprise plans.

How do I know I am affected?

You are likely affected when using Cloudflare's WAF offering and you are unable to save or publish stories using Web Stories for WordPress.

Workaround

Cloudflare:

Add a custom Firewall rule to disable the WAF for any Web Stories-related REST API requests, like so:

Sucuri:

Add wp-json/web-stories to the allowlist in the "Whitelist URL Paths" section.

What is being done to fix this?

We are still investigating this issue and will update this thread with any new findings.

• Check if REST API is fully functioning when opening the editor (Status Check: Add REST API endpoint #4790)
• Improved error messages if REST API requests fail (Add Context to Failure to Save Error Message #1033)
• Implement experimental workaround in the plugin (Base64-encode HTML markup over the wire #4859, Make WAF workaround opt-in for now #5038)

How can I follow progress on this issue?

Subscribe to this issue using the "Subscribe" button in the sidebar:

---

User reports so far

• https://wordpress.org/support/topic/failed-to-save-the-story/
• https://wordpress.org/support/topic/cloudflare-waf-block-json-issues/
• https://wordpress.org/support/topic/failed-to-save-the-story-2/
• https://wordpress.org/support/topic/failed-to-save-the-story-error/

[swissspidy]

My first assumption was that the WAF kicks in because we save the full AMP HTML markup via the REST API, but preliminary testing by @LuckynaSan & @ernee showed that this doesn't happen in all cases. For example, some templates can be used and previewed/published just fine. But creating a blank new story fails every time with a 403 error.

I haven't done any in-depth testing with various configurations yet myself, but I found some valuable old threads on this when Gutenberg faced the same issue:

• CloudFlare blocking REST API PUT Request (Draft Doesn't Get Saved) (solved by an update from Cloudflare) WordPress/gutenberg#2704
• CloudFlare can unexpectedly block REST API requests WordPress/gutenberg#3527
• https://blog.cloudflare.com/protecting-everyone-from-wordpress-content-injection/ (mentioned by 2704)

Then, the OWASP ModSecurity Core Rule Set (CRS) added some exceptions for Gutenberg:

• Kindly, consider adding support for Wordpress Gutenberg editor. SpiderLabs/owasp-modsecurity-crs#1232
• wordpress: gutenberg support SpiderLabs/owasp-modsecurity-crs#1298

[swissspidy]

In version 1.1.0 of the plugin there will be an experimental workaround for this. To enable:

1. Add define( 'WEBSTORIES_DEV_MODE', true ); to your wp-config.php file
   (somewhere before the /* That's all, stop editing! Happy publishing. */) line)
2. In your WordPress admin, go to Stories -> Experiments
3. Toggle the WAF Compatibility checkbox and save the changes.
4. Create a new story!

[swissspidy]

Closing in favor of #5059

[mateusnds]

If you are coming from the support forums or encounter the following issue, please read carefully.

Thank You