Skip to content
MLVibeScan

Vibe Coding Security Scanner · Servers in Germany

MLVibeScan

Prove that your AI app actually became safer. No fear score: every important finding comes with evidence and a controlled re-test.

Free external scan · no account · safe proof card · deep and code scans only after purchase and domain verification · See what a finished report looks like

Built with these? Then you’re in the right place.

  • Lovable
  • Bolt
  • v0
  • Cursor
  • Windsurf
  • Replit
  • Claude Code
  • Copilot
  • Base44
  • Firebase Studio

The verifiable security cycle

Do not just find it. Prove progress.

MLVibeScan combines technical evidence with controlled re-tests and a revocable attestation.

  1. Scan
  2. Understand
  3. Fix
  4. Re-test
  5. Attest

  • 01

    Evidence-backed findings

    Evidence levels and masked locations instead of bare alerts.

  • 02

    Re-tests with history

    See what was fixed, what is new and what became worse.

  • 03

    Verified deep scan

    Active checks run only after technical domain verification.

  • 04

    Code and live behaviour

    ZIP source analysis and runtime checks are correlated to the same protection target.

  • 05

    Tool-specific fix packages

    Reviewed instructions for Lovable, Bolt, Cursor, Claude Code, Replit, v0 and Base44.

  • 06

    Public attestation

    Time-limited, revocable and automatically invalid on regression.

How we test and rate

What we find

The mistakes vibe-coded apps ship with

  • Credentials in the frontend

    Stripe, Supabase, OpenAI or AWS keys sitting in the JavaScript you ship. Bots harvest them from public bundles automatically — the bill lands on your desk.

  • Open database rules

    Supabase tables without Row Level Security. The key you need is public in your app — anyone can download your users table.

  • Public source maps

    Your unbuilt original code, filenames and comments included, readable by anyone in the browser.

  • Missing security headers

    CSP, HSTS, X-Frame-Options and the rest. Without them a small hole becomes an exploited one.

  • Unprotected sign-in

    No limit on failed password attempts. Working through leaked password lists then takes minutes.

  • Over-permissive CORS

    When any third-party website may call your API on behalf of your signed-in users.

  • Forgotten files

    .env, .git/config or a database dump that ended up in the public directory by accident.

  • Talkative error pages

    Stack traces and server paths in the response — the map an attacker would otherwise have to draw by hand.

  • TLS and certificate

    Expired or invalid certificates, missing HTTPS redirect, outdated encryption.

  • security.txt and DNSSEC

    Whether security researchers can reach you and the DNS zone is visibly hardened against manipulated answers.

  • Cache protection for sign-in and account

    Whether sensitive authentication responses may accidentally be stored in browser or proxy caches.

  • Email spoofing protection

    Missing SPF and DMARC records. Without them anyone can send phishing mail from your address.

  • Cookie security

    Session cookies without HttpOnly or Secure — the ticket to an account takeover.

  • External threat databases

    Whether your domain has already been reported as malicious. That happens after a breach — often before you notice it yourself.

  • Outdated libraries

    Which JavaScript packages you ship and whether known vulnerabilities are documented for those exact versions. Publicly documented means the instructions for exploiting them are freely available.

  • Forgotten environments

    The staging or preview address that has been running for months with real data and no sign-in, because nobody thinks about it any more. We find it through the public certificate log.

  • Development server in production

    Publishing with npm run dev instead of npm run build puts a server on the internet that was never meant to be there — including a path that hands out arbitrary files. In the browser you cannot tell the difference.

  • Someone else’s code in your app

    Packages from documented npm supply chain attacks, code that records form input, crypto miners. Not every breach is visible — but these traces are.

The free scan covers everything on this list that is detectable from the outside. Database rules and password guessing are part of the full report and additionally require proof that the domain is yours.

Scope

What we look for

