In one paragraph
Access-Control-Allow-Origin: * allows browser scripts from any origin to read a response when the request is made without credentials. That is useful for public resources, but requires review on sensitive endpoints. A wildcard cannot authorise credentialed cross-origin reads: browsers block that combination. Keep public endpoints public deliberately, and use validated, explicit origins for authenticated browser integrations.
Why it matters
CORS is a browser response-sharing mechanism. It relaxes the same-origin policy for approved callers; it is not authentication, authorisation, or a general server firewall. Non-browser clients do not become unable to request an endpoint simply because its CORS header is restricted.
For a public font, static file, or intentionally public API response, a wildcard can be correct. On an endpoint holding sensitive data, investigate what unauthenticated requests return and how the endpoint authenticates callers. Do not claim that a wildcard alone exposes every visitor's authenticated account: the browser does not accept it as permission to share credentialed responses.
Access-Control-Allow-Credentials: true does not override this restriction. With a credentialed request and a wildcard origin, the browser refuses to expose the response to the calling script. That is a broken configuration, not proof of successful data theft. Requests can still have server-side effects in some circumstances, so CORS must not replace CSRF protection.
How WebAuditOS evaluates this finding
The supplied check reports a wildcard alone as a warning and a wildcard combined with credentials true as a failure. A specific origin passes; no CORS header is not graded. It does not test whether a specific origin was safely allowlisted or blindly copied from the request. Unrestricted origin reflection can therefore pass this check while remaining dangerous.
How to fix it
- Classify the endpoint. Does it intentionally return the same public information without user credentials, or does it serve authenticated or otherwise restricted data? Review the actual response and access controls, not just its URL name.
- Keep the wildcard only where public browser access is intended. Do not add credential support to a public static-resource rule simply to clear a browser error.
- For private integrations, maintain an explicit set of approved full origins. An origin includes scheme, host, and any non-default port. Validate the incoming Origin against that set and return the matching single origin only when approved:
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Vary: OriginSend the credentials header only when that integration needs credentials. Append Origin to existing Vary values rather than overwriting them. Ensure the cache also handles request-dependent responses appropriately.
- Reject unapproved origins without granting CORS access. Do not reflect every Origin, allow null indiscriminately, or accept a string merely because it contains your domain. A suffix comparison without a domain boundary can accept attacker-controlled names.
- Configure preflight consistently. OPTIONS responses must authorise the required methods and request headers for approved origins. Adding the right header only to the final handler will not repair a failing preflight.
- Test from both an approved and an unapproved browser origin. Check a successful authenticated flow, a rejected origin, a preflighted request, and an unauthenticated request. Inspect the browser Console and Network panel; curl can inspect headers but does not enforce browser CORS rules.
- Test through the CDN as well as the origin. Repeat requests from different origins to detect cache variation errors, then rescan the affected pages in WebAuditOS.
What the fix can break
Narrowing an allowlist can break legitimate browser clients you forgot: regional frontends, preview hosts, customer portals, and applications on different ports. Inventory supported callers before deploying. Server integrations may keep working while browser integrations fail, making this look customer-specific.
Credentialed cross-origin cookies must also satisfy SameSite and browser privacy restrictions. A correct CORS response does not override those rules.
Missing Vary: Origin can cause an origin-dependent header to be reused for the wrong caller, often producing intermittent blocked requests. This does not automatically turn an exact-origin header into a wildcard. Review caching of sensitive bodies separately; CORS is not permission to cache personal data publicly.
Questions
Is Access-Control-Allow-Origin: * always a vulnerability?
No. It is appropriate for intentionally public resources requested without credentials. Review whether the endpoint actually returns public data and whether its authentication design is sound.
Can I list several origins separated by commas?
No. Return one approved origin for the request, or a wildcard where appropriate. Keep the list in server-side configuration rather than placing a comma-separated list in the response header.
Why does wildcard plus credentials fail even though the server returns 200?
An HTTP success does not mean browser sharing is authorised. The browser checks CORS and can withhold the response from JavaScript after the server answers.
What should I check next?
Review cookies missing SameSite for credential behaviour and the security headers guide for complementary browser controls. Neither replaces endpoint authorisation.