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
- Key takeaways
- What triggers the "blocked by CORS policy" message?
- How does the same - origin policy relate to CORS?
- Which response headers does a server need to send?
- What is a pre - flight request and why does it matter?
- How to fix the error on a typical Node.js/Express server
- How to resolve the error when you cannot change the server
- When is it safe to disable CORS checks?
- How does Decloak help you detect CORS misconfigurations?
- Quick checklist to verify CORS is correctly configured
Key takeaways
- CORS is a browser - enforced mechanism that lets a server explicitly permit cross - origin requests.
- The error means the server's response lacked or mismatched the required
Access-Control-Allow-*headers. - Fixes involve adding correct headers on the server, handling pre - flight OPTIONS requests, or using a same - origin proxy.
What triggers the "blocked by CORS policy" message?
The browser blocks the request because the response does not satisfy Cross - Origin Resource Sharing rules. When a script on https://mysite.com tries to fetch https://api.example.com/data, the browser checks for CORS headers. If none are present, or if the Access-Control-Allow-Origin value does not match the requesting origin, the request is aborted and the console shows the error.
How does the same - origin policy relate to CORS?
The same - origin policy stops scripts from reading data from a different scheme, host, or port. CORS is an exception mechanism: a server can opt - in by returning headers that tell the browser which origins are allowed. Without those headers, the same - origin policy remains in effect and the request fails.
Which response headers does a server need to send?
| Header | Purpose |
|---|---|
Access-Control-Allow-Origin | Lists the permitted origin (e.g., https://mysite.com or *). |
Access-Control-Allow-Methods | Lists HTTP methods the client may use (GET, POST, etc.). |
Access-Control-Allow-Headers | Lists custom request headers the client may send. |
Access-Control-Max-Age | Caches the pre - flight response for the given seconds. |
Access-Control-Allow-Credentials | Allows cookies or HTTP authentication if set to true (must not be used with *). |
What is a pre - flight request and why does it matter?
For non - simple requests (e.g., using PUT, custom headers, or Content-Type other than application/x-www-form-urlencoded), the browser first sends an OPTIONS request. The server must respond with the CORS headers listed above. If the OPTIONS response is missing or returns a 4xx/5xx status, the browser shows the CORS error and never sends the actual request.
How to fix the error on a typical Node.js/Express server
const express = require('express');
const app = express();
// Simple allow - any - origin example (use with caution)
app.use((req, res, next) => {
res.setHeader('Access-Control-Allow-Origin', '*');
res.setHeader('Access-Control-Allow-Methods', 'GET,POST,PUT,DELETE,OPTIONS');
res.setHeader('Access-Control-Allow-Headers', 'Content-Type,Authorization');
if (req.method === 'OPTIONS') {
return res.sendStatus(204);
}
next();
});
app.get('/api/data', (req, res) => {
res.json({ message: 'CORS works' });
});
app.listen(3000, () => console.log('Server running'));
For production, replace * with the exact origin, and add Access-Control-Allow-Credentials: true only when you need cookies.
How to resolve the error when you cannot change the server
- Use a same - origin reverse proxy (e.g., Nginx) that adds the required CORS headers.
- Move the request to the backend of your own application, then have your frontend call your backend (same origin).
- If the resource is public and supports JSONP, you can load it via a
<script>tag (limited to GET).
When is it safe to disable CORS checks?
Never disable CORS in a production browser. The error is a security feature that prevents malicious sites from reading sensitive data. Only relax headers on trusted origins or for public resources that do not expose private data.
How does Decloak help you detect CORS misconfigurations?
Decloak's free scan includes the HTTP/TLS security posture layer, which checks response headers for missing or overly permissive CORS settings. The scan runs in about 15 seconds and returns a graded report, so you can see if your site is inadvertently blocking legitimate cross - origin requests or exposing data to any origin.
Quick checklist to verify CORS is correctly configured
- Verify
Access-Control-Allow-Originmatches the expected origin or is*only for public assets. - Ensure pre - flight OPTIONS responses include all required headers and return 204.
- Confirm that
Access-Control-Allow-Credentialsis not used with a wildcard origin. - Test with a browser console or a tool like
curl -I -H "Origin: https://mysite.com" https://api.example.com/data. - Run a Decloak free scan and review the CORS findings in the report.
This article follows best practices for understanding and fixing the "blocked by CORS policy" error.
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.