Cross-Origin Access Control
Build Cross-Origin Resource Sharing headers for your API. Configure allowed origins, methods, credentials, and cache settings. Read the guide.
Which origins can access your resources
Wildcard origin (*) allows any website to read your API responses.
Any website can make cross-origin requests to your API and read the response. This is the most permissive setting and appropriate only for fully public APIs with no authentication.
HTTP methods allowed for cross-origin requests
Standard read and submit methods. GET and POST are the most common for APIs. OPTIONS is needed for preflight requests.
Request headers the client is allowed to send
Authorization header is included. Make sure your API validates tokens on every request, since cross-origin callers can now send auth credentials.
Allow cookies and auth headers in cross-origin requests
Cross-origin requests will not include cookies or auth headers. This is safer but means the API cannot identify users via session cookies from other origins.
How long to cache preflight results (seconds)
Preflight results cached for 1 day(s). Good for stable APIs where allowed methods and headers rarely change.
Response headers the client JavaScript can access (optional)
No extra headers are exposed. The browser only lets cross-origin JavaScript read the default safe headers (Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma).
Browsers enforce the same-origin policy by default, which means JavaScript on one domain cannot read responses from another domain. CORS relaxes this restriction in a controlled way. Without it, any website could silently call your API using the visitor's cookies and read the response. CORS headers let your server declare exactly which origins are trusted. For a detailed walkthrough, see our CORS guide.
The most frequent mistakes are using * with credentials (browsers will block it), forgetting to handle the OPTIONS preflight method, and not varying the Vary: Origin header when dynamically setting the origin. Test your CORS setup with browser DevTools and watch for blocked requests in the Console and Network tabs.
Cross-Origin Resource Sharing (CORS) is a browser mechanism that lets servers declare which origins can access their resources. Without CORS headers, browsers block JavaScript from reading responses to cross-origin requests. CORS protects users by preventing malicious sites from silently calling your API with their cookies.
You need CORS headers whenever client-side JavaScript on one domain makes requests to an API on a different domain. Common examples include a React frontend on localhost calling an API on api.example.com, or a single-page app hosted on a CDN talking to your backend. Same-origin requests do not need CORS.
A preflight is an automatic OPTIONS request the browser sends before the actual request when it uses methods like PUT, DELETE, or PATCH, or when it includes custom headers. The server must respond with the correct CORS headers to allow the real request to proceed. The Access-Control-Max-Age header controls how long preflight results are cached.
When Access-Control-Allow-Credentials is true, the browser requires the server to echo back the exact requesting origin instead of *. This prevents malicious sites from using the wildcard to send authenticated requests on behalf of users. You must specify the allowed origin explicitly.
For public APIs that serve only non-sensitive, read-only data, wildcard is acceptable. However, if your API returns private data or accepts mutations, wildcard means any website can call it. Always pair wildcard with no credentials and read-only methods, or switch to a specific origin list.
The CORS spec only allows a single origin value per response. To support multiple origins, your server must check the incoming Origin header against an allowlist and dynamically set Access-Control-Allow-Origin to the matching origin. Most CORS middleware libraries handle this automatically.
After deploying your CORS configuration, scan your site to verify the headers are being served correctly and check the rest of your security headers at the same time.
Scan your website