Lovable and Bolt.new
Changes described in plain terms as well as code, because a chat-based builder applies them through its chat and settings. Detected from a fingerprint or a .lovable.app, .gptengineer.app, .bolt.new or .stackblitz.io hostname.
Reports A finding you can't act on
A finding you can't act on
is just anxiety
Raw scanner output is a list of things that are wrong, written for someone who already knows what they mean. Every SecScan report goes through a second pass that rewrites it for the person who has to fix it — and generates one prompt they can paste into any AI coding tool.
See a real sample report →What's in a report
Every finding carries its own evidence — the exact HTTP response, header value or decoded payload that triggered it — plus a CWE identifier, a WSTG reference, and a confidence score. On top of that sit five written sections.
- 01
Overall risk
One paragraph a non-specialist can take to a stakeholder.
- 02
Top priorities
What to fix first, ordered by consequence rather than by severity label.
- 03
Quick wins
Findings that clear in minutes — usually a header, a flag or a deleted file.
- 04
Compliance notes
Findings mapped to SOC 2, PCI DSS, ISO 27001, OWASP ASVS, NIST SP 800-53 and HIPAA Security Rule controls by CWE. Omitted when nothing maps.
- 05
Fix prompt
One paste-ready instruction that works in any AI coding tool.
One fix prompt, for every AI coding tool
"Enable Row Level Security on that table" is correct and useless if you have never opened a SQL console. So the report ends with a prompt you can paste into any AI coding tool: Claude Code, Cursor, Codex, GitHub Copilot, Windsurf, Grok Build, Gemini, ChatGPT, Lovable, Bolt, Replit, v0 and the rest. It names no tool and uses none of a tool's own commands, so the same text works in all of them.
Each finding gets its own section: the problem in one sentence, the exact fix, where to look (what to search for, never an invented file path) and one way to check it worked. An exposed secret always comes first, with an instruction to rotate it as well as remove it. The prompt asks for the smallest change that fixes each issue, for the whole project to be searched for the same insecure pattern, and for a list of what changed, what could not be fixed and why. A tool that can edit your files applies the fixes. A chat-only tool replies with the exact change to make for each one.
The one thing that varies is a short set of stack notes, taken from what the scan detected about the site, about where fixes live on that platform:
Next.js
Headers in next.config or middleware, route handlers under app/api, and the exact file to edit.
WordPress
Plugins, wp-config.php, .htaccess and Admin Panel paths, not code.
Supabase
SQL for the SQL Editor, dashboard steps and code changes as three labelled parts, when no major framework sits alongside it.
Shopify, Wix, Squarespace, Webflow
Each finding split into what you can change in the platform and what only the platform controls.
Firebase
Security rules, console changes and firebase.json headers, when no framework sits alongside it. A Firebase web key is public by design.
Vercel
Headers and redirects in vercel.json, when no framework is detected.
Netlify
Headers in _headers or netlify.toml, when no framework is detected.
Anything else
No stack notes; each finding’s own remediation.
Detection runs most-specific-first: a hostname on .lovable.app
wins over a generic React fingerprint. Supabase, Firebase, Vercel and Netlify
add their notes only when no major framework is detected alongside them,
because the framework then decides how the code is edited.
AI analysis availability
The written analysis in every report runs on a third-party AI provider. If no key is configured for it, the scan still completes and the report still renders. Every external dependency degrades gracefully: the AI pass, the email sender and the payment layer each check for their key at startup and log a warning if absent rather than failing the run. If the AI provider fails or returns nothing, the report says so, and its fix prompt is assembled from the findings themselves instead of being written by the AI.
You can turn the written analysis off in Settings, under Privacy. The provider is sent the findings for each scan (names, descriptions and evidence, with anything shaped like a password or key removed) and never the credentials used for a credentialed scan. With the setting off, none of that is sent. The scan and every finding are unchanged; the report simply has no written summary or fix prompts, and says why.
Sharing a report
Reports are private to your account. To show one to someone — a client, a contractor, the person who actually owns the server — you generate a tokenised share link with an expiry of 7 days, 30 days, or never. Links can be revoked at any time, and revocation is immediate rather than a flag the viewer's cache might ignore.
A share link exposes the findings, which is to say a map of your application's weak points. Prefer a 7-day expiry over "never" unless the report is genuinely meant to be permanent, and revoke it when the conversation ends.
Comparing scans
Rescanning the same target produces a comparison rather than an isolated snapshot: what was fixed, what is new, and whether the grade moved. With continuous monitoring on, that comparison runs on a schedule and a regression — a finding you had cleared coming back — raises an alert on its own.
Each report opens with a "Since your last scan" card listing what was fixed, what is new and what is unchanged. A finding counts as fixed only if the test that raised it ran again and came back clear; if that test did not run, it is shown as not re-checked rather than fixed.
Checking a fix
Under each finding's recommended fix, "Check it" re-scans the site and judges the result against that one finding. The answer is one of fixed, still present, or not re-checked when the test could not run. It does not use up one of your scans.
Once a finding's latest check says fixed, it leaves the open list and the open counts and moves into a collapsed "Fixed since this scan" section, where its card still shows "Fixed and verified". The cover's severity counts drop it too. The grade and the AI analysis belong to the scan itself and are not recalculated, and the analysis card says it was written before the fix. Only a "fixed" answer moves a finding; "not re-checked" never does.
Confidence scores
Findings carry a confidence value because not all evidence is equally strong. An out-of-band SSRF callback carrying a token that appears nowhere else is confidence 95 — there is effectively no other explanation. A behaviourally confirmed injection sits at 90. A missing header is simply observed. Where a check cannot reach certainty, the report says so instead of rounding up.
Compliance mapping
Every finding also carries the framework controls it's evidence for — SOC 2, PCI DSS 4.0.1, ISO 27001:2022 Annex A, OWASP ASVS 4.0.3, NIST SP 800-53 Rev. 5 and the HIPAA Security Rule technical safeguards — keyed off the finding's CWE, and the report includes a per-framework summary. A reviewer who asks "show me you test for injection" gets findings mapped to PCI DSS 6.2.4 and ASVS V5.3.3: real, checkable work instead of a claim.
What this is not: a compliance assessment, an audit, or an attestation. A scan sees the HTTP surface of a running application at one moment; SOC 2 and ISO 27001 are overwhelmingly about policy, personnel and process that no scan can observe. There is no percentage or pass rate anywhere in the mapping — a framework nothing maps to is left out of the report rather than shown as passing. Only a licensed CPA firm issues a SOC 2 report, only a QSA validates PCI DSS, and only an accredited body certifies ISO 27001.
Read one against your own site
Every account gets 3 free scans every month. Takes a minute to sign up and verify your email.
Generate a report →