I use Cursor most days. It's the editor I reach for when I need to move fast on a client build, and for a lot of the work I do, it's genuinely good at that job. But somewhere around my third or fourth project shipped almost entirely out of Cursor, I started asking a different question. Not "can it write this feature," but "what is it actually checking before this goes live." The honest answer, as of right now, is: not much. That's not a complaint. It's just not what the tool is built to do yet.
What it's built to do
Cursor is a code editor with an AI layer wired all the way through it. Autocomplete, chat, multi-file edits, full-repo context when you ask for it. It's fast, and it's good at reading what you already have and extending it in the same shape. That's the actual job: speed and context, not judgment about whether the thing it just wrote is safe to expose to the internet. Nobody built a checkpoint into the workflow that asks whether a given endpoint should be public.
What it doesn't check, by default
- No pass that flags an exposed environment variable or a hardcoded API key before you commit.
- No check on whether a new Supabase or Postgres table actually has row-level security turned on.
- No verification that a new API route checks who's calling it, versus just checking that a request arrived.
- No rate limiting suggested unless you specifically ask for it.
- No dependency or package vulnerability scan built into the day-to-day workflow.
None of that is a knock on the product. It writes what you ask for, in the shape you ask for it, and if you don't ask for an auth check on a new endpoint, you often don't get one unprompted. The gap isn't laziness on the tool's part. Writing code and reviewing code are two different jobs, and right now Cursor mostly does the first one.
The editor itself isn't automatically safe just because it's popular, either. In the summer of 2025, a remote-code-execution flaw nicknamed CurXecute (tracked as CVE-2025-54135) was found in Cursor's own IDE and reported to the team, then made public by researchers that August. It got patched. But it's a reminder that the tool sits in your pipeline too, with its own attack surface, not just a neutral pass-through between you and your codebase.
Where the rest of the field already moved
By the time I'm writing this, some of the other AI coding tools had already built a review layer into the product itself. Lovable added a security scan to its publish flow back in the spring of 2025, mostly catching missing database permission rules before an app went live. Replit shipped a Semgrep-powered scan around the same time. Bolt added an automatic vulnerability check at publish time by that fall. Cursor, as far as I can tell right now, hasn't shipped an equivalent yet. It might, it's a fast-moving product. But today, there's no built-in moment where it stops you mid-flow and tells you an endpoint has no auth check on it.
What I check by hand now
- Every new database table. Is row-level security actually turned on, not just planned for later.
- Every new API route. Does it check who's calling it, not just that a request showed up.
- Env files. Are they actually gitignored, and did a key ever get pasted into a chat prompt or committed by accident.
- New packages. Anything added this sprint that nobody's actually looked at.
- Anything public-facing. Does it have a rate limit at all.
Once it's a habit, this list takes ten minutes, not an hour. The expensive mistakes I've seen in AI-built projects almost never come from the model writing bad logic. They come from nobody checking the ordinary stuff after it finished. Cursor will build you something fast. Whether it's safe enough to hand to a stranger on the internet is still a question only you get to answer.