Cursor Security: Scan AI-Written Code Without Leaving Your Editor

Cursor writes code fast, but it reproduces classic vulns and leaks secrets. Here's what to check in AI-written code — and how to scan it right inside Cursor with Trust's MCP.

Aug 7, 2026 · 7 min read

Cursor is genuinely great. You describe a feature, hit accept a few times, and it's done. But if you've started wondering whether all that AI-written code is actually safe, you're asking the right question at the right time. The honest answer: Cursor writes code that runs, not code that's secure — and those aren't the same thing.

This isn't a "Cursor is bad" post. It's a "here's the specific stuff it gets wrong, and how to catch it in about a minute without leaving your editor" post.

Is Cursor safe? Mostly yes, with a real asterisk

Cursor the tool is fine. The risk is in what the underlying model writes for you. In its 2025 analysis of AI-generated code, Veracode found that about 45% of samples failed security tests by introducing an OWASP Top 10 vulnerability — and that models failed to defend against cross-site scripting in 86% of cases. So roughly one in two accepts can carry a flaw, and XSS is close to a coin flip in the model's favor.

Why? The model learned from millions of public repos, and plenty of public code is insecure. It optimizes for "does this compile and do what they asked," not "could a stranger abuse this." It has no idea which of your keys are secret or which endpoints touch real user data.

The four things AI-written code gets wrong

The same handful of issues show up again and again. None of them look wrong in the editor.

1. Secrets in the client bundle

Ask Cursor to "call OpenAI from the frontend" and it will cheerfully do exactly that — putting your key somewhere the browser can read it. In Next.js, the classic mistake is a secret prefixed with NEXT_PUBLIC_, which gets bundled into the JavaScript every visitor downloads. See how a NEXT_PUBLIC key leaks, and if you use Supabase, watch for the far worse service-role key exposure.

2. Auth that looks enforced but isn't

Cursor loves to generate a login page and a redirect, then leave the data wide open:

Supabase tables created with Row-Level Security off — the UI only shows "your" rows, but the API will hand out everyone's.
A middleware.ts used as the security gate. Middleware is for redirects, not a boundary — a Server Component or route handler still needs its own check.

3. XSS via dangerouslySetInnerHTML

For "render this markdown" or "show the user's bio," Cursor reaches for dangerouslySetInnerHTML more often than it should. Feed user-controlled text into that (or a raw innerHTML assignment) and you have cross-site scripting — the exact category that failed 86% of the time above.

4. Injection from unsanitized input

String-built SQL queries, eval() on user input, or os.system() with a value from a request get copied straight out of the model's training data into your handlers.

Why you can't just eyeball it

Every one of these compiles, passes your manual click-through, and looks like normal code. The vulnerability is in what's missing (a check, a sanitizer) or where a value ends up (the client bundle) — not in a red squiggle.

Scan it without leaving Cursor

Here's the part that changes your workflow. You don't need to push, deploy, and wait for a dashboard to email you. Trust ships an MCP integration that plugs into Cursor, so the scanner lives right next to the AI that wrote the code.

Add the Trust MCP server to Cursor's config (Settings → MCP) — copy-paste from the MCP page.
In Cursor's chat, say "scan this file for security issues" or "check my repo for leaked secrets," and the agent calls Trust directly.
It runs real checks — secret detection, static analysis for the patterns above, dependency issues — then reports exact line numbers back into your chat with plain-language fixes.

The loop becomes: Cursor writes it, Trust checks it, Cursor fixes it — all in the same window.

Scan your Cursor project — free, no signup

Paste a URL or GitHub repo for a full pass, or wire up the MCP to scan inside Cursor.

Run a free scan →

A 60-second sanity check for right now

Search your project for NEXT_PUBLIC_ and make sure no real secret (Stripe, OpenAI, Supabase service-role) is behind it.
Confirm every table with private data has Row-Level Security on, and that your API routes check the user — not just the UI.
Grep for dangerouslySetInnerHTML and confirm none of it renders raw user input.

Not sure what a leaked key even looks like? Our OpenAI API key detector shows the exact pattern to hunt for.

Cursor makes you fast, and speed is a real advantage — don't give it up. Just close the one gap that comes with it: the model doesn't know what's secret or who's allowed. Put a scanner in the same window that writes the code, and "is my AI code safe?" becomes a one-line question you can ask any time.