no-permissive-cors
ESLint rule documentation for no-permissive-cors
📡 Live from GitHub — This documentation is fetched directly from no-permissive-cors.md and cached for 6 hours.
Keywords: no permissive cors, security, ESLint rule, CWE-942, Access-Control-Allow-Origin, wildcard, API security CWE: CWE-942: Permissive Write of Outbound HTTP Headers
OWASP Mobile: OWASP Mobile Top 10 M8: Security Misconfiguration
CWE: CWE-942
ESLint Rule: no-permissive-cors. This rule is part of eslint-plugin-browser-security.
Quick Summary
| Aspect | Details |
|---|---|
| Severity | High (Data Exposure) |
| Auto-Fix | ❌ No (requires allowlist logic) |
| Category | Security |
| ESLint MCP | ✅ Optimized for ESLint MCP integration |
| Best For | Node.js servers with public APIs |
| Suggestions | ✅ Advice on using origin validation functions |
Vulnerability and Risk
Vulnerability: Permissive Cross-Origin Resource Sharing (CORS) occurs when an application sets Access-Control-Allow-Origin to * or reflects the Origin header without validation.
Risk: Any website can make requests to your API. If your API relies on ambient credentials (like cookies), a malicious site can exfiltrate sensitive user data or perform actions on behalf of the user.
Error Message Format
The rule provides LLM-optimized error messages (Compact 2-line format) with actionable security guidance:
🔒 CWE-942 OWASP:M8 | Permissive CORS detected | HIGH [DataExfiltration,CSRF]
Fix: Do not use wildcard (*) for CORS origin; use an allowlist | https://cwe.mitre.org/data/definitions/942.htmlMessage Components
| Component | Purpose | Example |
|---|---|---|
| Risk Standards | Security benchmarks | CWE-942 OWASP:M8 |
| Issue Description | Specific vulnerability | Permissive CORS detected |
| Severity & Compliance | Impact assessment | HIGH [DataExfiltration,CSRF] |
| Fix Instruction | Actionable remediation | Do not use wildcard (*) for CORS origin |
| Technical Truth | Official reference | Permissive HTTP Headers |
Rule Details
This rule flags configurations that explicitly use the * wildcard in CORS headers or middleware settings (like the cors npm package).
Why This Matters
| Issue | Impact | Solution |
|---|---|---|
| 🕵️ Data Theft | Private user data exposed to any site | Use a strict allowlist of trusted origins |
| 🚀 CSRF | Actions performed without user intent | Enforce secure CORS and use Anti-CSRF tokens |
| ⚖️ Compliance | Violation of data protection laws | Audit and restrict cross-origin access strictly |
Configuration
This rule has no configuration options in the current version.
Examples
❌ Incorrect
// Setting wildcard origin using res.setHeader
app.use((req, res, next) => {
res.setHeader('Access-Control-Allow-Origin', '*'); // ❌ HIGH RISK
next();
});
// Using the cors middleware with wildcard origin
const cors = require('cors');
app.use(cors({ origin: '*' })); // ❌ HIGH RISK✅ Correct
// Specifying a single trusted origin
app.use(cors({ origin: 'https://trusted.example.com' }));
// Using a function to validate against an allowlist
const whiteList = ['https://app.example.com', 'https://admin.example.com'];
const corsOptions = {
origin: function (origin, callback) {
if (whiteList.indexOf(origin) !== -1 || !origin) {
callback(null, true);
} else {
callback(new Error('Not allowed by CORS'));
}
},
};
app.use(cors(corsOptions));Known False Negatives
The following patterns are not detected due to static analysis limitations:
Dynamic Origin Reflection
Why: If the server reflects the Origin header without validation, it's effectively a wildcard.
res.setHeader('Access-Control-Allow-Origin', req.headers.origin); // ❌ NOT DETECTEDMitigation: Always validate the Origin header against a strict allowlist.
Environment Variable Wildcards
Why: If the origin is loaded from an environment variable that happens to be *.
app.use(cors({ origin: process.env.ALLOWED_ORIGIN })); // ❌ NOT DETECTEDMitigation: Use a configuration system that prevents wildcards in production.