Bolt.new App Security: What's Missing by Default

Quick answer: Bolt.new app security has one specific headline risk, and it's the same one that hit Lovable, because Bolt wires up Supabase the same way. Describe a database and Bolt gives you working tables in seconds. It doesn't turn on Row-Level Security for you, though, so a table that returns the right data in your own testing can be just as open as the anon key sitting in your JS bundle. Everything else on the checklist - headers, TLS, DNS - is unset for the same reason it's unset everywhere: nobody's job until you make it somebody's job.

Jump to: what makes Bolt.new different from Lovable and Cursor, the checklist Bolt never runs for you, how it compares to the rest of this series, why this pattern isn't hypothetical, how to fix it in an afternoon (with the actual code), and a quick FAQ at the end.

Bolt.new sits between Lovable and Cursor, and that's exactly the gap

Bolt.new, built by StackBlitz, runs on WebContainers, a full Node.js environment inside the browser, so you can watch your app boot in real time as it's generated. That's a genuinely different technical foundation from Lovable or Cursor, but the part that matters for security is simpler: what happens once you hit deploy.

Bolt gives you two real paths out. You can export the code and run it wherever you want, which puts you in the same position as a Cursor user: full control, zero defaults, every configuration decision is yours. Or you can deploy straight from Bolt, usually to Netlify, with a Supabase integration wired up alongside it, which puts you in the same position as a Lovable user: a platform in the deployment path, doing some of the work for you, and quietly not doing the rest.

Most Bolt users take the second path, because it's the one that matches the pitch: describe an app, watch it get built, ship it the same afternoon. That's also why the Supabase-shaped gap below is the one worth reading first. If Bolt's UI feels closer to Lovable's than Cursor's for you, most of what applies to Lovable applies here too, with a couple of differences that come from Bolt's own toolchain.

The checklist Bolt.new never runs for you

Here's what actually stays unconfigured, in the order it tends to matter.

An unset Row-Level Security policy on a Supabase table. This is the one to check first. Bolt's native Supabase integration will scaffold your tables, your auth, and your queries, and all of it will work in testing, because RLS is opt-in at the database layer, not something a working query implies. Supabase enforces access per-row only if a policy tells it to. Skip that step and the table is exactly as open as the anon key shipping in every Bolt app's client bundle, readable and writable by anyone who opens dev tools and watches a single network request, regardless of what the login screen shows on the surface.

Security headers. The response headers that stop an injected script from running loose in a visitor's browser (Content-Security-Policy), force every connection onto HTTPS (Strict-Transport-Security), or stop your site being loaded invisibly inside someone else's page (X-Frame-Options). Whether you deploy through Bolt's Netlify integration or export and host it yourself, none of these arrive by default. Netlify doesn't set them for you unless you add a _headers file or a netlify.toml header block yourself, so the gap is the same one Lovable and Cursor apps both have, just with a different file name for the fix.

TLS and certificate configuration. Bolt's Netlify deploy path handles HTTPS and certificate renewal reasonably well out of the box. What it doesn't handle is whether HSTS is actually being sent to force every visitor onto the secure connection from their very first request, that's still a header you add, not a setting Bolt or Netlify assumes on your behalf.

DNS and email authentication. DMARC and SPF let mail servers verify that an email claiming to be from your domain actually is; CAA controls which certificate authorities are allowed to issue a certificate for it. All three live with whoever controls the domain's DNS, and Bolt has no visibility into a registrar at all. Deploy on a bolt.new or Netlify subdomain and this mostly doesn't apply yet. Point a real domain at it, which is what most people do before sending a link to an investor or a customer, and the domain is spoofable until someone adds these records by hand.

CORS policy. CORS decides which other websites are allowed to call your API directly from a visitor's browser. Wide-open origins are a completely normal thing to have during a build, especially with a Supabase backend you're actively iterating against. The problem shows up when nobody tightens it before the link goes out, particularly if credentialed requests are involved, since that turns a development convenience into a standing door.

Cookie flags and session handling. The settings that stop a session cookie from being read by an injected script (HttpOnly), sent over an unencrypted connection (Secure), or replayed from another site (SameSite), plus whether it actually expires. Bolt-generated auth flows work correctly for the case you tested, whether they're hardened against session fixation or cookie theft depends on whether anyone thought to ask for it in the prompt.

