Cors Wildcard on Cloudflare

In Cloudflare Workers, a CORS wildcard (Access-Control-Allow-Origin: *) can inadvertently expose sensitive origins when credentials or private response headers are involved. Within Cloudflare Workers, this typically arises in the fetch event handler where the response is constructed manually. Consider a Worker that proxies requests and sets Access-Control-Allow-Origin: * while also including Access-Control-Allow-Credentials: true. This combination is disallowed by browsers and can lead to inconsistent authorization behavior, potentially allowing unauthorized origins to receive authenticated responses if routing logic is misconfigured.

A Cloudflare-specific attack pattern involves leveraging a wildcard in combination with custom subdomain routing. If a Worker uses a wildcard Access-Control-Allow-Origin and reflects the Origin header without strict validation, an attacker can craft a request from a malicious origin that gets echoed back, bypassing same-origin policy in vulnerable contexts. In Cloudflare environments where multiple Workers or services share routes, a wildcard can expose internal or administrative endpoints if route matching is too broad. For example, a Worker mounted on /* that sets Access-Control-Allow-Origin: * might respond to preflight requests for admin panels or API routes that should be restricted.

Another Cloudflare-specific risk occurs when using the cors helper on the Request object in conjunction with environment-based route rewriting. If the Worker dynamically sets CORS headers based on incoming hostnames without validating against an allowlist, a wildcard can be injected through a compromised or misconfigured custom domain. This can expose sensitive data or authentication cookies to origins controlled by an attacker, especially when the Worker also handles authorization tokens or session cookies.

To detect CORS wildcard misconfigurations in Cloudflare Workers, inspect the logic where Access-Control-Allow-Origin is set. A common indicator is a hardcoded * or a dynamic value derived directly from the Origin header without allowlist validation. In Cloudflare Workers, look for patterns such as:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event))
})

async function handleRequest(event) {
  const origin = event.request.headers.get('Origin')
  const response = await fetch(event.request)
  const newHeaders = new Headers(response.headers)
  if (origin) {
    newHeaders.set('Access-Control-Allow-Origin', origin) // potential wildcard reflection
  }
  newHeaders.set('Access-Control-Allow-Credentials', 'true')
  return new Response(response.body, { status: response.status, headers: newHeaders })
}

This pattern reflects the incoming origin directly, which can result in a wildcard-like effect when combined with certain routing setups. It also pairs the header with Access-Control-Allow-Credentials: true, which is invalid when the origin is * and can lead to inconsistent enforcement by browsers.

Using middleBrick, you can automatically detect this issue through its unauthenticated, black-box scanning of Cloudflare-hosted APIs. The scanner runs 12 security checks in parallel, including Input Validation, Property Authorization, and Unsafe Consumption, to identify COW (Credentials-Origin-Wildcard) misconfigurations. middleBrick’s OpenAPI/Swagger spec analysis resolves $ref definitions and cross-references them with runtime behavior, helping to pinpoint whether your Worker’s CORS setup exposes sensitive routes. The LLM/AI Security checks further probe for system prompt leakage and output anomalies that might indicate overly permissive CORS policies being exposed through AI-facing endpoints.

In the middleBrick Web Dashboard, you can track your security scores over time and see detailed findings for CORS configurations. The CLI tool allows you to integrate scanning into local workflows:

middlebrick scan https://your-worker.example.com

For CI/CD integration, the GitHub Action can fail builds if the security score drops due to permissive CORS rules, and the MCP Server enables scanning directly from AI coding assistants within your IDE.

Remediate CORS wildcard issues in Cloudflare Workers by replacing dynamic or wildcard origins with an explicit allowlist and avoiding the combination of Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true. Use environment variables to define trusted origins and validate the incoming Origin header against this list before setting response headers.

Here is a secure Cloudflare Workers example that validates origins against an allowlist and sets CORS headers safely:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event))
})

const ALLOWED_ORIGINS = [
  'https://app.example.com',
  'https://admin.example.com'
]

async function handleRequest(event) {
  const origin = event.request.headers.get('Origin')
  const response = await fetch(event.request)
  const newHeaders = new Headers(response.headers)

  if (origin && ALLOWED_ORIGINS.includes(origin)) {
    newHeaders.set('Access-Control-Allow-Origin', origin)
    newHeaders.set('Access-Control-Allow-Credentials', 'true')
  }

  // Optionally expose specific safe headers instead of using '*'  
  newHeaders.set('Access-Control-Expose-Headers', 'X-Custom-Header')
  return new Response(response.body, { status: response.status, headers: newHeaders })
}

If you use Cloudflare Workers with KV namespaces or Durable Objects for route handling, ensure that CORS logic is centralized and not duplicated across modules. For deployments that involve multiple Workers or subdomain routing, define allowed origins in a shared configuration module and reference it consistently. Avoid reflecting the Origin header without strict validation, and do not set Access-Control-Allow-Origin: * when credentials or sensitive headers are involved.

For API routes that require per-request authorization, consider using Cloudflare’s cors helper with explicit configuration instead of relying on defaults:

export default {
  async fetch(request, env) {
    const cors = new CORS({
      origin: ['https://app.example.com', 'https://admin.example.com'],
      credentials: true
    })
    const response = await cors.handle(request, async () => {
      return new Response('OK', { status: 200 })
    })
    return response
  }
}

This approach ensures that only known origins are allowed, reducing the risk of wildcard-based exposure on Cloudflare-hosted services.