CloudFlare blocking REST API PUT Request (Draft Doesn't Get Saved) (solved by an update from Cloudflare)

[ahmadawais]

[UPDATE: Cloudflare rolled out a fix for problems with the WP0025B rule 8-Aug-2018, please update.]

I have started to try Gutenberg on a production site and it is not working. The site is new and has no other plugin installed. Looks like the PUT request is not working.

I am using the latest version of Gutenberg 1.1.0 available in the WP Repo. I have also tried this on two other sites and same error. I thought I should report it here?

[ahmadawais]

@pento thanks for explaining all that. It makes much more sense to keep it closed that way.

For anyone looking for a quick fix to this, just change the REST API base. It was suggested to me by Fritz Walther.

/**
 * Modify URL base from `wp-json` to 'wpjson'.
 *
 * Save the permalinks again, Settings > Permalinks.
 * Access your API at site.tld/wpjson/wp/v2.
 *
 * @param String $slug The Slug.
 * @return String
 * @since 1.0.0
 */
function aa_api_slug( $slug ) {
    return 'wpjson';
}

// Hook.
add_filter( 'rest_url_prefix', 'aa_api_slug' );

Peace! ✌️

[hExPY]

@ahmadawais do you know if this setting result in any security issues?

[ahmadawais]

Your new API URL will not be protected the same way old one is by CloudFlare.

[pento]

CloudFlare have rolled out a "testing fix" for this: it's currently still blocking the requests, but they're gathering logs. Assuming it all looks good on their end, they intend to roll out the fix properly next Monday.

Naturally, that's way too long to wait, so I'm going to investigate workarounds, so at least y'all can see why it's not working, and what your options are. 🙂

[pento]

Cloudflare rolled out a fix for this earlier today.

@ahmadawais, @roylindauer: Are you still seeing this issue after removing any workarounds you have in place?

[hExPY]

@pento i reverted all changes and it works perfectly now. Thx for keeping in touch with Cloudflare! :-)

[kurtschlatzer]

Thanks to Cloudflare's fix, my WAF log filled up with garbage "whitelist" entries for our folks working in the wp-admin. Grrrrr. Gutenturd.

[caraya]

@pento I have no workaround on either my WordPress site or Cloudflare and I'm still experiencing the editing issue.

[pento]

@caraya: Is your Cloudflare WAF log indicating which rule is causing requests to be blocked?

[caraya]

It's blocking on 100030 because it's challenging the request.

It appears that Cloudflare's patch wasn't fully propagated yet. It is working.

Sorry for the noise

[pento]

Thanks @caraya, this seems to be a different problem to the one Cloudflare has fixed. Rule 100030 is meant to block XSS probing attacks, I would guess that Cloudflare is interpreting the block format (particularly is it contains HTML comments, JSON, and string escaping) as XSS risks.

Which site are you seeing this on, @caraya? I'll follow up with Cloudflare and get them to investigate.

[ghost]

The issue is still happening as well on our Wordpress site, disabled both rules in cloudflare as per the guideline but doesn’t seem to have an effect. Actually some rules in cloudflares WAF seem to not actually disable I’m not sure but in terms of whitelisting as well I’ve whitelisted all of Taiwan just out of frustration because cloudflare kept blocking my ip despite whitelisting all Taiwanese ips. Anyways hopefully there is a fix for this soon.

[caraya]

@pento the site is https://publishing-project.rivendellweb.net/

I have a ticket open with Cloudflare on this issue. I have not had an ETA for resolution, but more pressure doesn't hurt :)

[ghost]

How is this issue closed? I’ve disabled both rules in Cloudflare Pro plan and the rules are still blocking the Rest Api

[pento]

@kesenwang: The firewall log should indicate which rule is blocking requests: could you have a look and see which one it is?

[daniellepinto81]

Don't use cloudflare. Use Siteground. Have this issue. Disabled ALL plugins. Use default Wordpress theme. Console shows this error: POST https://tcwprintshop.com/wp-json/wp/v2/posts/1326 403 ()

Network shows similar 403 error: 1326 | 403 | fetch | index.js?ver=1536783125:1

[caraya]

@mikepinto81 do you run a firewall? Do your server logs report anything else other the 403 error? This may or may not be a Gutenberg problem so the more information you can add to the report the more it'll help troubleshoot.

[daniellepinto81]

