Bolt.new ships features fast. The same pattern that makes that possible — confident code, idiomatic-looking output, fast iteration — is what hides the risk we read for. We audit Bolt.new codebases line by line, name what's broken, and tell you what to fix first.
Full-stack prototypes generated in a WebContainer environment, then exported and forked into ‘real’ deployments.
API routes set `Access-Control-Allow-Origin: *` together with `Allow-Credentials: true` (or the equivalent). Any third-party site the user visits can issue authenticated requests to the API on their behalf, reading or modifying their data without their knowledge.
Promises that throw and routes that crash return the full Node.js stack trace as the HTTP response body. File paths, library versions, environment variable names and database column names all become public — gold for anyone profiling the app for a follow-up exploit.
package.json uses `^` ranges and the project has no committed lockfile, so two clean installs a week apart pull different transitive trees. A vulnerable patch version of a deep dependency lands on production before anyone reads its changelog.
A privileged key (typically Supabase service_role, Firebase admin or a payments secret key) ends up referenced in client-side code. The build pipeline inlines it into the JavaScript bundle, where any visitor can read it from DevTools and bypass every row-level rule the database has.
The database has tables marked as public, or RLS policies of the form `USING (true)`. Anyone with the project's anon key — which is meant to be public — can read or write the full table from a browser. The application looks safe because the UI gates the views, but the data is open by default.
Knowing the tool that built the code lets us focus the audit. We start by detecting the Bolt.new signature in the codebase, then we read the surfaces where Bolt.new-specific failure modes cluster: auth, secrets, data access, dependencies and LLM-touching paths. Five to ten business days from kickoff to written report. No deployment access required — read-only repository access is enough.
Severity-ordered findings with file paths, line references, why it matters and a fix sketch. Readable by both engineering and non-technical stakeholders.
15-minute recording of the report — for the cofounder, investor or director who didn't make the live call.
Live discussion of severity, fix order and the calls that need a human in the loop.
Slack or email for clarifications, fix reviews and a second pair of eyes on the patches.
Typical SMB AI-built codebase, kickoff to written report. Larger or multi-repo audits scoped separately.
CORS, sessions, file storage paths and any code that assumed the WebContainer's sandboxed network. We map those assumptions, name where they break in real deployments, and recommend fixes.
Yes. Lockfile inconsistencies and dependency churn between iterations is one of our most common Bolt findings. We pin and audit what's actually in the deployed lockfile vs. what the prompt history suggests.
Often yes. The default error-handling in Bolt-generated apps mirrors the WebContainer dev experience — full stack traces, file paths, env-var names. We flag every endpoint that does this.
Next.js, Python and full-stack apps with Tailwind, shipped at high velocity by individual developers.
Read more →Terminal-driven, multi-file changes across a codebase — often touching infra, tests and product code in a single agent loop.
Read more →Inline completions across enterprise codebases, mixed with hand-written code from many authors over years.
Read more →We design for privacy from the start, human control, traceability, usage limits, permissioning and documentation. For sensitive processes, we help assess risk and applicable obligations under GDPR and the EU AI Act.
Every engagement is led personally by one of the partners. If there's a fit, you get a personal first read of your case within one business day — not a canned demo.