Not the detection rules — those stay with us. But the names, so you can tell whether your stack is covered.

  • Supabase Row Level Security
  • Firebase Security Rules
  • Stripe Live Keys
  • Takeoverable subdomains
  • Exposed .git directory
  • Unrestricted Google keys
  • Dev server in production
  • Compromised npm packages
  • Skimmer in the bundle
  • Crypto miner
  • Malicious service workers
  • GraphQL-Introspection
  • Exposed Swagger docs
  • Metrics endpoints
  • Hallucinated package names
  • Plaintext passwords
  • Archived .env files
  • Unprotected API endpoints
  • Subresource Integrity
  • Database schema exposed
  • Password reset flood
  • OpenAI
  • Anthropic
  • AWS
  • GitHub Token
  • service_role
  • Clerk
  • Vercel
  • Neon
  • Upstash
  • MongoDB Atlas
  • Groq
  • Replicate
  • SendGrid
  • Twilio
  • Discord Bot Token
  • JWT signing secret
  • Private keys
  • DB connection strings
  • CSP
  • HSTS
  • X-Frame-Options
  • Referrer-Policy
  • Permissions-Policy
  • CORS
  • Cookie flags
  • TLS certificate
  • HTTPS redirect
  • security.txt
  • DNSSEC
  • Auth cache protection
  • SPF
  • DMARC
  • Source Maps
  • .env
  • .git/config
  • package-lock.json
  • Database dumps
  • Dockerfile
  • Stacktraces
  • Debug mode
  • Rate limiting
  • Password guessing
  • Blocklist entry

The free scan covers everything on this list that is detectable from the outside. Database rules and password guessing are part of the full report and additionally require proof that the domain is yours.

Bevor du auf „Publish" drückst

Was es kostet, es nicht zu wissen

Eine Lücke in einer vibegecodeten App ist keine kleinere Lücke, nur weil die App schnell entstanden ist. Sie steht im selben Internet wie alle anderen.

  • Gestohlene Schlüssel kosten sofort Geld

    Automatisierte Bots durchsuchen öffentlich erreichbare JavaScript-Bundles gezielt nach Zugangsdaten. Ein OpenAI-, Stripe- oder AWS-Schlüssel im Frontend wird nicht irgendwann gefunden, sondern zeitnah — und dann bis zum Limit deines Kontos benutzt.

    Die Rechnung geht an dich

  • Eine offene Datenbank ist ein meldepflichtiges Datenleck

    Fehlt bei Supabase die Row Level Security, kann jeder mit dem öffentlichen Schlüssel aus deinem Frontend die komplette Nutzertabelle herunterladen. Sobald personenbezogene Daten betroffen sind, ist das kein technisches Problem mehr, sondern ein rechtliches.

    Art. 33 DSGVO: 72 Stunden bis zur Meldung an die Aufsichtsbehörde

  • Betroffene können Schadenersatz verlangen

    Nach Art. 82 DSGVO haben Betroffene einen eigenen Anspruch auf Ersatz — auch für immaterielle Schäden. Dazu kommt die Benachrichtigungspflicht gegenüber jedem einzelnen Nutzer nach Art. 34 und der Bußgeldrahmen nach Art. 83.

    Als Einzelperson haftest du persönlich

  • Deine Domain kann auf Sperrlisten landen

    Wird deine App übernommen und für Phishing missbraucht, melden Sicherheitsdienste die Domain. Browser zeigen dann eine ganzseitige Warnung, und deine E-Mails kommen nicht mehr an. Der Weg zurück dauert Wochen.

    Auch nach der Bereinigung bleibt der Eintrag eine Weile

  • Dein Quellcode liegt offen

    Versehentlich mitgelieferte Source Maps oder ein erreichbares .git-Verzeichnis geben deinen ungebauten Originalcode preis — inklusive aller Zugangsdaten, die jemals in der Versionsgeschichte standen, auch der längst gelöschten.

    Jedes je committete Passwort gilt als kompromittiert

  • Vertrauen bekommst du nicht zurück

    Der finanzielle Schaden lässt sich beziffern. Die E-Mail an deine Nutzer, in der du erklären musst, dass ihre Daten abgeflossen sind, ist die eigentliche Rechnung — und die zahlst du bei jedem künftigen Start mit.

    Der Schaden überlebt das Projekt

Unsere Devise

Nichts veröffentlichen ohne Scan.

Zwanzig Sekunden vor dem Livegang. Kostenlos, ohne Konto, so oft du willst — und du weißt, was du da eigentlich ins Netz stellst.

Jetzt kostenlos prüfen

„Claude Code hat meinen Code schon geprüft"

