CORS is explicitly configured (not relying on framework defaults)
Why it matters
Calling app.use(cors()) with no origin: option silently defaults to Access-Control-Allow-Origin: *, which allows any third-party domain to make cross-origin requests to your API and read the responses. OWASP A05 (Security Misconfiguration) and CWE-942 (Permissive Cross-domain Policy) both call this out. When combined with credentials: true, wildcard CORS causes browsers to reject the response anyway — but misconfigured CORS without credentials still exposes unauthenticated API responses to attacker-controlled sites.
Severity rationale
Medium because wildcard CORS exposes unauthenticated API responses to any origin, enabling data exfiltration from endpoints that rely on same-origin as a defense.
Remediation
Always pass an explicit origin list to the CORS configuration. Never rely on the default wildcard.
import cors from 'cors'
app.use(cors({
origin: [
'https://example.com',
'https://app.example.com',
process.env.NODE_ENV === 'development' ? 'http://localhost:3000' : null,
].filter(Boolean),
credentials: true,
methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
}))
For Next.js, set Access-Control-Allow-Origin headers explicitly in next.config.js using the headers() function with per-path rules rather than installing the cors npm package.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Security Implementation Validation Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-942 — Permissive Cross-domain Policy with Untrusted Domains
- owasp:2021 · A05 — Security Misconfiguration
- owasp:2021 · A01 — Broken Access Control
Taxons
History
- 2026-04-18·v1.0.0·Initial import from ai-slop-security-theater·automated