I actually had Siteground look into it and they couldn't figure it out (after elevating the issue) and said to contact the plugin author. There are no errors in the server logs and I do not run any type of firewall (that I know of unless siteground does by default?) I forgot to add that Pages update and post JUST FINE. It is ONLY posts that have the problem when Gutenberg is active. They update fine when Gutenberg is disabled.

---

From: Carlos Araya notifications@github.com Sent: Thursday, September 13, 2018 3:43 PM To: WordPress/gutenberg Cc: mikepinto81; Mention Subject: Re: [WordPress/gutenberg] CloudFlare blocking REST API PUT Request (Draft Doesn't Get Saved) (solved by an update from Cloudflare) (#2704)

@mikepinto81https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmikepinto81&data=02%7C01%7C%7C8626e1a0d9294dbfa7c008d619b11e16%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636724645829338048&sdata=0oQZtXXe7Qy1HCFLSq5SmL0KrgeaZMryfEsuSYBcAvw%3D&reserved=0 do you run a firewall? Do your server logs report anything else other the 403 error? This may or may not be a Gutenberg problem so the more information you can add to the report the more it'll help troubleshoot.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWordPress%2Fgutenberg%2Fissues%2F2704%23issuecomment-421128678&data=02%7C01%7C%7C8626e1a0d9294dbfa7c008d619b11e16%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636724645829338048&sdata=aydSF1xNtuzrLSP0T8ds5TOTNJQMrOLZ37Cox%2FXgDuI%3D&reserved=0, or mute the threadhttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAKztPgeSvV4xJKIe3cVR-pTiY7qR37oJks5uarVFgaJpZM4PRCw1&data=02%7C01%7C%7C8626e1a0d9294dbfa7c008d619b11e16%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636724645829338048&sdata=4d%2BgVDPkY7u2sfM78o183gTvJwiOZ%2BPN%2F1loiZ%2Bz9zE%3D&reserved=0.

[JustinSainton]

@mikepinto81 Have you looked at your htaccess file? See my similar issue here: https://github.com/WordPress/gutenberg/issues/2704#issuecomment-329231370

[daniellepinto81]

@JustinSainton unfortunately we even tried resetting to default htaccess and no difference. What is really confusing is how this only affects Posts and not Pages.

[Tomplanmytrip]

Hey Guys!

I'm using Cloudflare Pro and Gutenberg

I disabled WP0025A and WP0025B as they recommend but it's still not working

I've the same pb than Caraya

Rule ID	Action Taken	IP Address	Loc.	Host	Date
100030	Challenge	www.tomplanmytrip.com	22 minutes ago	Details

Any updates?

Thx!

[pento]

Thank you for the info, @Tomplanmytrip. Rule 100030 is intended to block XSS probing attacks, it seems like Cloudflare is mistaking the post_content combination of HTML comments and serialised JSON as being an attempt to create an XSS attack.

This is going to be a little trickier to fix, I'll raise it with Cloudflare to get their input on it.

[Tomplanmytrip]

Ok thank you Pento :)

I've got the following mistakes in my developer tool

Failed to load resource: the server responded with a status of 400 ()

autosaves:1 Failed to load resource: the server responded with a status of 405 () -> I get the following message if I click on it: script>var wpgmza_google_api_status = {"message":"Enqueued","code":"ENQUEUED"}

start:1 Failed to load resource: the server responded with a status of 400 () -> I get the following message if I click on it: {"status":400,"error":"BadRequestError: Missing content-type"}

Is my plugin WP-map the problem?

Edit: Yes, Wp-Map is the issue. It works now. Any idea how to fix it?

Also, I have the similar problem If I'm using A getyourguide widget with the following code:

[pento]

I'd be interested to know if disabling a particular plugin makes the problem go away, but either way, we do need to figure out a way for Cloudflare to not be blocking legit requests. 🙂

[Gatewayy]

The only thing that has worked for me so far is to whitelist the IP from the WAF area of the Firewall settings from the CF web admin.

[caraya]

Do your web server error logs give anything related to this? I don't think this is a Cloudflare-related issue. I experienced it too but mine was caused by a mod_security my host did without telling me :(

[daniellepinto81]

My issue I found was caused by the fact that I migrated the site from another install. The previous install had Wordfence installed and was using a php.ini var (auto_prepend_file). After uninstalling Wordfence I didn't realize there was still the php.ini file auto_prepend_file still pointing to the old install. This was causing the issue. I use Siteground and it took 3 different support people to help me hunt this down as for some reason the error logs were not giving hints to where the block was coming from.

