Articles

Configure CORS Headers on CDN to Fix Cross-Origin Errors (2026)

April 16, 2026 6 min read

This is about how to get your browser to stop throwing CORS errors when your frontend code on one domain tries to fetch resources from your backend on another domain, specifically when a CDN sits in front of that backend.

Let’s see it in action. Imagine you have a frontend served from https://my-app.com and your API is at https://api.my-cdn.com.

<script>
  fetch('https://api.my-cdn.com/data')
    .then(response => response.json())
    .then(data => console.log(data))
    .catch(error => console.error('CORS Error:', error));
</script>

If your CDN isn’t configured correctly, that fetch call will likely fail with a CORS error in your browser’s developer console. The error typically looks something like this:

Access to fetch at 'https://api.my-cdn.com/data' from origin 'https://my-app.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

The core problem is that browsers enforce a "same-origin policy" for security. If a web page from https://my-app.com tries to request resources from a different origin (https://api.my-cdn.com), the browser will block it by default unless the server explicitly says it’s okay. The CDN, acting as the server in this scenario, needs to be told to send back the right signals.

The solution involves configuring your CDN to send specific HTTP headers that tell the browser it’s safe for https://my-app.com to access resources from https://api.my-cdn.com. These are the CORS (Cross-Origin Resource Sharing) headers.

Here’s how you’d typically configure this on a CDN, using common examples. The exact interface will vary by CDN provider (like Cloudflare, Akamai, AWS CloudFront, Fastly), but the concepts are the same.

1. Allow Specific Origins (Access-Control-Allow-Origin)

This is the most critical header. It specifies which origins are allowed to access your resources.

  • Diagnosis: Use your browser’s developer tools (Network tab) to inspect the response headers from your API endpoint (https://api.my-cdn.com/data). Look for the Access-Control-Allow-Origin header. If it’s missing, or if it’s set to * when you need to be more restrictive, that’s the problem.

  • Fix (Specific Origin): Configure your CDN to add or modify the Access-Control-Allow-Origin header to https://my-app.com.

    • Example (Conceptual CDN Config):
      • Rule: "Add Header"
      • Header Name: Access-Control-Allow-Origin
      • Header Value: https://my-app.com

  • Why it works: This header directly tells the browser that requests originating from https://my-app.com are permitted to access the resource.

  • Fix (Multiple Specific Origins): If you have multiple frontend applications on different domains that need access, you can often configure the CDN to allow a comma-separated list or use a configuration that dynamically checks the incoming Origin header.

    • Example (Conceptual CDN Config):
      • Rule: "Add Header"
      • Header Name: Access-Control-Allow-Origin
      • Header Value: https://my-app.com, https://another-app.com

  • Why it works: The browser checks if the Origin header from the request is present in the Access-Control-Allow-Origin list.

  • Fix (Allow Any Origin - Use with Extreme Caution): If you truly want any domain to access your API (e.g., a public, read-only API), you can set it to *.

    • Example (Conceptual CDN Config):
      • Rule: "Add Header"
      • Header Name: Access-Control-Allow-Origin
      • Header Value: *

  • Why it works: The wildcard * explicitly tells the browser that any origin is permitted. Warning: This is generally not recommended for APIs that handle sensitive data or perform state-changing operations.

2. Allow Specific Methods (Access-Control-Allow-Methods)

Browsers also pre-flight OPTIONS requests for methods other than GET and HEAD (like POST, PUT, DELETE) to check if the server allows them.

  • Diagnosis: If your POST or PUT requests are failing, check if Access-Control-Allow-Methods is present and includes the HTTP methods your frontend is using.
  • Fix: Configure your CDN to include the allowed HTTP methods.
    • Example (Conceptual CDN Config):
      • Rule: "Add Header"
      • Header Name: Access-Control-Allow-Methods
      • Header Value: GET, POST, PUT, DELETE, OPTIONS
  • Why it works: This header informs the browser which HTTP request methods the server supports for the requested resource, allowing pre-flight OPTIONS requests to succeed for non-simple methods.

3. Allow Specific Headers (Access-Control-Allow-Headers)

Custom headers or headers like Content-Type (when not application/x-www-form-urlencoded, multipart/form-data, or text/plain) can also trigger pre-flight requests.

  • Diagnosis: If your requests fail with errors mentioning specific headers (e.g., Content-Type, Authorization), check for Access-Control-Allow-Headers.
  • Fix: Configure your CDN to list the headers your frontend might send.
    • Example (Conceptual CDN Config):
      • Rule: "Add Header"
      • Header Name: Access-Control-Allow-Headers
      • Header Value: Content-Type, Authorization, X-Requested-With
  • Why it works: This header specifies which HTTP request headers can be used when making the actual request, allowing custom or non-standard headers to be included after a successful pre-flight.

4. Expose Specific Headers (Access-Control-Expose-Headers)

By default, browsers only expose a few "safe" response headers to JavaScript. If your JavaScript needs to read custom response headers (e.g., X-RateLimit-Limit), you need to explicitly expose them.

  • Diagnosis: If your frontend code tries to access a custom response header from the CDN and gets undefined or an error, this header is likely the culprit.
  • Fix: Configure your CDN to expose the necessary headers.
    • Example (Conceptual CDN Config):
      • Rule: "Add Header"
      • Header Name: Access-Control-Expose-Headers
      • Header Value: X-RateLimit-Limit, X-RateLimit-Remaining
  • Why it works: This header tells the browser which response headers are safe to expose to client-side JavaScript, making custom headers accessible.

5. Set Access-Control-Allow-Credentials

This header is crucial if your frontend needs to send cookies or HTTP authentication credentials with its requests, and the Access-Control-Allow-Origin is not *.

  • Diagnosis: If your requests that include cookies or authentication tokens are failing with CORS errors, check this header. You often see errors like "Credential is not supported with wildcard '*'."
  • Fix: Configure your CDN to set Access-Control-Allow-Credentials to true.
    • Example (Conceptual CDN Config):
      • Rule: "Add Header"
      • Header Name: Access-Control-Allow-Credentials
      • Header Value: true
  • Why it works: This header indicates whether the browser should send credentials (like cookies or authorization headers) with requests to the specified origin. If true, the Access-Control-Allow-Origin cannot be *; it must be a specific origin.

6. Cache Control for Pre-flight Requests

Pre-flight OPTIONS requests can add latency. You can tell the browser to cache the result of the pre-flight check for a certain period.

  • Diagnosis: While not a direct error fix, if you notice many OPTIONS requests in your network tab, or if your API is getting hammered by pre-flight checks, this is an optimization.
  • Fix: Set the Access-Control-Max-Age header.
    • Example (Conceptual CDN Config):
      • Rule: "Add Header"
      • Header Name: Access-Control-Max-Age
      • Header Value: 86400 (which is 24 hours)
  • Why it works: This header specifies how long the results of an OPTIONS request can be cached, reducing the number of pre-flight requests the browser needs to make for subsequent requests to the same resource from the same origin.

The next error you’ll hit after fixing CORS is likely a 4xx or 5xx error from your actual backend API, indicating an issue with the request payload, authentication, or a problem within the API itself.

Want structured learning?

Take the full Cdn course →