Gut so — und trotzdem bleibt eine Lücke. Nicht weil die Werkzeuge schlecht wären, sondern weil sie an einer anderen Stelle stehen als ein Angreifer.

  • Er sieht deinen Quellcode — nicht das, was ausgeliefert wird

    Im Code steht `import.meta.env.VITE_STRIPE_KEY`, und das sieht völlig harmlos aus. Erst der Build setzt den echten Wert ein, und alles mit dem Präfix VITE_ oder NEXT_PUBLIC_ landet dabei absichtlich im Browser. Was am Ende im Bundle steht, sieht man nur am Bundle.

  • Er sieht deinen Code — nicht deinen Server

    Security-Header, TLS-Zertifikat, HTTPS-Weiterleitung, CORS-Regeln und Cache-Verhalten kommen von Vercel, Netlify, nginx oder Cloudflare. Nichts davon steht in deinem Repository, also kann es dort auch niemand prüfen.

  • Er sieht deinen Code — nicht deine Datenbank

    Ob Row Level Security in deinem Supabase-Projekt tatsächlich eingeschaltet ist, steht nirgends im Code. Das ist ein Schalter im Dashboard. Man kann es nur feststellen, indem man die Datenbank fragt.

  • Er schaut von innen — wir von außen

    Ein Assistent prüft mit dem Wissen des Autors: Er kennt die Absicht hinter jeder Zeile. Wir kommen als anonymer Besucher an deine öffentliche Adresse — genau die Perspektive, aus der ein Angreifer schaut, und die einzige, die zählt.

  • Das Werkzeug bewertet seine eigene Arbeit

    Wenn dasselbe Modell den Code geschrieben und geprüft hat, sind blinde Flecken kein Zufall, sondern zu erwarten: Was es beim Schreiben für richtig hielt, hält es beim Prüfen erneut für richtig. Eine zweite, unabhängige Instanz findet, was die erste für selbstverständlich hielt.

  • Er prüft einmal — nach jedem Deploy ist alles anders

    Eine neue Umgebungsvariable, ein geändertes Hosting-Setup, ein zusätzliches Paket: Jede Auslieferung kann eine Lücke aufreißen, die gestern nicht da war. Bei uns ist der Scan kostenlos, also kannst du ihn zur Gewohnheit machen.

Deshalb ersetzt MLVibeScan deinen KI-Assistenten nicht — er prüft nach. Von außen, an deiner echten Adresse, an dem, was tatsächlich ausgeliefert wird. Ein zweites Paar Augen, das nicht mitgeschrieben hat.

For vibe coders

Built it with AI? Then this is for you.

If you built your app with one of these tools, you are the audience — not because you are a beginner, but because all of these tools share the same blind spot.

AI tools write code that works. They do not necessarily write it securely, and they do not tell you when something is missing. A language model puts a Supabase call in the frontend because that is the shortest path — whether Row Level Security backs it up is a question it never asks. It writes no security headers because you did not ask for any. And it has no idea which environment variables your build inlines into the bundle you ship.

That is not a complaint about the tools. It is the exact spot where an outside look finds what an inside look cannot: MLVibeScan tests your app at its public address — against what is actually on the internet, not against what is in your editor.

What this scanner is built for

  • Apps from Lovable, Bolt, v0, Base44 or Firebase Studio
  • Projects from Cursor, Windsurf, Claude Code, Copilot or Replit
  • Supabase and Firebase backends accessed straight from the frontend
  • First SaaS products, MVPs and side projects with real users
  • Anything running on Vercel, Netlify or Railway

If more than one of those sounds familiar, the scan takes twenty seconds and costs nothing.

Guide: understand vibe coding security

Privacy here is not fine print

Every public promise has a technical counterpart.

  • No copy of your code

    For URL scans, shipped files are analysed in memory. A voluntarily uploaded ZIP is isolated, processed without execution or an LLM and then deleted. Only the structured result is stored.

  • Servers in Germany

    Application and database run in a German data centre. External security sources receive only the queried domain from the scanner — never your visitor IP, code or report.

  • Findings are deleted automatically

    The findings disappear on their own once the retention period is up. No request needed, no reminder — a deletion run handles it hourly.

  • No account, no sign-up

    You enter an address and get a result. We create no user account and ask for no personal data.

  • No trackers, no third-party CDNs

    This website loads no trackers or third-party fonts in the browser. Your visitor IP is not passed to analytics or advertising services.

  • Read-only, never intrusive

    The scanner requests your page like a visitor. It changes nothing, creates nothing and deletes nothing.

  • Public only with your approval

    A badge and summary are never published automatically. The summary contains totals, never locations or evidence.

  • Attestation expires on regression

    A new critical or high issue invalidates the badge. An outdated deep scan is never presented as current.

