Issues with Cross-Origin Resource Sharing (CORS) and WAF Turnstile Verification

What is the name of the domain?

What is the error number?

403 Error Code

What is the error message?

FetchError: The request failed and the interceptors did not return an alternative response

What is the issue you’re encountering

I’m encountering an issue involving CORS policies, specifically when using Cloudflare’s Web Application Firewall (WAF). I have a single-page application (SPA) and an API hosted on different subdomains. The setup works perfectly fine if I disable Chrome’s security settings, but with default security enabled, I am getting blocked by CORS-related issues. I’ve already ensured that my CORS headers are properly configured, but it seems that newer cross-origin policies might be causing these blocks. I’m not very familiar with these newer security headers and am struggling to determine how to configure them correctly for the SPA and API on different subdomains. I’m using Cloudflare’s WAF with Turnstile verification, and the cf-mitigate header might be preventing me from receiving a readable response. When the WAF blocks requests, I only get an HTML response back that I can’t read, resulting in a TypeError. I am not sure how to properly handle this header or configure the WAF to allow preflight requests, which would let me see the actual error details. Is there a specific way to handle Turnstile’s cf-mitigate response in order to ensure smooth communication between the SPA and API? I would greatly appreciate any guidance on how to resolve this issue. Alternatively, if there are specific settings I need to update in Cloudflare to allow cross-origin requests without compromising security, that would be immensely helpful. Thanks in advance for your assistance!

What steps have you taken to resolve the issue?

Ensured that the CORS headers are properly set on the API server.

Tested disabling Chrome’s security settings, which confirmed the setup works without CORS restrictions.

Ran a fetch inside the console with all necessary headers to ensure the issue was not related to the SPA.

Tried different WAF options related to the Turnstile challenge but ultimately chose the managed challenge.

What are the steps to reproduce the issue?

Host a single-page application (SPA) and an API on different subdomains.

Enable Cloudflare’s Web Application Firewall (WAF) and implement Turnstile verification.

Attempt to make a request from the SPA to the API that requires cross-origin access.

Observe that the WAF blocks the request, resulting in an HTML response that cannot be read by JavaScript, causing a TypeError.

Test disabling Chrome’s security settings, which allows the request to proceed without issues, indicating a CORS-related problem.

Still having this issue is anyone able to assist?

Still looking for an update can anyone help me out with this issue?

Still looking for a resolution if anyone can help

May I ask if the Access-Control-Allow-Origin HTTP header is present across those sub-domain(s)?
Are you trying to protect from some of the Access-Control-Allow-Methods or limit, block with a WAF rule?
Are those request(s) authorized for cf-mitigate (Turnstile)?

Hi Fritex, and thanks for getting back to me!

  1. Yes, the Access-Control-Allow-Origin HTTP header is present across those sub-domains.
  2. No, we are not trying to protect or limit any of the Access-Control-Allow-Methods or block with a WAF rule.
  3. I’m not entirely sure what it means for the requests to be “authorized for cf-mitigate (Turnstile).” Could you clarify or provide more context?

Let me know if you need further details!

1 Like

Thank you for feedback.

Related to this, I wonder if the request passed through between subdomains, if that’s possibly a way how the single-page appliaction works? :thinking:

Is the Turnstile implemented on the form element itself, or?

Wonder if it kind of “remembers” when visitor navigates between SPA and sub-domain(s)? Might be it is not. It acts like pre-clearance isn’t working from my understanding.

Are you using Flexible or Full (Strict) SSL? Just wondering …

Blogpost reminded me on your case, but maybe it’s not the same what would help you :thinking:

Is the APi on the other sub-domain does the API get 403 from the WAF rule in such situation? Despite you’re saying no WAF rule? Might be some other service which was triggered than, such as Bot Fight Mode?

Sorry for double-asking or asking dumb questions, trying to simplify where to go with troubleshooting first.