Cursor App Security: What's Missing by Default

Quick answer: cursor app security has one specific blind spot. Cursor is a coding assistant, not a hosting platform, so once it hands you working code, every deployment decision, security headers, TLS version, DNS records, CORS policy, is entirely on you. Nothing gets configured automatically, because configuring a live deployment was never Cursor's job to begin with.

Jump to: what makes Cursor different from Lovable or Bolt, the checklist Cursor never runs for you, why this pattern isn't hypothetical, how to fix it in an afternoon, and a quick FAQ at the end.

Cursor isn't Lovable, and that matters here

Most of the "AI builder" conversation lumps Cursor in with Lovable, Bolt.new, and v0, and for a lot of purposes that's fair. All four let you describe what you want and get working code back fast. But there's a real difference once you get past "does it run," and it's the difference that decides who's responsible for locking the thing down.

Lovable, Bolt.new, and v0 are platforms. They generate your app and they often host it too, which means there's a shared surface where the platform's own defaults do some of the security work whether you asked for it or not. Cursor doesn't work that way. It's an AI-powered IDE that writes code inside your own repo, on your own machine, and you decide where it goes from there, Vercel, a VPS, your own Docker setup, wherever. That's a real strength for developers who want control. It also means there's no platform standing behind you to catch the basics, because there's no platform in the deployment path at all. Cursor's job ends at the code. Everything after that, including the security configuration this post is about, is 100% on whoever hits deploy.

That's not a knock on Cursor. It's genuinely good at producing clean, working code that follows the patterns already in your repo. It's also exactly why "Cursor wrote it, so it's probably fine" is the wrong instinct. Cursor was never going to add your CSP header. It was never in scope.

There's an audience difference underneath this too. Lovable, Bolt.new, and v0 skew toward non-technical founders shipping a first version of something, which is exactly why those platforms bundle hosting, it removes a decision the audience isn't necessarily equipped to make. Cursor's audience is closer to working developers using AI to move faster inside a codebase they already own. That's a more capable audience on average, but "more capable" doesn't mean "already checked the DNS records," it just means the assumption tends to be flipped: a Lovable user might not know headers exist, a Cursor user usually knows they exist and assumes they'll circle back to them before launch. The circling back is the part that quietly doesn't happen often enough.

The checklist Cursor never runs for you

Here's what that gap actually looks like in practice, the specific things that stay unconfigured unless a person deliberately sets them.

Security headers. Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, Referrer-Policy. Cursor will write your route handlers and your middleware exactly as asked, but it won't add a header nobody asked for. These are usually a few lines in your server config or a next.config.js header block, and they're the single most common gap across AI-assisted codebases generally, not a Cursor-specific flaw, just a gap nothing upstream is catching.

TLS configuration. Whether your deployment target terminates TLS 1.2-only or still allows 1.0/1.1, whether HSTS is set to force HTTPS on every request, whether your certificate auto-renews before it expires. None of this lives in application code, so none of it is something Cursor would ever touch, it's a hosting-layer decision that has to be made explicitly wherever you actually deploy.

DNS and email authentication. DMARC, SPF, and CAA records live in your DNS provider, not your repo. Cursor has no visibility into your domain registrar at all, so a domain that's never had these records added stays exactly that way indefinitely, spoofable by anyone, unless a person logs into the DNS dashboard and adds them.

CORS policy. A quick Access-Control-Allow-Origin: * gets a demo working fast, and it's a completely reasonable thing to type while iterating. The problem is it's also exactly what ships to production if nobody circles back to tighten it, especially paired with credentialed requests, which turns a convenience shortcut into an open door.

Cookie flags and session handling. HttpOnly, Secure, SameSite on session cookies, and real expiry on tokens. Cursor will happily generate a working auth flow. Whether that flow is hardened against session fixation or cookie theft depends entirely on whether the prompt (or the reviewer) thought to ask.

Exposed configuration. A .env file or .git folder still reachable at the root of a deployed domain, verbose error pages that hand back stack traces and file paths, a dependency tree nobody's scanned for known CVEs. All deployment and hygiene decisions, none of them Cursor's to make.

Authorization on API routes, not just authentication. This is the one that's easiest to miss because it looks fine from the UI. Cursor will generate a route that correctly checks whether a request is logged in. Whether it also checks that the logged-in user is allowed to see that specific record, not just any record, is a separate question that depends entirely on how the prompt was framed. A working login screen and a properly authorized API are two different things that happen to look identical when you're just clicking around your own app.

None of these seven are exotic. They're the same categories a security review would have caught for free a few years ago, back when most teams had a senior engineer somewhere in the path between "code written" and "code live." Cursor didn't remove that person on purpose, it just makes it possible to skip straight from prompt to production without one, and nothing else in that shorter path picks up the job.

This isn't hypothetical, we've seen the pattern

In the first post in this series, we ran an actual FlawPilot scan on a real, live vibe-coded app and walked through exactly this cluster: no CSP, no HSTS, no clickjacking protection, no DMARC, sitting right next to a perfect 100 on performance. That post wasn't about Cursor specifically, but the pattern is the same pattern, because the root cause is the same root cause: a tool optimized to satisfy a prompt, handing off a working app with zero opinion about how it gets locked down afterward.

The research backs up how common this is across AI-assisted development broadly. Veracode's 2025 GenAI Code Security Report tested over 100 large language models across 80 coding tasks and found that AI-generated code introduced exploitable flaws in 45% of tests, clustered heavily around exactly this category: missing headers, missing DNS hardening, configuration left on whatever was convenient during development. A 2023 Stanford study (Perry et al., ACM CCS) found the same pattern at the human level: developers using an AI coding assistant wrote measurably less secure code than developers without one, and felt more confident about it, not less. Cursor's specific version of the story is just more visible than most, because there's no platform layer anywhere to accidentally catch part of it for you.

The stakes are real, not theoretical. In March 2025, a missing Row-Level Security policy in Lovable-generated apps was catalogued as CVE-2025-48757, CVSS 9.3, exposing over 170 live production databases to unauthenticated read and write access. That one wasn't a Cursor app, and it wasn't a coding mistake either, it was a security control nobody had reason to think about while the code itself worked fine for months. That's the category every item in this checklist lives in.

Fixing it is an afternoon, not a rebuild

None of the six items above touch your application logic. That's the good news buried in this whole post. Security headers are a config block. TLS and HSTS live in your hosting provider's dashboard or a reverse proxy config. DMARC, SPF, and CAA are DNS records. CORS is a policy change, not a rewrite. None of it requires touching the code Cursor wrote for you, which is exactly why it's worth doing before launch rather than after.

This is also the exact gap FlawPilot's free scan is built to catch, across security, performance, infrastructure, and SEO. Every finding lands in a "What to do next" list ranked by what actually matters, with the fix for the top issue in every area spelled out in plain English at no cost, not a CVSS score you have to go decode. Drop in your URL, no login, no server access, and in about two minutes you know exactly which of the six items above still need attention on your specific deployment.

This is the second post in our series on what AI coding tools leave unconfigured by default. The first one walked through a real scan end to end. This one's about Cursor specifically, and the pattern holds: the code works, the security step just isn't anyone's job until you make it someone's job.