Lovable Detector: Is a Website Built With Lovable.dev?

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:

Detection is reconnaissance, not exploitation. The same signals power both a founder’s inventory tool and an attacker’s target list - which is why running detection against your own properties is basic hygiene in 2026, not paranoia.

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.

Fingerprints in more depth

Bundle and DOM

Lovable’s generator favors a consistent front-end kit: Vite for bundling, React, Tailwind utility classes, and shadcn/ui primitives built on Radix. In the DOM you often see data-radix-* attributes, recognizable component class combinations, and client-side routing structure that matches the template rather than a bespoke design system.

JavaScript chunk names and asset path layouts from Vite production builds are not unique to Lovable alone - many apps use Vite - but combined with Supabase client bootstrap patterns and Lovable-specific markers they become discriminative. Source maps, when accidentally deployed, can make template provenance even clearer; that is also a separate security issue (source map checker).

Network and Supabase client

Almost every Lovable full-stack app speaks to Supabase from the browser. Observable traffic includes:

• REST: https://<ref>.supabase.co/rest/v1/<table>
• Auth: /auth/v1/...
• Storage: /storage/v1/...
• Functions: /functions/v1/<name>

The anon key appears as apikey and often again in Authorization: Bearer. Finding that key is not by itself a vulnerability - Supabase designs the anon key for the client - but it is a high-value reconnaissance artifact. With project URL + anon key, a tester (or attacker) can probe RLS immediately. Detection therefore double-serves inventory and attack surface mapping.

Hosting and headers

Default *.lovable.app hosts are trivial positives. Custom domains require correlating CDN/cache headers, cookie behaviors, and residual links to Lovable assets or docs. Teams that re-deploy exports to Vercel/Netlify lose some host signals but usually keep bundle + Supabase signals.

Meta, telemetry, and DOM IDs

Default Open Graph tags, favicons, and attributes such as data-lov-id are low-effort tells. Telemetry endpoints that match Lovable’s pipeline raise confidence when present. Stripping them is possible after export; absence does not prove “not Lovable.”

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.

Across 1,430+ scanned projects and the Feb 2026 wave of 170+ open databases, that checklist is not theoretical. Platform detection is how you prioritize which hosts get the deep probe first when the target list is long.

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 “read-only” means

Detection issues GET (and equivalent safe) requests to load the document, linked scripts, and observe public responses. It does not attempt login brute force, data modification, or destructive Storage operations. Escalation to full security scanning is a separate, explicit step - and still requires authorization when the app is not yours.

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.

Security implications after a positive detection

Use detection output as a structured work queue:

1. Inventory secrets in the bundle - anon key, third-party public keys, accidental service-role or Stripe secret material (token leak checker).
2. Enumerate tables via REST - with authorization, test select without auth, with user A, with user B (BOLA).
3. Storage - list and download paths; check public buckets.
4. Edge Functions - unauthenticated invoke; privilege inside function code; SSRF-ish outbound patterns.
5. Auth abuse - signup floods, reset token handling, session fixation basics.
6. Headers and CORS - credentialed cross-origin access (CORS checker).

A positive Lovable fingerprint without a follow-up probe is incomplete diligence - especially for acquisitions, bug bounties, and pre-launch founder checks.

How pentesters and auditors use Lovable detection

Professional use cases:

• Scoping - Confirm stack in the first hour; write test cases from a Lovable-specific methodology (Lovable pentesting) instead of generic OWASP-only fluff.
• Asset discovery - Given a list of marketing sites and app subdomains, bulk-detect which are Lovable to prioritize Supabase-focused testing.
• Regression - After a client “fixed RLS,” re-detect to ensure they did not merely rebrand hosting while redeploying the same open policies.
• Competitive / market research - Non-intrusive counts of Lovable fingerprints on public URLs (still respect robots, rate limits, and law).
• Incident response - When a brand is listed in a mass-exposure report, confirm whether a property is on the affected stack class.

Pair detection with vibe hacking awareness: attackers automate the same fingerprint → RLS scrape loop. If criminals can detect you, defenders should detect themselves first.

False positives, false negatives, and confidence

False positives

Hand-rolled apps that copy the Lovable aesthetic - Vite, shadcn, Supabase - can trip bundle and network heuristics without ever using Lovable. Multi-signal agreement (host + telemetry + DOM markers) reduces this. When confidence is mid-range, read the signal breakdown: “Supabase + Vite only” is weaker than “Supabase + lovable.app residual + data-lov-id.”

False negatives

Teams that export code, rename chunks, remove telemetry, switch to a custom API layer, or heavily code-split can fall below threshold. Server-rendered wrappers or Cloudflare workers in front of the SPA may obscure some headers. Ambiguous is a valid output - then fall back to manual stack analysis.

Confidence hygiene

