What Is CORS?

At a glance

Browsers apply CORS using headers such as Access-Control-Allow-Origin. A wildcard is not inherently dangerous: suitability depends on whether the resource is public and credentials are involved.

CORS governs browser access to cross-origin responses

The same-origin policy normally restricts one page's scripts from reading responses from another origin. CORS lets a destination server use Access-Control-Allow-* headers to permit particular origins, methods and request headers. It is a protocol for relaxing a browser restriction, not a firewall or user-authentication system.

Cross-origin form submissions, image loads and server-to-server requests do not all follow the same reading restrictions. CORS primarily governs whether browser JavaScript can obtain response content. No CORS does not mean a request cannot be sent; permitting an origin does not automatically make an API public.

Simple requests and preflight requests

• Requests meeting specific method, header and content-type conditions can be sent directly. The browser then uses the response's allowed origin to decide whether to expose it to the script.
• Non-simple requests first send an OPTIONS preflight to check permitted methods, headers and credentials. The actual request follows when preflight succeeds.
• Access-Control-Allow-Origin can specify an origin or *. Credentialed access cannot combine with a wildcard origin. Dynamic-origin responses also need appropriate Vary: Origin caching behavior.
• Access-Control-Allow-Credentials permits eligible credentialed responses to be exposed. Cookie sending is still affected by SameSite, Secure and third-party-cookie policies.

Why reflecting Origin can be dangerous

To support several frontends, a server may read Origin and echo it in the response. Reflecting arbitrary origins without a strict trust check can let malicious websites read data available to a signed-in user. Loose suffix matching, accepting null origins and incorrect subdomain handling are common mistakes.

Configure precise origins, methods and headers according to resource sensitivity, while keeping authentication and authorization on the server. CORS cannot replace access control: even if a browser blocks reading, an attacker may call a public API from another server.

Practical use and interpretation

Assess CORS by sending different Origin values and comparing actual and preflight responses. A homepage without CORS headers only establishes that response's policy, not the policy of every API.

A wildcard can be reasonable for public, non-credentialed static resources. Arbitrary origin reflection combined with credentials on sensitive endpoints is a stronger risk signal. If evidence does not cover the API, its policy remains unknown.

Points to consider

Incorrect CORS can allow an untrusted website to read data that should be restricted.

Frequently asked questions

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

No. It can be appropriate for public fonts, images or non-credentialed data. Risk depends on sensitivity, credentials and authorization controls.

Can CORS stop another server calling my API?

No. Browsers enforce CORS; server-side clients are not constrained by the same-origin policy. APIs still need authentication, authorization and rate limits.

Why can a request fail after preflight succeeds?

The actual response also needs matching CORS headers. Authentication, methods, cookie SameSite settings and application authorization can still affect the outcome.