ESLint InterlaceESLint Interlace
Plugin: browser-securityRules

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

AspectDetails
SeverityHigh (Data Exposure)
Auto-Fix❌ No (requires allowlist logic)
CategorySecurity
ESLint MCP✅ Optimized for ESLint MCP integration
Best ForNode.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.html

Message Components

ComponentPurposeExample
Risk StandardsSecurity benchmarksCWE-942 OWASP:M8
Issue DescriptionSpecific vulnerabilityPermissive CORS detected
Severity & ComplianceImpact assessmentHIGH [DataExfiltration,CSRF]
Fix InstructionActionable remediationDo not use wildcard (*) for CORS origin
Technical TruthOfficial referencePermissive 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

IssueImpactSolution
🕵️ Data TheftPrivate user data exposed to any siteUse a strict allowlist of trusted origins
🚀 CSRFActions performed without user intentEnforce secure CORS and use Anti-CSRF tokens
⚖️ ComplianceViolation of data protection lawsAudit 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 DETECTED

Mitigation: 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 DETECTED

Mitigation: Use a configuration system that prevents wildcards in production.

References

On this page

No Headings