Do not treat 51% as courtroom proof. Use tiers:

Limitations

• Public URL only - Localhost and VPN-only apps are invisible to the hosted detector.
• No substitute for RLS testing - Detection does not prove data is safe or exposed.
• Evolving templates - Lovable generator updates change fingerprints; detectors need maintenance.
• Multi-platform hybrids - A Lovable front end with a custom Nest API may only partially match.
• Legal/ToS bounds - Detection of public assets ≠ permission for aggressive scanning.
• CDN caching and bot walls - Aggressive bot protection may block fingerprint fetches; results can be incomplete.

Manual fingerprint checklist (no detector UI)

If you need to confirm stack by hand during a browser-only recon:

1. View source / network: look for supabase.co, supabase.in, or self-hosted Kong/PostgREST patterns with apikey headers.
2. JS assets: Vite-style /assets/index-*.js chunks; search bundled text for createClient and Supabase auth storage keys (sb--prefixed localStorage).
3. DOM: Radix/data-radix-*, shadcn-like class clusters, possible data-lov-id.
4. Host: *.lovable.app is definitive; custom domains need more signals.
5. Headers: CDN cache headers and server banners that differ from pure Vercel/Netlify defaults (not decisive alone).
6. Favicon / OG: default Lovable branding leftovers after rushed deploys.

Document each signal for your report. Single-signal “Lovable” claims are weak in legal or customer contexts - multi-signal is better.

Why attackers automate detection

Mass vulnerability hunting needs cheap triage. A fingerprint that implies:

• Browser-visible Supabase project ref
• SPA with client-side auth
• Historical rate of missing RLS

…is enough to queue thousands of hosts into a scanner. That is the vibe hacking loop: detect → extract anon key → dump open tables → move on.

Defenders should assume their Lovable (or Lovable-like) app is already categorized if it is on the public Internet. Obscurity of the generator is not a control; RLS is.

Detection vs tech-stack security readout

A good detector response separates:

Do not stop at “yes, Lovable.” The value is the attack surface map that detection gives you in minutes instead of hours.

Enterprise and bug-bounty program use

Bug bounty triagers: use detection to route reports - “Lovable + open RLS” is a known high-signal class; prioritize accordingly.

ASM / attack surface management: schedule bulk fingerprint jobs on owned domains after marketing launches new microsites (teams forget shadow Lovable experiments).

M&A technical diligence: 50 product URLs in a portfolio → detector pass → deep scan only on positives and high-value targets.

Always stay inside authorization and rate limits. Detection traffic should look like a polite crawler, not a flood.

Hardening that reduces fingerprint noise (not a substitute for RLS)

Some teams want to look less like a default Lovable deploy:

• Export and rebuild with your own bundler settings / chunk names
• Remove telemetry and data-lov-* markers
• Custom domain + your CDN
• Replace default OG tags and favicons

This may lower detector confidence and casual attacker interest. It does not fix open databases. Skilled attackers still find supabase.co in the bundle. Spend engineering time on policies first; cosmetics second.

After detection: founder playbook

If this is your app and the detector says Lovable:

1. Run the full Lovable security scanner / VibeEval probe.
2. Turn on RLS for every table; fix Storage; remove service-role from any client path.
3. Rotate any key that was ever committed or shipped in a public bundle accidentally (beyond normal anon).
4. Re-test with a second account for BOLA.
5. Add a CI preview scan so the next prompt does not reopen policies (CI/CD security guide).
6. Read How to Secure Lovable and Is my Lovable app secure?.
7. Inventory Edge Functions and Storage buckets named in the detector output - fix those next.
8. Confirm Auth redirect URLs and email templates point only at your domains.

Related tools

• Vibe Code Scanner - multi-platform security scan for AI-generated apps
• Lovable Security Scanner - full RLS / auth / credential audit for Lovable
• Supabase RLS Checker - standalone Row Level Security probe
• Is Lovable Safe? - the full security analysis of the Lovable platform
• Lovable BOLA Vulnerability - the April 2026 disclosure in context
• Firebase Scanner - if the stack is Firebase instead of Supabase
• Lovable tech stack guide - architecture map after detection
• Vibe hacking - attacker automation that starts with fingerprints like these

Detector output as input to a pentest scope document

Copy this skeleton when detection is positive:

Target: https://app.example.com
Generator confidence: High (Lovable)
Backend: Supabase ref <xyz>
Identities for test: anon, userA, userB
In-scope:
  - PostgREST tables discovered via OpenAPI
  - Storage buckets listed in network log
  - Edge Functions: <names>
  - Auth endpoints
Out of scope:
  - Third-party marketing pixels
  - Physical social engineering
Success criteria:
  - No cross-user data on REST
  - No service_role in bundle
  - No public private-files

Scoped testing prevents both under-testing (forgot Storage) and over-testing (attacking the CDN vendor itself).

