Skip to content

How to fix wildcard CORS without breaking your API

An Access-Control-Allow-Origin: * finding needs context. Public resources may intentionally allow browser access from any origin. Private responses need a different policy. Start with the endpoint and the request that failed, rather than changing every header on the site.

What the wildcard actually allows

CORS is a browser response-sharing mechanism. A wildcard permits browser JavaScript at another origin to read a non-credentialed response. It does not authenticate a caller, grant access through your application permissions, or tell you whether the endpoint returns sensitive information. A public asset and an account API can both have this header and require very different decisions.

Decide whether this endpoint needs a change

Check the actual URL, method, response body and intended clients. A public resource that needs no credentials may keep Access-Control-Allow-Origin: *. For private data, first verify authentication and authorisation. If only your own same-origin application needs access, cross-origin sharing may not be needed. If a trusted application at another origin needs access, define its exact scheme, hostname and port in your server-side policy. Never treat CORS as the only access control.

  1. Identify the API response that triggered the finding, rather than relying on the homepage header.
  2. List which browser applications need to read it and whether they send credentials.
  3. Confirm that private responses enforce authentication and user permissions before changing CORS.

Fix the wildcard and credentials error

When browser access uses credentials, Access-Control-Allow-Origin: * is incompatible with that response access. For an approved client, return its exact origin, for example Access-Control-Allow-Origin: https://app.example.com. Set Access-Control-Allow-Credentials: true only when that access is intended. Removing credentials is appropriate only if the resource is genuinely public and the request does not need them. Do not remove authentication merely to silence a browser error.

Support several approved origins correctly

An Access-Control-Allow-Origin response header takes one origin or the wildcard, not a comma-separated domain list. Keep the list in application configuration. Match the request Origin against it, then return the one approved origin for that response. Do not reflect every Origin automatically, and avoid loose substring matches. When this header varies by origin, include Origin in the Vary response header so a cache can distinguish those responses. Preserve any existing Vary values.

Verify the real request and its preflight

Use browser developer tools with the intended client and endpoint. Some requests first send an OPTIONS preflight containing the proposed method and headers. The response must allow the methods and headers the approved application actually needs. A successful OPTIONS response does not prove that the subsequent response or its permissions are correct. Test that response too.

  1. Test a request from an approved origin. Confirm the returned origin matches it and that the browser can read the intended response.
  2. For a private endpoint, test an unauthenticated request and a user without the required permission. Neither should receive protected data.
  3. Test an unapproved origin. It must not be reflected as an approved origin in the response.
  4. Exercise the methods and request headers used by the real client, including their OPTIONS preflight where applicable.
  5. Retest through the production CDN or cache, not just the application server. Verify Vary includes Origin when the policy is dynamic.

What this finding does not prove

A wildcard header by itself is not proof of a breach. CORS also does not prevent every cross-origin request from being sent; some requests can have effects even when the browser cannot expose the response to JavaScript. Keep appropriate CSRF protection for state-changing authenticated operations. Requests from command-line tools and servers are not constrained by the browser same-origin policy, so application permissions remain essential. A public-signal website scan cannot verify every authenticated API route or establish that an application is secure.

Give your developer a useful handover

Record the endpoint, the calling origin, whether credentials are needed, the browser error, the preflight and response headers, and the expected permitted clients. Remove private response data and credentials from anything you share. After the fix, retain the allowed and denied test results. AuditHQ can provide public website observations as a starting point; authenticated API testing requires a separate, authorised review.

Frequently asked questions

Is Access-Control-Allow-Origin: * always unsafe?

No. It can be appropriate for public resources accessed without credentials. Review the endpoint, the data it returns and its intended clients before changing it.

Can I put multiple domains in Access-Control-Allow-Origin?

Not as a comma-separated list. Validate the request Origin against a server-side allowlist and return one matching approved origin. Include Vary: Origin when the response policy changes by origin.

Does wildcard CORS let another site read my session data?

Browsers block credentialed response access when the allowed origin is a wildcard. A wildcard alone does not prove session data exposure. Authentication, authorisation and CSRF protection still need separate review.

Can a free website scan verify this whole fix?

No. A public-signal scan may inspect a sampled response. It cannot exercise every authenticated API route, user permission or browser-client interaction.