What is CORS and Why Is It Used?

Decloak is an AI-powered web security intelligence platform that scans a site's HTTP/TLS posture, JavaScript, and third-party scripts to produce a report anyone can read. This guide is part of Decloak's library of practical, source-backed security guidance.

Key takeaways

• CORS is an HTTP - header mechanism that relaxes the browser's same - origin policy for approved origins.
• The browser sends an Origin header and, for non - simple requests, a pre - flight OPTIONS request.
• The server responds with Access-Control-Allow-Origin (and optional headers) to grant or deny access.
• Use CORS to safely expose APIs, fonts, WebGL textures, or any resource to trusted third - party sites.

What does CORS stand for and how does it work?

CORS stands for Cross - Origin Resource Sharing, and it works by having the browser include an Origin header in every cross - origin request. If the request is not "simple" (e.g., uses custom headers or methods other than GET/POST), the browser first sends a pre - flight OPTIONS request to the server. The server must answer with specific CORS response headers - most importantly Access-Control-Allow-Origin - that list the origins allowed to read the response. When the headers match the request's origin, the browser permits the script to access the data; otherwise it blocks the response.

Why is CORS needed in modern web applications?

CORS is needed because browsers enforce the same - origin policy, which prevents a script loaded from https://example.com from reading resources from https://api.another.com. Without a controlled way to relax this rule, legitimate cross - origin interactions - such as a single - page app calling a backend API hosted on a different domain - would be impossible. CORS provides a safe, server - controlled way to allow those interactions while still protecting users from unintended data leakage.

Which headers control cross - origin access?

How to implement CORS on a typical server?

1. Identify trusted origins - maintain a whitelist of domains that should be allowed to access your resources.
2. Add the Access-Control-Allow-Origin header - in most web frameworks this is a simple middleware configuration. For example, in Express (Node.js):

const allowedOrigins = ['https://app.example.com', 'https://dashboard.example.com'];
app.use((req, res, next) => {
const origin = req.headers.origin;
if (allowedOrigins.includes(origin)) {
res.setHeader('Access-Control-Allow-Origin', origin);
res.setHeader('Access-Control-Allow-Credentials', 'true');
}
next();
});

1. Handle pre - flight requests - respond to OPTIONS requests with the appropriate Access-Control-Allow-Methods and Access-Control-Allow-Headers.

app.options('*', (req, res) => {
res.setHeader('Access-Control-Allow-Methods', 'GET,POST,PUT,DELETE');
res.setHeader('Access-Control-Allow-Headers', 'Content-Type,Authorization');
res.setHeader('Access-Control-Max-Age', '86400');
res.sendStatus(204);
});

1. Test the configuration - use browser dev tools or curl to verify that the correct headers appear and that blocked origins receive a CORS error.

Common pitfalls and how to avoid them

• Using * with credentials - browsers ignore Access-Control-Allow-Origin: * when Access-Control-Allow-Credentials: true. Always echo back the requesting origin instead of using *.
• Over - broad method lists - only allow the HTTP methods your API actually needs; exposing DELETE or PUT unnecessarily widens the attack surface.
• Missing pre - flight headers - if a client sends a custom header like X - My - App, you must list it in Access-Control-Allow-Headers; otherwise the browser will block the request before it reaches your code.
• Cache control - set a reasonable Access-Control-Max-Age to reduce pre - flight traffic but avoid stale permissions.

When should you not use CORS?

If all resources are served from the same origin, you can skip CORS entirely. Likewise, public assets such as images or fonts that do not expose sensitive data can safely use Access-Control-Allow-Origin: *. For highly sensitive endpoints, consider additional authentication layers and keep the CORS whitelist as narrow as possible.

How does CORS relate to security scanning?

Security scanners, including Decloak's free scan, check for correctly configured CORS headers as part of the HTTP/TLS security posture layer. Misconfigured headers - such as allowing any origin with credentials - are flagged as high - risk findings because they can enable data exfiltration from trusted users.

For a deeper look at how Decloak evaluates CORS and other security controls, see the Every Report Now Includes an Explicit OWASP Top 10:2025 Coverage Checklist.