Agencies: billing and client communication

When you detect Lovable on a client property:

1. Explain in plain language: “Your app talks to a database API from the browser; security depends on policies.”
2. Do not shame the tool choice - offer a fix path.
3. Quote remediation as policy work + rescan, not a full rewrite, when appropriate.
4. Keep detector evidence (headers, script URLs) in the appendix for technical stakeholders.

Clients panic less when you separate platform legitimacy from configuration debt.

Fingerprint ethics and ToS

Only scan systems you own or have permission to assess. Passive detection is low impact; do not escalate to data extraction without authorization. Rate-limit bulk jobs; respect robots and local law.

Engineering use case: portfolio audits

Agencies inheriting Lovable apps can batch-detect which client domains are still on the stack, then schedule RLS remediations. Detection without remediation is vanity metrics - pair every positive with a scheduled scan and a ticket template for missing RLS.

Differentiating Lovable from “hand-rolled Vite + Supabase”

False positives matter when you report stack to a client or bounty program. Weighted signals:

Require two independent classes (host/meta + network, or network + DOM marker) before writing “built with Lovable” in a formal report. “Supabase SPA” is still useful for methodology even when generator confidence is medium.

Bulk detection workflow for ASM

1. Collect apex + app subdomains from CT logs, marketing site links, and GitHub pages references.
2. Rate-limit polite GETs; cache HTML and main JS hashes.
3. Run fingerprint rules offline on the corpus.
4. Queue High-confidence hits for authorized deep scans only.
5. Ticket owners with detector evidence appendix (script URLs, header samples).

Do not dump tables during detection. Detection is inventory; exploitation without authorization is illegal.

What changes after Lovable export

Teams export to GitHub and redeploy on Vercel/Netlify. Expect:

• Host signals drop; bundle + Supabase signals remain.
• Env var renames can accidentally ship service_role under a new public prefix - re-run Token Leak Checker.
• Auth redirect URLs must include the new domain or OAuth breaks (or worse, leftover tunnels stay allowlisted).

Detection confidence may fall from High to Medium after a careful rebrand; security risk often stays identical until RLS is fixed.

Pairing detector output with gapbench shapes

When training juniors, map detector “Lovable + Supabase” to public gapbench scenarios:

• supabase-clone - RLS off / permissive
• config-leak - service-role shaped material

Practice the probe on gapbench, then apply the same curls to authorized client apps. See also the controlled comparison in Lovable vs Bolt vs Cursor same-spec.

Detector maintenance and template drift

Lovable ships generator updates that rename chunks, change default CSS tokens, or alter telemetry endpoints. Detectors that hard-code one year’s markers go stale. Operational practice:

• Version fingerprint rules; log which rule fired.
• Re-validate quarterly against known Lovable showcase URLs you own.
• Prefer durable signals (supabase.co REST + anon JWT shape) over fragile ones (exact chunk hash).

If confidence collapses industry-wide after a Lovable release, fall back to methodology based on observed backend, not brand name.

Curl recon cookbook (authorized targets only)

URL="https://app.example.com"
# HTML + linked scripts
curl -sL "$URL" -o /tmp/page.html
grep -oE 'https?://[^"'\'' ]+\.js' /tmp/page.html | head
# Supabase project refs in JS
curl -sL "$URL" | tr '"' '\n' | grep -E 'supabase\.(co|in)' | sort -u
# Anon JWT shape (eyJ...) in main document - confirm in Network tab for full accuracy
grep -oE 'eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+' /tmp/page.html | head

Decode the JWT payload (middle segment, base64url) and check role. Expected for client keys: anon or authenticated template - never service_role. If you see service_role, escalate to incident rotation immediately (token leak).

Writing detector findings into client reports

Recommended language:

“Public JavaScript and network behavior are consistent with a Lovable.dev-generated React + Supabase application (confidence: High). The anon API key observed is expected for Supabase client apps; security depends on Row Level Security policies, which require separate testing.”

Avoid: “The site is insecure because it is Lovable.” Platform ≠ posture.

Comparison: detector vs full security scan

Use the detector to prioritize; use the Lovable security scanner to prove data safety.

Shadow IT discovery story (anonymized)

A mid-size company found twelve *.lovable.app hosts via CT logs and marketing microsites launched by non-engineering teams. Eight had open RLS on lead-capture tables. None were in the official asset inventory. Detection + mandatory scan policy closed the gap in two sprints. Without fingerprinting, those apps stayed invisible to AppSec.

Sources and references

• Lovable Security Report Feb 2026 - 18,000 users exposed, 170+ databases breached
• Vibe Coding Security Weekly - Apr 23, 2026 - 48-day chat exposure, full timeline
• Supabase documentation on the anon key - why the browser gets a JWT and what RLS has to do