CORS Misconfiguration
Last updated: January 12, 2026
CORS misconfiguration occurs when Access-Control-Allow-Origin is set too permissively, allowing unauthorized domains to make requests to your API.
Scan for This VulnerabilityWhat is CORS Misconfiguration?
Cross-Origin Resource Sharing (CORS) controls which domains can access your API. Misconfigured CORS (especially using wildcards with credentials) allows malicious websites to make authenticated requests on behalf of your users, stealing data or performing actions.
Why It's Dangerous
This vulnerability can allow attackers to access sensitive data, compromise user accounts, or gain unauthorized control over your application. In AI-generated code, this issue is particularly common because security measures are often deprioritized in favor of rapid feature development.
Why AI Code Is Vulnerable
AI code generation tools focus on producing functional code quickly. They often generate patterns that work correctly but lack the defensive measures experienced security engineers would implement. This makes cors misconfiguration particularly prevalent in vibe-coded applications.
Understanding the Technical Details
CORS Misconfiguration is classified as a high-severity vulnerability because of its potential to cause significant damage to your application and users. Understanding the technical mechanics helps you recognize and prevent this issue in your own code.
This vulnerability typically occurs when security controls are either missing entirely, improperly configured, or incorrectly implemented. In many cases, the code appears to work correctly during development and testing, but the security flaw becomes exploitable once the application is deployed and accessible to malicious actors.
Attackers actively scan for this type of vulnerability using automated tools. Once discovered, exploitation can be rapid—often within hours of your application going live. The consequences range from data theft and account takeover to complete system compromise depending on the application's architecture.
For vibe-coded applications built with platforms like Lovable, Bolt.new, Replit, or v0.dev, this vulnerability appears in roughly 20-40% of deployments according to security research. The AI-generated patterns often follow insecure defaults that require manual security hardening.
How It Happens
- Using wildcard (*) for Access-Control-Allow-Origin
- Reflecting the Origin header without validation
- Allowing credentials with permissive origins
- Not understanding CORS security implications
Impact
Data theft from authenticated APIs
Unauthorized actions performed via user sessions
Cross-site data leakage
API abuse from malicious sites
How to Detect
- Check API responses for Access-Control-* headers
- Test if arbitrary origins are reflected
- Verify credentials aren't allowed with wildcards
- Run VAS to detect CORS issues
How to Fix
Whitelist specific origins
Only allow known, trusted domains.
// Express.js example
const corsOptions = {
origin: ['https://myapp.com', 'https://admin.myapp.com'],
credentials: true
};Never use wildcard with credentials
Browsers block this combination, but misconfigured servers may allow it.
// BAD
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
// GOOD - specific origin
Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Credentials: trueValidate reflected origins
If dynamically setting origin, validate against allowlist.
const allowedOrigins = ['https://myapp.com'];
const origin = req.headers.origin;
if (allowedOrigins.includes(origin)) {
res.setHeader('Access-Control-Allow-Origin', origin);
}Commonly Affected Platforms
Prevention Best Practices
The most effective approach to cors misconfiguration is prevention. Implementing security measures during development is significantly easier and less costly than remediating vulnerabilities after deployment.
Security-First Development
When using AI code generation tools, always review the generated code for security implications. AI tools prioritize functionality over security, so treat all generated code as requiring security review. Establish a checklist of security requirements specific to your application type and verify each before deployment.
Continuous Security Testing
Integrate security scanning into your development workflow. Run scans after major code changes, before deployments, and on a regular schedule for production applications. Early detection of vulnerabilities reduces remediation costs and prevents potential breaches.
Defense in Depth
Never rely on a single security control. Implement multiple layers of protection so that if one control fails, others still protect your application. For example, combine authentication, authorization, input validation, and output encoding to create comprehensive protection against attacks.
Stay Informed
Security threats evolve constantly. Follow security researchers, subscribe to vulnerability databases, and monitor your dependencies for known issues. Understanding emerging threats helps you proactively protect your applications before attackers exploit new techniques.
Is Your App Vulnerable?
VAS automatically scans for cors misconfiguration and provides detailed remediation guidance with code examples. Our scanner specifically targets vulnerabilities common in AI-generated applications.
Scans from $5, results in minutes. Get actionable results with step-by-step fix instructions tailored to your stack.
Get Starter ScanFrequently Asked Questions
What's wrong with Access-Control-Allow-Origin: *?
Wildcard (*) allows ANY website to make requests to your API. This is fine for truly public APIs (weather data, public content) but dangerous for authenticated APIs. With wildcard, evil-site.com can make requests to your API - the only protection is that browsers won't send cookies with wildcard CORS.
Can I use wildcard with credentials?
Browsers enforce that you cannot use Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true. If you need credentials, you MUST specify exact origins. Some misconfigured servers try to work around this by reflecting the Origin header - this is the same as allowing all origins.
Why is reflecting the Origin header dangerous?
If your server copies the incoming Origin header to Access-Control-Allow-Origin (to avoid maintaining an allowlist), you've created a wildcard with extra steps. Any site can set their Origin header and your server will authorize it. Always validate against an explicit allowlist.
Do I need CORS for same-origin requests?
No, CORS only applies to cross-origin requests. If your frontend (app.com) calls your API (app.com/api), no CORS needed. CORS is required when domains differ: app.com calling api.app.com, or localhost:3000 calling localhost:4000 during development.