Authorization on API routes and Edge Functions, not just authentication. Bolt will generate a Supabase Edge Function or an API route that checks whether a request is logged in without much trouble. Whether it also checks that the logged-in user is allowed to see the specific row or record being requested, not just any record with a valid session, is a separate question, and it's the same one that shows up across every AI-assisted builder in this series so far.

None of these are Bolt-specific failures. They're the same seven categories a senior engineer would have caught in review a few years ago, back when there was usually a person standing between "the prompt worked" and "the app is live."

How Bolt.new compares to the rest of this series

Every tool in this series leaves the same rough shape of gap, but the specific default that trips people up first is different for each one:

Bolt sits closest to Lovable on this table, same database, same headline risk, and that's the whole reason the RLS check belongs at the top of your list, not the bottom.

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

The first post in this series ran an actual FlawPilot scan against a real, live vibe-coded app and found this exact cluster sitting next to a perfect 100 on performance: no CSP, no HSTS, no clickjacking protection, no DMARC. That post wasn't about Bolt specifically, and neither was the Cursor one or the Lovable one, but the pattern holds across all three because the root cause is identical: a tool optimized to satisfy a prompt, with no opinion about what happens after the prompt is satisfied.

The Supabase-specific risk isn't theoretical either. In March 2025, a missing Row-Level Security policy in Lovable-generated apps was catalogued as CVE-2025-48757, CVSS 9.3, and it left more than 170 live production apps with databases open to unauthenticated read and write access, just from inspecting the app's own network requests. That CVE was scoped to Lovable, but the mechanism behind it isn't a Lovable bug, it's what happens anywhere Supabase gets wired up without a policy telling it to check who's asking. Bolt's native Supabase integration creates the exact same condition, on the exact same database engine, the moment a table ships without RLS turned on.

The broader research points at the same thing from a different angle. 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 missing headers, missing DNS hardening, and access control left on whatever was convenient during development, not spread evenly across every possible mistake. A 2023 Stanford study (Perry et al., ACM CCS) found the same thing 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. Bolt didn't introduce this pattern. It just makes it faster to reach production without anyone standing in the gap this checklist covers.

Fixing it is an afternoon, not a rebuild

Every item on this list is configuration, not application logic. Here's what the fix actually looks like, not just the label.

The RLS fix is a policy added through Supabase's SQL editor or dashboard, scoping rows to the authenticated user, no rewrite involved:

alter table public.orders enable row level security;

create policy "Users can only view their own orders"
on public.orders
for select
using (auth.uid() = user_id);

The headers fix, if you deploy through Bolt's Netlify path, is a _headers file at your project root:

/*
  Content-Security-Policy: default-src 'self'
  Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  X-Frame-Options: DENY
  Referrer-Policy: strict-origin-when-cross-origin

The DMARC fix is a single DNS TXT record at your registrar:

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

None of it touches the code Bolt generated for you, which is why it's worth doing before the link goes out, not after.

This is the same 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, free, no CVSS score to decode. Drop in your URL, no login, no Supabase access required, and in about two minutes you know exactly which of the seven items above still needs attention on your specific deployment.

How FlawPilot helps

FlawPilot is useful because it connects detection to remediation. A scan can tell you a Row-Level Security policy is missing. The next step, actually closing it, is what determines whether the risk goes away.

Every finding lands in a ranked "What to do next" list, written in plain English instead of a severity label. The fix for the top issue in every pillar, security, performance, infrastructure, SEO, is included in the free report, spelled out clearly enough to act on without a security background. For a full crawl of the site, and for findings that go deeper than a config change, Logicwind's engineering team builds a prioritized remediation roadmap and puts people on it directly: RLS policies, header configuration, DNS records, all of it.

The boundaries matter as much as the capability. FlawPilot only checks publicly accessible signals to run the scan, it never touches your server, your codebase, or your credentials, and it doesn't auto-apply any fix without a human in the loop. Finding the gap and fixing the gap happen through the same team, but that means engineers doing the work, not a bot merging code on your behalf.

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

The FlawPilot team, Logicwind