90 days of security support for one domain

The scan is free. You only pay if we found something you want to fix — once, no subscription.

Free scan

Free

No account, no payment details

  • Count and severity of every finding
  • Broken down by area
  • Security grade from A to F
  • Some of the minor findings in full
Per domain, one-off

Full report

Final price · invoice included · no subscription

  • What exactly was found — in plain words
  • Where it sits: file, line, location
  • Ready-made fix prompt to paste into Cursor & co.
  • Report as a PDF to print and pass on
  • Re-test as often as you like after fixing
  • Deep check of your database rules after domain proof
  • Measured history: fixed, new or worsened
  • Eligibility for a verifiable badge when the criteria are met
  • Beta: secure JS/TS ZIP code scan without execution or LLM upload
  • Production readiness with code/runtime correlation
  • Eight tool-specific AI fix packages
  • Beta: weekly passive deployment monitor

Valid 90 days for every scan of this domain — as long as we keep your findings. A positive badge additionally requires a verified deep scan with no open critical or high findings.

Questions

What to know before your first scan

  • What is MLVibeScan?

    MLVibeScan is a security scanner for web apps built with AI tools such as Lovable, Bolt, v0, Cursor, Replit and Base44. Enter the deployed URL to get a free external security overview without an account.

  • What does a scan cost?

    The external scan is free. The complete report costs €9.49 once per domain and includes detailed evidence, fix instructions, PDF export and unlimited re-tests for 90 days. There is no subscription.

  • Does MLVibeScan store my source code?

    No. Deployed pages and JavaScript files are analyzed in memory and discarded immediately. Only findings are stored, with detected credentials masked, and reports are deleted automatically after 90 days.

  • What does MLVibeScan check?

    It checks recurring AI-built app risks including exposed API keys, open Supabase or Firebase rules, vulnerable packages, public source maps and Git files, missing security headers, broad CORS, weak cookies, TLS, DNS and abuse protection.

  • What is the deep scan?

    After payment and domain verification, the deep scan performs controlled read-only checks of database rules, public API responses, Google key restrictions, login rate limiting and password-reset protection.

  • Why is domain verification required?

    Payment is not proof of operator consent. Active checks run only after you prove control through DNS, a meta tag or a security code sent to a fixed role address on the domain.

  • Do I need a user account?

    No. MLVibeScan creates no customer account. A private report token provides access to the report and domain pass.

  • Does the scan change my app?

    No. Passive checks only read public responses, headers, DNS and TLS. Verified deep checks use a small fixed request budget and remain read-only.

  • Does a report with no findings mean my app is secure?

    No. It means the automated checks found nothing in their stated scope. Business-logic flaws, authenticated role issues and unknown attack methods may remain.

  • How often should I scan?

    Scan before every release and again after fixes. Build settings, dependencies and environment variables can introduce a new exposure even when the source change looks harmless.

  • What does the MLVibeScan badge prove?

    It proves a recent, technically verified deep scan with no open critical or high findings. It states the date, scope and validity and is explicitly not a guarantee of complete security.

  • Can the security badge be bought?

    No. Payment unlocks the report, deep scan and re-tests but does not guarantee a positive badge. The domain must be verified, the deep scan completed and every critical or high finding fixed.

  • When does a badge become invalid?

    It becomes invalid after a new critical or high finding, revocation, 30 days without a current deep scan, or at the end of the 90-day domain pass.

  • What does a public summary show?

    Only aggregates: grade, counts by severity and area, scope, date and progress since the previous scan. Finding titles, URLs, locations, evidence, fixes and tokens always stay private.

  • Why does a positive badge not mean “guaranteed secure”?

    An automated scan assesses only the stated technical scope at that time. Unknown business logic, new attack methods or areas outside that scope can still contain risk.

  • How is MLVibeScan different from a penetration test?

    MLVibeScan is automated, repeatable and specialised in common vibe-coding mistakes. A penetration test is individually scoped and investigates business logic and roles more deeply.