Live app
Website URL
Check reachable pages, browser scripts and endpoints in a deployed app.
A URL scan does not read your private repository or prove every user-role permission.
View the live-app sample reportProduct · Scanner
Check what your live app exposes.
Start with a deployed URL to check reachable pages, browser scripts and endpoints for potential security issues. Private repository review is a separate input and report, available through GitHub or a source ZIP.
- Reachable-page, script, auth, API and configuration checks
- Only scan apps you own or have permission to test
- Evidence and fix guidance to review with your coding tool
- Works with Lovable, Bolt, v0, Replit, Cursor
Illustrative live-app findingsExample
- Exposed Supabase service_role keyCritical
- Unexpected anonymous record accessCritical
- Missing CSP headerHigh
- Cookies without Secure flagMedium
- X-Frame-Options presentOK
Fictional illustration, not a live scan or an accuracy claim
How it works
3 steps to your first result.
- 1
Choose an authorized URL
Start with your deployed app. Review the scan terms; use staging or dedicated test accounts for sensitive workflows.
- 2
Check the reachable surface
The scanner reviews discovered pages, scripts and endpoints. Access restrictions, time limits and unsupported workflows can leave gaps.
- 3
Review evidence and coverage
Use the available finding detail and guidance to investigate a change. The 7-day trial includes full findings and fixes across 3 URL or repository scans.
What you get
Exposed secrets
Detects API keys leaked into JS bundles (Supabase service_role, OpenAI, Stripe live keys, AWS).
Database security
Checks observable database access through reachable interfaces. A URL scan cannot read every private policy definition or prove every role is isolated.
Auth flows
Checks for IDOR, broken session handling, missing rate limits, and weak password policies.
Headers & CSP
Audits CSP, HSTS, X-Frame-Options, COOP, COEP, Permissions-Policy, and cookie flags.
Endpoint discovery
Discovers reachable routes, scripts and API candidates. A route name or successful HTTP response alone does not establish a vulnerability.
AI-ready fixes
Bring available evidence and guidance into your coding tool. Review the proposed change and test legitimate access before deploying.
Check what shipped and what is in the code
Two complementary views: test a live-app URL, or review source from GitHub or a ZIP. Neither replaces the other.
Source code
GitHub repository or source ZIP
Review supported source files, dependencies and configuration in a selected snapshot.
Source findings do not prove the same code is deployed or that an issue is exploitable in the live app.
View the fictional code sample reportAutomated checks have coverage limits. No findings is not proof of security, and no longer detected is not a confirmed fix.
Frequently asked
- Is it safe to run on a production app?
- Scans send requests and can perform bounded active checks, so they may affect logs, rate limits or test records. Only scan authorized apps. Review the terms and use staging or dedicated test accounts for sensitive workflows; do not assume every check is read-only.
- How long does a scan take?
- A standard live-app scan usually takes a few minutes. Pro's scheduled extended live-app scan can use a longer crawl and additional access-control checks when a test login is configured. Both check the running app; neither is a repository scan. Duration and coverage depend on the target and limits.
- Which platforms work?
- Any deployed web app, built with Lovable, Bolt, v0, Replit, Cursor, or by hand. Backed by Supabase, Firebase, or your own stack. If it's reachable over HTTPS, we can scan it.
- What does a fix actually look like?
- A finding explains the observation, why it may matter and a proposed approach. URL findings can suggest likely files, not verified private-source locations. Repository reports can point to selected source files and lines. Neither should be applied blindly.