[Tomplanmytrip]

@Gatewayy Thx :) Do you mean I should Whitelist my IP?

Also, WP-Map wasn't the only problem.

1 hour later, I couldn't update my post, neither use the autosaves. So I lost my post. I uninstalled Gutenberg for now.

@caraya - I dunno. Is it working now for you?

[caraya]

Yes, it did.

That's why I asked about your regular server error logs, it may say something other than Gutenberg or Wordpress related. If you can track the logs or have your host help you with that it might be helpful to troubleshoot the problem.

I would hold off whitelisting your IP (there will be many you'll have to whitelist if you choose to do so) until you test Gutenberg in your installation after the Wordfence fix.

Whitelisting all of the US as @gatewayy did opens your server all kinds of attacks. His issue is also specific to Cloudflare firewall so until you test and are sure it doesn't work, it won't be necessary to whitelist anything.

[moyvera]

@caraya please keep this thread updated if you have any news. I'm facing the same issue trying to use instagram embedded photos or something from a trusted source. It makes sense to block those requests for cloudflare but should be a section where we can add trusted sources.

[Related to XSS attack]

[bartclaeys]

Issue seems not resolved yet, I am experiencing it today with the latest Wordpress version:

• Wordpress: v5.0.1
• Cloudflare plugin: v3.3.2.
• Gutenberg plugin: v4.7.0

Update: Solved! Problem was caused by custom rule in .htaccess

[ensemblebd]

I have read in several places that the fix is to use a paid ssl cert from cloudflare, not their universal free one. I'm unsure how precisely that correlates. My site doesn't have an htaccess rule to remove that would resolve this. httpd.conf is standard as well. And I do not have any firewall rules, page rules, or other non-basic settings in the pro cloudflare account. Turning off cloudflare's DNS for the site at a whole doesn't even solve the issue.

Am not using the CloudFlare wordpress plugin.

Server response headers still indicate a cloudflare response:

cache-control: no-cache, must-revalidate, max-age=0
cf-ray: 48b2d7269******-DFW
content-encoding: br
content-security-policy: upgrade-insecure-requests;
content-type: text/html; charset=UTF-8
date: Tue, 18 Dec 2018 16:00:09 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expires: Wed, 11 Jan 1984 05:00:00 GMT
link: <https://some.website/wp-json/>; rel="https://api.w.org/"
server: cloudflare
status: 404
vary: Accept-Encoding,User-Agent

[ensemblebd]

For the api request: POST -> /wp-json/wp/v2/pages/1234 (page/post update operation, note: autosave has the same issue)

Problem is here: /<root>/wp-includes/rest-api.php for rest_api_loaded() on Line 274 It exits immediately due to: if ( empty( $GLOBALS['wp']->query_vars['rest_route'] ) )

Therefore the request never executes. Contents are:

["query_vars"]=>
  array(2) {
    ["attachment"]=>
    string(2) "v2"
    ["pages"]=>
    string(4) "1234"
  }
  ["query_string"]=>
  NULL
  ["request"]=>
  string(24) "wp-json/wp/v2/pages/1234"
  ["matched_rule"]=>
  string(30) ".?.+?/([^/]+)/pages(/(.*))?/?$"
  ["matched_query"]=>
  string(24) "attachment=v2&pages=1234"
  ["did_permalink"]=>
  bool(true)

On a working site, it looks like this:

["extra_query_vars"]=>
  array(0) {
  }
  ["query_vars"]=>
  array(1) {
    ["rest_route"]=>
    string(16) "/wp/v2/pages/857"
  }
  ["query_string"]=>
  NULL
  ["request"]=>
  string(23) "wp-json/wp/v2/pages/857"
  ["matched_rule"]=>
  string(14) "^wp-json/(.*)?"
  ["matched_query"]=>
  string(33) "rest_route=/wp%2Fv2%2Fpages%2F857"
  ["did_permalink"]=>
  bool(true)

Am working on digging deeper. Would appreciate any insights from those that know what they're doing.

• Edit: Solution was to modify the wp_options database table value for option_name = 'rewrite_rules', simply moved the offending serialized regular expression below the position in the array of the wordpress default api routes. I tried flushing, both using this, and this, and by using the frontend permalinks [Save Changes] op. To no avail. Had to manually modify it myself in the database.

[mike-pt]

I'm not sure what changed but I had to whitelist a few rules and yet this still is getting blocked now it the following rules::

And was worst before:

I can't simply go about disabling every of this rules, most are not even listed as possible false positives :/

[mike-pt]

Aslo the draft is autosaved, its only updating that fails now

[caraya]

@mike-pt do the Cloudflare error logs show anything? how about the server logs? Check that before disabling rules as it may not be the reason why it's not working.

Try disabling your plugins and test if it works.

If it does try activating the plugins one by one until it stops working.

If it doesn't then developers will need logs from Cloudflare and your server to see if they can troubleshoot it further.

[mike-pt]

Error logs from cloudflare? I don't think they provide that, however I have pasted the screenshot from cloudflare blocking this, and I do see a 403 on the browser none of this are the WP WAF rules, but OWASP, and a lot of those are not common false positives!

This as to do with how gutenberg uses the JSON API when updating posts, so maybe the problem is on the API side still it hits at least the rules I've pasted above! I don't think plugins have anything to do with this, since its clear that the request is made when using gutenberg, as a workaround the classic editor is in use, no issues there!

[caraya]

It's the Web Application Firewall event log, not error log, my bad.

• Under Firewall scroll down
• Select Web application firewall
• Look at the Firewall Event Log.
• Does it report anything under that tab that doesn't appear in the images you pasted?

If the JSON API is not working that's usually a WAF issue, not IP firewall issue. At least it was for me before the Gutenberg team solved it. It may also be related to PHP Security plugins that are blocking things without you realizing they are (this has also been reported as an issue in this and other threads)

[mike-pt]

Yeah and that's exactly what I've pasted above... I never mentioned IP blocks only WAF rules.

This still happens, I have to disagree on the PHP security plugins cause the screens I posted are from Cloudlfare WAF log and its clearly blocking things, based on a few OWASP rules (note that none are from the Wordpress specific rules in this screenshot)

[mike-pt]

@caraya I feel like you took this too personal, I'm not rejecting any solutions (but so far no solution was really provided, but you did provide useful opinions on possible issues that could be related, and let me thank you for that).

With that sad if I disagree with something and provide an explanation as to why I don't see why that means I'm disagreed in every possible solution, and if it felt like so that was surely not my intention, I do have the right to disagree and I think it would be unfair to not be honest about it, now obviously there needs to be a reasoning for it and I did provide it.

Now still back to the PHP security Plugins, the screens I posted are from cloudflare, NOT wordpress, cloudflare is blocking the request based on the rules I've posted as a screenshot, the request doens't even get to the host, so how could a php security plugin do it?

I'm happy to share more examples / more details on what cloudflare is blocking to try to understand the problem. Cause really my question is only about WHY this requests are blocked and match this many WAF rules, is many cloudflare being nuts and the plugin is not really "doing anything wrong" or are this actually legit and the way gutenberg does the update (via the API should be more safe) ? That's the real question here, we are still in the phase where I'm just want to clarify why cloudflare blocks it (which again might even be a cloudflare issue not gutenberg) .

P.S. If you felt offended at any point it was honestly never my intention, I simply was replying directly and honestly to you're comments, I hope this helps clarify things!

[caraya]

@mike-pt

If you follow these and other issues with the plugin not updating you'll see that there are multiple reasons why this happens. Your screen is not what I expect to see when I troubleshoot this type of issues and I don't think I mentioned you're disagreeing, it's your right :).

