so I've been building ShipSafe — security scanner for AI-generated code — and a few weeks ago I got curious. like, actually curious. not "I wonder ...
For further actions, you may consider blocking this person and/or reporting abuse
The methodology here is strong: real production repos found by searching for Cursor-specific patterns rather than curated examples. That's a much more honest signal than benchmarks run on toy projects.
67% with security issues is significant but also worth contextualizing: what's the baseline for non-AI-generated code at similar project sizes and types? The question isn't just "does AI code have vulnerabilities" but "does AI code have more vulnerabilities than human code at the same velocity?" If the comparison point is "code written by the same developers without AI but taking 3x as long," the risk calculus changes.
The most interesting data point would be which vulnerability categories are overrepresented in AI-generated code specifically — my guess would be injection vulnerabilities and overly permissive configurations, since those tend to be in boilerplate that AI generates confidently without fully modeling the security context.
The inverted auth middleware example is a perfect illustration of why AI-generated code needs security review as a first-class concern, not an afterthought. The
if (token)vsif (!token)bug is particularly dangerous because it passes basic functional testing — the developer is always logged in during manual QA, so the redirect behavior seems correct from their perspective.What stands out in your data is that these aren't exotic vulnerabilities. IDOR, missing server-side auth, hardcoded secrets — these are well-known patterns that any senior engineer would catch in code review. The issue is that AI coding assistants optimize for "does it work" rather than "is it secure," and developers trusting the output skip the scrutiny they'd apply to code written by a junior teammate.
This makes a strong case for integrating automated security scanning directly into the AI-assisted development workflow — not as a CI gate after the PR is opened, but as real-time feedback while the code is being generated.
interesting stuff.... thanks
The inverted auth middleware pattern at 31% is wild. That's the kind of bug that passes every test you throw at it because you're always logged in when you test. It's almost adversarial in how invisible it is.
I run a large programmatic site (thousands of pages generated from data pipelines) and while my stack is static-first so most of these server-side vulns don't apply, I've seen the same fundamental issue with AI-generated code: it optimizes for the happy path. When I use AI to generate data processing scripts, it'll skip input validation, ignore edge cases in financial data (negative P/E ratios, missing dividends), and assume every API call succeeds.
Your point about
.cursorrulesas a mitigation is underrated. I've found that giving AI assistants explicit constraints up front ("always validate inputs", "never trust client-side checks alone") dramatically changes the output quality. It's basically the same principle as writing good acceptance criteria — the AI needs to know what "done" looks like, not just what "working" looks like.Cursor itself is reasonably safe for most developers when you use it carefully and keep it updated, but it's not bulletproof. The real risk often comes from the AI-generated code it produces, which can contain critical vulnerabilities (like SQL injection, XSS, insecure auth, etc.) if you don't review or scan it. Your scan result (67% of 100 apps having critical vulns) is plausible and not surprising — it's more likely our prompts (or lack of security-focused follow-up) are contributing heavily, rather than Cursor being uniquely dangerous. AI models (even strong ones like Claude or GPT) are not a security experts. They optimize for "working code" based on our prompt, not secure code. ✌🏻
The inverted auth middleware example is a classic. It really highlights why we need fine-grained control over AI output. Automated security scanning is great, but even just having well-defined architecture rules that the AI is forced to follow can prevent these common 'does it work' but 'is it broken' mistakes before they ever reach a PR.
This is a massive issue that doesn't get enough attention. When using AI agents like Cursor, they often prioritize "making it work" over "making it secure" -- like suggesting getSession() in Supabase which doesn't verify the JWT on the server. I've started using strict .mdc rules to force the agent to only use getUser() and await all Promises in Next.js 15. It's the only way to keep the speed of AI while maintaining actual security standards.
been thinking about what happens when teams ship Cursor code straight to prod. your 67% is going to make some security leads very uncomfortable. what were the most common vuln categories?