SECURITY / TOOL

LOVABLE DETECTOR

Paste a URL. We look at the bundle, the network requests, and the deployment host, and tell you whether it was built with Lovable.dev — plus the RLS, credential, and auth issues we commonly find in Lovable apps.

What a Lovable detector actually checks

A deployed Lovable app looks like a generic React SPA at a glance. Dig one layer deeper and the fingerprints are unmistakable. The detector checks four classes of signal:

01 / BUNDLE FINGERPRINTS

Vite chunk naming conventions, shadcn/ui class names in the DOM (data-radix-*, Tailwind utility combinations), and React Router v6 link patterns. Lovable's template locks these in.

02 / NETWORK TRAFFIC

Calls to <project>.supabase.co/rest/v1/ with apikey headers containing a JWT. Edge Function invocations at /functions/v1/. GraphQL at /graphql/v1.

03 / HOSTING SIGNATURES

Default *.lovable.app subdomain, or a custom domain with Lovable's CDN headers (x-served-by, cache-control defaults). Distinct from Vercel and Netlify.

04 / META + TELEMETRY

Default OG tags, favicon, and a trailing data-lov-id attribute in the DOM. Telemetry pings that match Lovable's analytics pipeline.

Confidence scoring: three or more signals in the same category lock in a positive. Two signals mean probable. One is a hint — usually not enough.

Why detect Lovable before you audit

Knowing the platform cuts audit time in half. A Lovable app has a predictable failure profile — the same five or six flaws show up in almost every one. Once detected, a pentester can skip the generic “what framework is this?” phase and jump straight to the probes that actually matter:

  • Every Lovable app uses Supabase. Check RLS on every table.
  • Every Lovable app ships the anon key in the frontend bundle. Check if it’s a read/write key to tables without policies.
  • Every Lovable app can have Edge Functions. Check whether any are invoked with the service-role key from the browser.
  • Every Lovable app has a Storage bucket. Check if it’s public.
  • Every Lovable app has a login/signup flow. Check session token handling and password-reset abuse.

For detailed per-issue context, see Is Lovable Safe? and the full Lovable Security Scanner.

Running the detector

Paste the URL of a deployed Lovable-suspected app at the top of this page. The detector runs a read-only fingerprint check (no writes, no account data touched) and returns:

  • Verdict: Lovable / not Lovable / ambiguous
  • Confidence: percentage with which signals matched
  • Stack surface: Supabase URL, Edge Functions discovered, Storage buckets seen
  • Next step: a one-click link to the full security scan against the detected stack

The fingerprint check usually completes in under 15 seconds.

What “Lovable detected” means for your security posture

Detection is a starting point, not an assessment. Lovable the platform is safe. Lovable apps — as of April 2026, across 1,430+ scanned projects, and in the most recent 48-day chat-history exposure — ship with a consistent cluster of misconfigurations. The detector tells you what you’re looking at. The full scan tells you what’s actually broken.

If you’re auditing someone else’s Lovable app (with authorization), start here, then escalate. If you’re auditing your own, treat the detector output as a pre-flight check before running the full scan.

Sources and references

/ FAQ

COMMON QUESTIONS

01
What is a Lovable detector?
A Lovable detector is a tool that fingerprints a deployed website to determine whether it was generated by Lovable.dev. It looks at the built JavaScript bundle, the network requests (especially the Supabase REST/GraphQL endpoints), the response headers from the hosting provider, and the typical file paths that Lovable ships. Output: yes/no, plus the confidence score.
Q&A
→
02
How can I tell if a site was built with Lovable.dev?
Four signals usually clinch it: (1) a Vite-bundled React SPA with shadcn/ui class names in the DOM, (2) direct calls to a supabase.co REST endpoint with the anon key in the request header, (3) a lovable.app subdomain or a custom domain fronting one, and (4) specific telemetry/analytics calls Lovable ships by default. Our detector checks all four and more.
Q&A
→
03
Why would I want to detect that a site is built with Lovable?
Security auditors and pentesters use Lovable detection to scope a bug-bounty engagement — Lovable apps have a predictable set of failure modes (missing RLS, exposed anon keys, open Edge Functions) so knowing the platform narrows the probe dramatically. Competitive analysts use it to size the Lovable install base. Individual users use it to know what their own app is running on.
Q&A
→
04
Does the detector work on apps deployed to custom domains?
Yes. Lovable deployments keep their fingerprints even when fronted by a custom domain — the bundle chunk names, the Supabase endpoint hits, and the server response metadata still line up with a Lovable build. Custom-domain detection is the default mode.
Q&A
→
05
Is the detector free?
Yes, the detection check is free and does not require an account. Running the full security scan against the detected stack (RLS probes, auth bypass, key exfiltration) uses a VibeEval trial account — free for 14 days, no card required.
Q&A
→
06
What happens after Lovable is detected?
The detector surfaces the Supabase URL, the anon key if exposed in the bundle, the Edge Functions it discovered, and any obviously misconfigured Storage buckets. You can then run the full scan to test every finding against OWASP API Top 10 and the failure modes we see across 1,430+ audited Lovable projects.
Q&A
→
07
Can I detect Lovable in an app that's not yet deployed?
The detector works on any publicly reachable URL. If the app is local-only (localhost, private VPN) the detector cannot see it — but the security scan can still run against a staging URL if you have one.
Q&A
→
08
What other vibe-coding platforms can VibeEval detect?
Lovable, Bolt.new, v0.dev, Base44, Firebase Studio, Figma Make, Replit, and Cursor-generated deployments. The same bundle-fingerprint technique works across all of them — see our broader vibe code detector for the multi-platform check.
Q&A
→
/ NEXT STEP

RUN THE FULL SECURITY SCAN

Once the stack is identified, run the full probe: RLS, auth, storage, exposed keys.

RUN SECURITY SCAN →