Since you've confirmed that this is the web application firewall then, to me, it's a new error but, like the others, I'm guessing it doesn't like the way Gutenberg is mixing comments and JSON and considers it an attempt at SQL injection. So yes, it's likely that new modsecurity rules are making it not work but I'm surprised other people are not having the same issue... it still may be something being injected between your client and the firewall (ads, malware, long etc)

@pento

This is a new type of WAF error in Cloudflare, It's reporting a different type of error for protection against SQL injection but it's none of the previously reported errors. It is triggering OWASP core rules, specifically something in the APPLICATION-ATTACK-SQLI group of rules (Github link),

Don't know why it would be triggering now, but Cloudflare uses OWASP as their default module

[mike-pt]

To clarify that screen is form:

Firewall Event Log

Requests affected by both IP Firewall and Web Application Firewall (WAF) rules.

[From Cloudflare] After selecting the corresponding block.... I did crop it to filter out the IP etc... and simply show the "triggered/matched" rules.

But yeah what surprised me is that cloudflare lists APPLICATION-ATTACK-SQL (and this didn't not happen in past releases, unfortunately I can't say precisely when, I test gutenberg when it was beta and it trigger some cloudflare WordPress specific waf rules, which back then was their own issue and they fixed ) and after updating this WP install, changing form classic editor to Gutenberg this start happening, but with the rules that are posted, and as you say are core OWASP rules! So it seems to be a bit more serious (or maybe cloudflare bug!?!), so I defiantly appreciate if someone can look into it and make sure all is good. And I'm also surprised no one else commented with the same results yet.

