Managed/JS Challenge blocks CORS

Answer these questions to help the Community help you with Security questions.

Have you searched for an answer?
Yes

Please share your search results url:

When you tested your domain using the Cloudflare Diagnostic Center, what were the results?

With Managed Challenge enabled, https status fails with your request failed with a response status of 400 or above and site mixed content returns response_non_200.

When Managed Challenge is disabled, these both pass.

Describe the issue you are having:

When Managed Challenge is enabled with expression (ip.geoip.country ne "RU") or (ip.geoip.country ne "CN") or (ip.geoip.country ne "KP") (these countries are already blocked in a previous rule) then I get the results as mentioned above, and CORS headers are blocked on my site. When it is disabled, CORS headers are fine.

What error message or number are you receiving?
In console in the browser (no adblocking/ublock or similar enabled):
Access to 'https://sub1.mydomain.com' from origin 'https://sub2.mydomain.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

What steps have you taken to resolve the issue?

  1. Ensured CORS headers are correct in nginx
  2. Added CORS to my Access policies
  3. Attempted bypassing Access on all affected subdomains
  4. Tested the domain with firewall rules enabled and disabled

What is the domain name?

Was the site working with SSL prior to adding it to Cloudflare?
I’ve only ever used it with Cloudflare

What are the steps to reproduce the error:

  1. Enable Managed Challenge or JS Challenge firewall rules
  2. Access an article on the https://academy.pointtosource.com website
  3. Scroll to bottom, see if comments box is visible
  4. Inspect console, see that CORS headers for two other https://sub.pointtosource.com resources have been blocked (commento and scale8)

Have you tried from another browser and/or incognito mode?
Yes, same deal

Please attach a screenshot of the error:

1 Like

That expression is going to catch every country. What are you trying to do with that rule? Challenge everybody in those three countries, or not in those three countries?

For the assets where you have a CORS error, what is the HTTP status code on the Network tab of DevTools?

It looks like you have Rate Limiting enabled, and a 429 status code will not contain CORS response headers. Enabling Rate Limiting on static assets that should be delivered from the Cloudflare Cache is not necessary, but you will be billed for the product.

2 Likes

Thanks for the quick reply Michael.

That expression is going to catch every country. What are you trying to do with that rule? Challenge everybody in those three countries, or not in those three countries?

I’m trying to catch every country not listed here, because I’ve got a separate flat block rule for those three countries above this rule in the firewall list.

For the assets where you have a CORS error, what is the HTTP status code on the Network tab of DevTools?

Status codes are 403 on the two resources which are getting CORS errors. I understand what a 403 error code is, I’m just unsure why the managed or JS challenge would come up with that.

Yes correct, this is because I found that one particular path on one of these subdomains was getting a lot of automated attempts (multiple every second) so I enabled rate limiting. Disabling it didn’t solve the CORS issue I was experiencing, I understand about the billing, thank you for pointing that out, I guess maybe as you say it’s superfluous if it’s being served from Cloudflare Cache.

1 Like

This is not a CORS problem really. You need to see what Firewall rule is triggering to cause the 403. In Dev tools you will see the CF-Ray header, and you can filter on the Firewall Overview page of the dashboard for that RayID, and this will tell you what rule is causing the request to be blocked.

Say I am in RU. Your expression will expand to:
(false) or (true) or (true). This is true. Now say that I am in GB. Your expression will evaluate to (true) or (true) or (true), and again this is true. Regardless of what country the request comes from the expression will be true.

Personally, rate limiting is intended to limit the “expensive” requests. Serving static assets from Cache is not an expensive request, so rate limiting them does not matter. This is a one-click option on your rate limiting rules.

Thanks for the comments.

I understand your point about the firewall expression, tbh though I wanted to catch practically everywhere in a Managed Challenge, so the rule was doing what I wanted (just getting there in a slightly different way). I’ve also disabled the rate limiting.

OK so cf-ray:
image

And when I filter by that code in the firewall overview page:

And it comes back with the Managed Challenge I thought was causing the issue.

I’ve tried changing the expression to exclude only one country, (i.e. only 'does not equal RU for instance) but the same thing happens. I guess the next thing is to understand why the Challenge forbids that particular path, but there’s nothing in the commento docs or forum that say this has ever been an issue.

Edit: I changed the expression to challenge only if the request didn’t have the specific URI Full which were getting blocked, and it seems to work well enough.

So my managed rule didn’t work as well as I thought it did, and it ended up challenging nothing.

Premise: I want every request to the domain to have a managed challenge, EXCEPT 3 particular full URI paths. The reason for this is that when these URI paths are subject to the managed challenge, they get a 403 error.

As the first firewall expression which applies overrides the ones below, I’ve basically done the following rules in order:

  1. If URI Full equals /path1 OR URI Full equals /path2 OR URI Full equals /path3 then allow
  2. If IP source does not equal myIP then Managed Challenge

I think this gets me to where I want to be, but I’m not sure if it’s the best way (because it uses 2 firewall rules, and because I’m not sure if it’s the most efficient way). I’m thinking that there’s likely some way to combine the two expressions into one rule, but so far it’s eluding me.