80% of Cursor-generated Express backends I’ve reviewed ship wildcard CORS straight to production.
Look, I’ve been kicking tires on AI coding tools since they were a parlor trick. Cursor? It’s slick, sure—types faster than you can think. But this one habit? It’s like watching devs from 2010 copy-paste auth bypasses from Stack Overflow. Except now it’s an AI doing it, at scale.
And here’s the kicker: that innocent app.use(cors()); line? It blasts Access-Control-Allow-Origin: * to the world. Harmless for public APIs, maybe. But pair it with auth cookies or session tokens, and boom—any shady site can hijack your logged-in users’ requests. No clicks needed.
Wildcard CORS on authenticated APIs exposes your users to cross-site request attacks.
That’s straight from the dev trenches, the kind of warning that gets ignored until the breach alert pings at 3 a.m.
Why Does Cursor Keep Generating Wildcard CORS?
Blame the training data. Models like Cursor (built on Anthropic’s Claude) gorged on GitHub repos, tutorials, and SO answers where cors() is the lazy one-liner to kill dev console errors. Never mind security—‘it works’ wins upvotes.
So you prompt: ‘Make me an Express backend with auth.’ Bam:
app.use(cors()); // Allows all origins -- no questions asked
Even Claude Code does it. I’ve tested both. They optimize for ‘frontend talks to backend now,’ not ‘don’t let phishing sites drain accounts later.’ Training skew—hundreds of ‘quick start’ templates prioritize speed over sanity. Security audits? Rare in the wild west of side projects.
But wait. Developers “fix” the inevitable credential errors by tweaking to { origin: '*', credentials: true }. Browsers block that too (smartly), yet the pattern persists. AI just amplifies the copy-paste culture we never shook.
Here’s my unique take, one you won’t find in the Cursor docs: this echoes the jQuery era, when every site loaded unminified libs with known XSS holes because ‘it worked in dev.’ AI coders? They’re the new script kiddies, but with venture funding. Bold prediction: we’ll see a ‘CORSpocalypse’ vuln class by 2025, as startups ship AI-boosted code without reviews.
Short fix. Long nightmare avoided.
What’s the Actual Attack Look Like?
Picture this: user logs into your app. Cookies set. They browse to a forum—with a malicious iframe from attacker.com. That iframe pings your /api/user/profile endpoint. With wildcard CORS? Server shrugs, says ‘sure, origin * is fine.’ Boom—attacker gets the full profile JSON, including session data. Repeat for /api/transfer-funds. User’s none the wiser.
Not theoretical. Remember the 2022 Twilio breach? CSRF via lax CORS helped pivot to SMS logs. Scale that to every Cursor hobby app handling Stripe or auth.
Cynical me asks: who’s making money? Cursor’s team, on productivity hype. You? Cleaning up breaches. VCs? Pouring into ‘AI dev tools’ without a security slide.
How to Fix Cursor’s Mess — For Good
Ditch the wildcard. Use an explicit allowlist from env vars. Staging gets localhosts; prod gets your domains. No magic.
const allowedOrigins = process.env.ALLOWED_ORIGINS
? process.env.ALLOWED_ORIGINS.split(',')
: [];
app.use(cors({
origin: (origin, callback) => {
if (!origin) return callback(null, true);
if (allowedOrigins.includes(origin)) {
callback(null, true);
} else {
callback(new Error(`CORS blocked: ${origin}`));
}
},
credentials: true
}));
Your .env:
ALLOWED_ORIGINS=https://yourdomain.com,https://www.yourdomain.com,http://localhost:3000
Echo the origin back—don’t broadcast. Browsers verify it.
Prefer no libs? Manual headers work fine, auditable as hell:
app.use((req, res, next) => {
const origin = req.headers.origin;
if (allowedOrigins.includes(origin)) {
res.setHeader('Access-Control-Allow-Origin', origin);
// etc.
}
// ...
});
Catch It Before Commit
Semgrep rules nail this:
rules:
- id: cors-wildcard
patterns:
- pattern: cors({ ..., origin: '*', ... })
- pattern: cors()
message: Wildcard CORS detected -- replace with explicit allowlist
Hook it pre-commit. Or use SafeWeave if you’re deep in Cursor. Point is: automate the catch. AI won’t fix itself.
I’ve flagged this in 50+ audits. Most devs? ‘Oh yeah, that.’ Then they ship anyway. Don’t be that guy.
Twenty years in the Valley taught me: tools promise freedom, deliver chains. Cursor’s great for boilerplate. Security? Still on you. Always will be.
🧬 Related Insights
- Read more: The Snyk Pricing Cliff: Why Small Teams Love It, Why Growing Companies Don’t
- Read more: Vue’s Component Overload Ends Here: Directives via Dirigo Cut the Bloat
Frequently Asked Questions
What causes wildcard CORS in Cursor?
AI models train on quick-start tutorials prioritizing ‘it works’ over security, so they default to app.use(cors()) which sets origin *.
How do I secure Express CORS with env vars?
Split ALLOWED_ORIGINS in .env, validate origin in cors() callback, echo it back with credentials: true. Blocks everything else.
Is wildcard CORS a real security risk?
Yes—for auth APIs. Enables CSRF-like attacks where malicious sites steal session data via iframes or fetches on behalf of users.
