Environment values exposed in frontend output
A credential can move from a private workspace secret into a client-side bundle through an incorrect build-time prefix or import.
Security for Bolt apps
BoringSec evaluates the deployed application first and shows early evidence while deeper authorized engines continue. Source-only questions remain clearly separated from what a public URL can prove.
Run it before sharing a prototype publicly and after changes to auth, database rules, integrations or deployment configuration.
Run scans only on systems you own or are authorized to assess. Deep engines require verified authorization and may remain unavailable for a target.
Example report structure
This is an illustrative finding, not a result for your application. Live reports show the scanner, evidence state and coverage limits for the actual target.
Common risk paths
These are risk patterns relevant to Bolt.new projects—not claims that every project has them. A finding appears only when a scanner returns supporting evidence.
A credential can move from a private workspace secret into a client-side bundle through an incorrect build-time prefix or import.
Supabase tables, storage buckets or Firebase databases can remain reachable even when the interface looks locked down.
Broad or reflected CORS behavior can let an untrusted origin read API responses in a user’s browser.
Honest coverage
URL evidence, connected source and authorized deep engines answer different questions. BoringSec keeps those sources separate and shows partial, blocked and unavailable states instead of turning an untested surface into a pass.
Read the public methodologyChecks the public response path for TLS, security headers, DNS and email authentication, cookies, CORS, exposed files, technology signals and other externally observable controls.
Inspects bounded, same-origin frontend bundles for secret-shaped values and records partial coverage when an asset cannot be fetched or exceeds a safety limit.
Nuclei, OWASP ZAP and Medusa continue asynchronously only when the requested scan is authorized and the engine is available. Their running, blocked or unavailable state stays visible.
A separately connected repository can add source-level evidence for committed secrets, auth and database risk patterns, dependency advisories and server/client boundary mistakes.
From observation to verification
Inspect the public response path and start eligible background engines.
See what was observed, by which scanner and with what confidence.
Use a concrete remediation path and the Bolt-relevant context.
Run a fresh assessment; monitoring can detect later regressions separately.
No. A live scan starts from the deployed URL and observes only the public surface. Repository access is a separate, explicit connection and is not required for the URL scan.
It can support findings with externally observable evidence such as response headers, TLS behavior, public files, shipped bundles and bounded backend probes. It cannot prove that private source code or authenticated workflows are safe.
No automated scan can prove complete security. BoringSec reports assessed, partial, unavailable and authorization-required coverage explicitly so a clean result is not presented as evidence for surfaces that were never tested.
No. BoringSec is an independent security service and is not sponsored by, endorsed by or affiliated with Bolt.new.
Start with the public URL. Add source or authenticated context only when you choose to expand coverage.
Start a security scan