Also I haven't tried gutenberg again after the day I posted this, it was disabled in the prod but I should probably check again if this is still happening to clear out the possibility of a cloudflare bug analyzing this.

[jordif]

Hi,

I'm facing the same issue with Cloudflare and the OWASP ruleset. If i turn the OWASP rule set off (while keeping the Cloudflare rule set on), everything works fine.

I've done some tests adjusting the OWASP sensitivity (high/medium/low): the longer the post content, the greater the chances of the request being blocked.

I haven't really tested this super thoroughly, but I also think that having a lot of markup increases the chances. I had a page with a table and many links in it. I could not update it (OWASP rule was triggered). After cleaning it up a little bit (removing target="_blank" an rel="noopener" from the links) it did get saved.

Cheers,

[jordif]

I have noticed something else: autosaves do work (and the json is almost the same), it's the publish/update request that gets blocked...

[mike-pt]

@jordif out of curiosity which rules does it it for you?

[jordif]

@mike-pt Mainly "SQL Injection" and "XSS attack" rules.

It seems the OWASP team are already aware of this and working on a solution.

https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1232

So I'm afraid we'll have to wait (and whitelist IPs in the meantime)

[ausworkshop]

Hi Guys, any news on this? I haven't been able to edit or preview since Guttenberg came along and really messed up my life. I'm with Cloudflare and WpEngine, was chatting to them for about an hour last night then today found this post. In the meantime I still have no idea how to fix or if it will one day fix itself. So after 15 years with my website I now can no longer edit it or update it but hey at least it's still working for now!

I have a business to run, it relies entirely on my website working and don't have time for all this tech stuff slowing me down all the time. I've almost lost hope in WordPress altogether after the trouble I'm having now and I really can't afford to have my site totally re-built on another platform. It's times like these I wish I was still using a simple Godaddy builder or something. I can't afford the amount of time I'm spending on WordPress just to keep it working. I don't ask too much, just a simple site that I can edit and update. What year are we living in?

Any advice or direction on what I need to do or who I need to reach out to for help would be appreciated. Or should I just go back to classic and forget about Guttenberg until it works one day with my existing setup? If Cloudflare are still working on it then how much longer will it take?

[ensemblebd]

All this banter about the politics of problem solving and who is to blame is ridiculous. This is GitHub, not youtube. People writing drivel on here does nothing but hurt people like @ausworkshop

The problem is that Gutenberg has an absolutely useless generic error message, offering a wide array of solutions.

Identification of issue

1.) Identify the network request in Chrome developer console (big red line). 2.) Copy the url it requested into your web browser. 3.) 500? 403? 401? 4.) Is it wordpress derived, or external (cloudflare)? 4.1.) Look at Step 1's network response headers. Do you see Apache, PHP, or IIS headers from your server? How about the CF ray? --> If no: Turn off cloudflare (DNS level or global switch on dash, and disable firewall). Recheck 1-5. --> If yes: Problem very likely has nothing to do with cloudflare (as was my case). Why not edit your index.php and throw out a header() call followed by a die() temporarily to verify (against same previously failed url)? That by itself verifies your entire host apparatus (web.conf / htaccess rewrite, cloudflare dns + firewall + routing, php) For POST op requests, use Postman. Same process.

Recap

To clarify, this is a closed issue, and you likely will not find help on here. Plus the original issue was resolved long ago.

But the above generic self-help debugging steps are a first step to identifying the actual problem for Gutenberg's useless error message.
Good luck

[ausworkshop]

Thanks ensemblebd, I've passed your debugging steps on to WPEngine who were looking into it further for me and have opened a support ticket. I'll get back on here and let you know if I find out what they did to solve it.

[chrissy-dev]

@ausworkshop Did you ever get this sorted? I've been working with WPEngine for over a month on the exact same problem.