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.
In this guide
- What does CORS stand for?
- Why does CORS matter for web security?
- How does the browser enforce CORS?
- Which HTTP headers control CORS?
- When is a preflight request sent?
- Common CORS misconfigurations to avoid
- How to fix a CORS error in development
- Example: Configuring CORS in Express (Node.js)
- Example: Configuring CORS in Nginx
- When should you disable CORS?
- Summary
Key takeaways
- CORS = Cross - Origin Resource Sharing.
- It lets browsers safely request resources from a different origin while protecting users from malicious cross - site requests.
- Proper CORS headers prevent common errors and security risks.
What does CORS stand for?
CORS stands for Cross - Origin Resource Sharing. It is a browser - enforced policy that defines how a web page can request resources from a domain other than the one that served the page.
Why does CORS matter for web security?
CORS matters because it mitigates the risk of cross - origin attacks such as CSRF and data leakage. Without CORS, a malicious site could freely read responses from another site the user is logged into, exposing sensitive data.
How does the browser enforce CORS?
When a script makes a cross - origin request, the browser adds an Origin header. The target server must respond with an Access-Control-Allow-Origin header that matches the request's origin (or a wildcard *). If the header is missing or mismatched, the browser blocks the response and logs a CORS error in the console.
Which HTTP headers control CORS?
| Header | Purpose |
|---|---|
Access-Control-Allow-Origin | Specifies which origins may access the resource. |
Access-Control-Allow-Methods | Lists HTTP methods (GET, POST, etc.) allowed for cross - origin requests. |
Access-Control-Allow-Headers | Indicates which custom request headers are permitted. |
Access-Control-Allow-Credentials | Allows cookies and HTTP authentication to be sent with the request when set to true. |
Access-Control-Max-Age | Caches the preflight response for a given number of seconds. |
When is a preflight request sent?
A preflight OPTIONS request is sent when the actual request uses a method other than GET, HEAD, or POST, or when it includes custom headers. The server must respond with the appropriate Access-Control-Allow-* headers; otherwise the browser aborts the request.
Common CORS misconfigurations to avoid
- Using a wildcard
*together withAccess-Control-Allow-Credentials:true- browsers will reject this combination. - Echoing back the incoming
Originheader without validation, effectively allowing any site to access the resource. - Forgetting to include
Access-Control-Allow-Methodsfor non - GET requests, causing unnecessary preflight failures.
How to fix a CORS error in development
- Identify the request URL and the origin shown in the browser console.
- Update the server configuration to include that origin in
Access-Control-Allow-Origin. - If credentials are needed, set
Access-Control-Allow-Credentials:trueand ensure the origin is not*. - Restart the server and retest the request.
Example: Configuring CORS in Express (Node.js)
const express = require('express');
const cors = require('cors');
const app = express();
// Allow only https://example.com to access the API
app.use(cors({
origin: 'https://example.com',
methods: ['GET','POST','PUT','DELETE'],
credentials: true
}));
app.get('/data', (req, res) => {
res.json({msg: 'CORS configured correctly'});
});
app.listen(3000);
Example: Configuring CORS in Nginx
location /api/ {
if ($http_origin ~* "^https?://(www\.)?example\.com$") {
add_header 'Access-Control-Allow-Origin' "$http_origin" always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type' always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
}
if ($request_method = OPTIONS) {
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain charset=UTF-8';
add_header 'Content-Length' 0;
return 204;
}
}
When should you disable CORS?
Disabling CORS (by not sending any Access-Control-* headers) is appropriate for resources that are only intended to be accessed from the same origin, such as internal admin pages. Public APIs that need to be consumed by third - party sites should always send explicit CORS headers.
Summary
CORS (Cross - Origin Resource Sharing) is a critical browser security mechanism that governs how resources are shared across origins. Understanding the required headers, handling preflight requests, and avoiding common misconfigurations helps developers prevent CORS errors and protect users from cross - origin attacks.
Related guides
How to Fix a Missing Content - Security - Policy Header
Learn concrete steps to add, test, and harden a Content - Security - Policy header, from server configuration to iterative reporting and verification.
Is HTTP 1.1 a security risk?
HTTP 1.1 is not a direct vulnerability, but its plain - text design and parsing ambiguities can create attack surfaces that need mitigation, especially when not used over TLS.
Is JavaScript a security risk?
JavaScript can be a major attack surface because injected scripts run with the same privileges as the page, but proper sanitization, CSP, and safe frameworks eliminate most risks.