Caching problem (APO) - bypass not working


I have a problem with a plugin I use on a site. Its a recipe card plugin: Wordpress Recipe Maker.
I use Cloudflare APO.
Here is the problem:

  • When clicking on the star of a recipe, in order to rate it, there should pop up a message box saying: “Vielen Dank für deine Bewertung!”, and the rating should be counted.
  • When clicking the stars however, there doesn’t pop up the message box and ratings are not being counted.
  • When going on development mode, the recipe plugin works perfectly.
  • When purging the Cloudflare cache the plugin works like its supposed to (pop up message box showed and rating counted)
  • After about 24 hours after purging the cache, the problem shows again.
  • So i tried to bypass the js files that are necessary for the recipe plugin:
  • However, Cloudflare is still caching these js files. I tried bypassing them with Cache rules, Page rules and WAF. Nothing works.
  • When checking the js in chrome dev tools (network), it says: “Provisional headers are shown. Disable Cache to see full headers.”
  • I don’t use rocket loader and i have already tried to exclude js from minification - doesn’t solve the issue.

So how can i bypass the mentioned js or any other ideas to solve the problem?

Thank you for your help!


Hello Sarah,

First you need to identify what’s the exact cause of the issue you’re facing. A cached JS file doesn’t sound like something that would lead to your recipe cards not working properly.

Please visit your site with Dev Tools open (F12 on Chrome/Win) when you know it’s not working properly. On the Network tab, check for any status code 403. If a subrequest is being blocked (403) by Cloudflare:

  1. Wait a few minutes
  2. Go to Dashboard > Security > Events. If the request was in fact blocked by Cloudflare, you should find an event related to that block action. Depending on your site traffic, you may need to filter by IP address, User Agent, URI Path, etc. to find it. Check the “Service” that blocked it.
  3. If this was
    a) Bot Fight Mode, disable this feature.
    b) Super Block Fight Mode, create a WAF Custom Rule to Skip it for the specific situation, with relevant conditions such as the URI Path and the visitor’s IP, for example;
    c) WAF Managed Rule, you need to create a WAF Exception for that rule. See: Add a WAF exception in the dashboard · Cloudflare Web Application Firewall (WAF) docs
    d) WAF Custom Rule, you need to edit it accordingly.

If there are no 403s, but instead 404s or 5XX errors, please post back more details.

1 Like

Thanks for your response, cbrandt! :blush: :pray:

I got closer to understand the problem, however I could not really solve it.

I found a 403 that only shows when Cloudflare cache is enabled and not purged within the last 24 h.
This 403 is indeed connected the one js I already suspected and mentioned above.
However, in Cloudflare/Security/Events it does not show up, so I am not sure, how this 403 is connected to Cloudflare.
See here:

Any ideas what could cause this 403?
I already turned off the Bot Fight Mode for a few minutes, to see whats happening, but nothing changed. Should I maybe keep it turned of for longer to see results? I am afraid, turning it of will be a security risk?!



It’s not directly blocked by Cloudflare. but by the website origin server.

This may be related to nonce, which is issued by WordPress or a plugin and normally has a default duration of 12 hours. So when you cache requests for over 12 hours, your nonce gets cached, and subrequests following that period are blocked by WordPress.

Indirectly, yes. But the caching of those 2 JS files you’ve mentioned should not be causing this. Instead, these files make a sub-subrequest for a REST API endpoint, which is the one being blocked by your origin.


Try to create a Cache Rule for the above path to have it bypassed, so that every time a user clicks on the card to star-rate a recipe, it fetches the file again. Whether or not this will work depends on how your website is set, and you may want to check your plugin’s support forum for further help, and ask them about how to properly cache (or not cache) the related files.

As cbrandt already mentioned, that 403 isn’t coming from Cloudflare. If you click on the red “analytics” text, the request window should show up. In that, there should be a “Response” section that would show what the 403 block page would look like. At 933 Bytes, that’s pretty bare-bones, and not coming from Cloudflare.

1 Like

Thank you cbrandt!! :pray:
I’ve tried the solution you’ve suggested. Unfortunately it didn’t work, but your explanation and background information guided me into a direction where I could find the solution for the problem.

I tired the following and it seems to work:

… I created a Page Rule-

mysite . com/*

Edge Cache TTL = 8 Hours (Because Nonce Validity is less than 12 Hours in General so better keep 8 hours to be in safe side)
Found it here.

I hope there is no drawback to performance or security by reducing the Edge Cache TTL to 8 h…?
What do you think?


Hi, Sarah,

I’m glad you’ve managed to solve the issue, it should work.

Not in any significant way, IMHO.

Thank you!

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.