Security Audit
RLS-Leaks vor dem Launch finden
AI-Coding-Tools shippen Apps gerne mit deaktivierter Row Level Security, hardcoded API-Keys im JS-Bundle und fehlenden Security-Headern. Pantra scannt nach den exakten Patterns die bisher jedes öffentliche Lovable- und Cursor-Data-Leak verursacht haben — und zeigt dir wie du sie in deinem Stack fixst.
Die Data-Leak-Epidemie bei Vibe-Coded Apps
2024–2025 wurden Dutzende Lovable-, Bolt- und Cursor-Apps dabei erwischt wie sie ganze User-Tabellen über den öffentlichen Supabase REST Endpoint leakten — weil die App mit AI gebaut wurde und der Entwickler nie darauf kam Row Level Security zu aktivieren. Andere shippten ihren SUPABASE_SERVICE_ROLE_KEY ins Frontend-JS. Das ist keine theoretische Gefahr. Das ist der mit Abstand häufigste Weg wie eine AI-gebaute App öffentlich geht und innerhalb von 48h auf einem Telegram-Channel landet.
Jeder Check den Pantra durchführt
| Check | Schweregrad | Was wir prüfen | Warum es zählt |
|---|---|---|---|
| Supabase RLS-Probe | Kritisch | Erkennt den Supabase Anon-Key, enumeriert Tabellen über REST und prüft ob unauthentifizierte SELECTs durchgehen | Wenn RLS aus ist, kann jeder jede Zeile deiner Datenbank lesen. |
| Service-Role-Key Exposure | Kritisch | Regex-Scan des JS-Bundles nach SUPABASE_SERVICE_ROLE_KEY und anderen Admin-Tokens | Ein geleakter Service-Role-Key umgeht RLS vollständig — voller DB-Zugriff. |
| Stripe / OpenAI / Anthropic Keys im Client | Kritisch | Pattern-basierte Erkennung von sk_live_, sk-proj-, sk-ant- im JS-Bundle | Jeder mit View-Source kann deine OpenAI-Credits leeren oder Stripe-Charges auslösen. |
| Content-Security-Policy Header | Hoch | Prüft auf einen CSP-Header und markiert unsafe-inline/unsafe-eval Direktiven | Die stärkste Einzel-Verteidigung gegen XSS und Supply-Chain-Attacken. |
| Strict-Transport-Security (HSTS) | Hoch | HSTS-Header mit sinnvoller max-age vorhanden | Verhindert Protokoll-Downgrade-Attacken auf Login-Seiten. |
| X-Frame-Options / frame-ancestors | Hoch | Verhindert dass die Seite von bösartigen Sites geframt wird (Clickjacking) | Ohne das kann ein Angreifer deine App framen und Klicks kapern. |
| HTTPS-Erzwingung | Hoch | HTTP-Requests redirecten auf HTTPS; Zertifikat ist valide; kein Mixed-Content | Jeder HTTP-Schritt ist ein Session-Hijack-Vektor in öffentlichen WLANs. |
| X-Content-Type-Options: nosniff | Mittel | Verhindert Browser-MIME-Sniffing | Blockiert eine Klasse von Attacken bei denen Uploads als JS interpretiert werden. |
| Referrer-Policy Header | Mittel | Mindestens strict-origin-when-cross-origin gesetzt | Verhindert dass interne URLs via Referer an Dritte geleakt werden. |
| Permissions-Policy Header | Mittel | Beschränkt Zugriff auf sensible Browser-APIs (Kamera, Geolocation, Mikrofon) | Begrenzt den Blast-Radius wenn ein Third-Party-Script kompromittiert wird. |
| Öffentlich sichtbare Supabase REST Exposure | Mittel | Prüft dass die Supabase-Projekt-URL nicht in Client-XHR-Patterns geleakt wird wenn sie nicht öffentlich sein sollte | Einige Apps versuchen ihre Supabase-URL via Proxy privat zu halten; wir markieren versehentliche Leaks. |
| Server-Banner-Offenlegung | Niedrig | Server- und x-powered-by Header leaken keine spezifischen Versionen | Versionsspezifische Banner helfen Angreifern dir gezielt CVEs zuzuordnen. |
| Dependency CVE-Übersicht | Info | Öffentliches Bundle wird auf bekannte Vulnerability-Versionen geprüft (Opt-in Heuristik) | Alte React-, Axios-, Lodash-Versionen haben öffentliche CVEs die weiterhin ausgenutzt werden. |
Wie der Security-Scan abläuft
1. Nur externer Probe — nie authentifiziert
Pantra greift ausschliesslich auf das zu was ein Angreifer aus dem offenen Internet erreichen kann. Wir verlangen keine Credentials, loggen uns nie in deinen Account ein, treffen keine authentifizierten Routen. Alles was wir finden würde ein Angreifer auch in 90 Sekunden finden.
2. JS-Bundle holen und parsen
Wir ziehen jeden Script-Tag, holen das Bundle und fahren Regex-Patterns die auf Anon-Key, Service-Role-Key und typische LLM/Payment-API-Key-Formen abgestimmt sind. Minified Code wird genug deobfuscated um konkatenierte Keys zu fangen.
3. Supabase REST-Probe (read-only)
Finden wir ein Supabase-Projekt, senden wir ein unauthentifiziertes GET an /rest/v1/ mit dem Anon-Key. Antworten Tabellen mit Daten — RLS ist aus. Wir schreiben oder ändern niemals Daten.
4. Header-Auswertung
HEAD- und GET-Responses werden gegen OWASP Secure Headers Project Baselines geprüft. Fehlende oder schwache Header werden als Findings mit Severity gerankt.
5. Stack-aware Fix-Prompt
Fixes unterscheiden sich je Stack. RLS in Lovable aktivieren heisst SQL-Migration im Supabase-Editor; in Next.js heisst es Middleware + Server-Component-Pattern. Der Prompt reflektiert das.
Beispiel Fix-Prompt für Supabase + Lovable
Fix diese kritischen Security-Issues in meiner Lovable App sofort:
1. AKTIVIERE ROW LEVEL SECURITY auf jeder öffentlich erreichbaren Supabase-Tabelle.
Im Supabase SQL-Editor pro Tabelle ausführen:
alter table public.{table} enable row level security;
Dann Policies hinzufügen:
create policy "owner darf lesen" on public.{table}
for select using (auth.uid() = user_id);
create policy "owner darf schreiben" on public.{table}
for insert with check (auth.uid() = user_id);
2. ENTFERNE den SERVICE_ROLE Key aus dem Frontend.
- Lösche jede Verwendung von import.meta.env.VITE_SUPABASE_SERVICE_ROLE_KEY.
- Verlagere Admin-Operationen in eine Edge Function, die den Key aus den
Supabase-Project-Secrets liest.
3. ENTFERNE alle sk_live_ / sk-proj- / sk-ant- Keys aus dem Client-Code.
Diese Keys gehören ausschliesslich server-seitig. Proxy den Call über eine
Edge Function oder eine Next.js API Route.
4. FÜGE Security-Header über Supabase Edge Function oder Hosting-Config hinzu:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
5. ERZWINGE HTTPS über den "Always use HTTPS" Toggle bei deinem Hosting
(Vercel, Netlify, Cloudflare Pages bieten das alle an).Stacks die wir für Fix-Prompts automatisch erkennen
Pantra vs. manueller Pen-Test vs. Gratis-Scanner
Gratis-Scanner wie securityheaders.com prüfen Header — mehr nicht. Manuelle Pen-Tests kosten €3k–€15k. Pantra schliesst die 80/20-Lücke: fängt die Issues die in der Praxis tatsächlich Apps geleakt haben.
| Aspekt | Manuell | Andere Tools | Pantra |
|---|---|---|---|
| RLS-Erkennung | Erfordert DB-Experte | Nicht geprüft | Probe-basiert, jeder Scan |
| Exposed API-Key Erkennung | Code-Review | Einfaches Pattern-Match | Stripe / OpenAI / Anthropic / Supabase Patterns |
| Header-Audit | Manuelles curl | Ja | Ja, mit Remediation-Prompt |
| Stack-spezifische Remediation | Abhängig vom Consultant | Nein | Lovable / Cursor / Bolt / v0 / Next.js |
| Preis | €3k–€15k pro Audit | Gratis (aber seicht) | Ab $19/Monat, täglich auto |
Passt gut zu
In welchem Plan verfügbar
In jedem Plan enthalten. RLS-Probes und Key-Exposure-Scans sind immer aktiv.
Häufige Fragen
Greift Pantra direkt auf meine Datenbank zu?add
Nein. Wir probieren nur öffentlich erreichbare Endpoints mit dem Anon-Key, der ohnehin an jeden Besucher ausgeliefert wird. Read-only. Genau wie ein Angreifer.
Was wenn mein Anon-Key korrekt mit RLS konfiguriert ist — gibt es einen False Positive?add
Nein. Wenn RLS aktiv ist und Policies anonyme Reads blockieren, liefert der Probe ein leeres Array oder einen Permission-Denied-Fehler. Das ist ein Pass. Grüner Check, kein Finding.
Ersetzt Pantra einen echten Security-Audit?add
Nein. Pantra fängt die 15-20 Issues die 90% der Vibe-Coded Leaks verursachen. Es ersetzt keinen SOC-2-Audit, keinen professionellen Pen-Test und keine kryptographische Prüfung für ein Finanzprodukt.
Kann ich die Supabase RLS-Probe deaktivieren?add
Ja, über eine Agency-Plan-Einstellung. Die meisten lassen es an — die Probe ist zerstörungsfrei und entspricht dem, was jeder Angreifer an Tag eins ohnehin tun würde.
Was wenn ich Firebase oder Neon statt Supabase nutze?add
Wir scannen trotzdem Header, HTTPS und geleakte API-Keys. RLS-Probes sind aktuell Supabase-only; Firebase-Firestore-Rule-Probes stehen auf der Roadmap.
Speichert ihr meine Scan-Ergebnisse?add
Ja, in deinem Account, damit das Dashboard Trends zeigen kann. Du kannst die komplette History jederzeit löschen. Public-Scans (kein Account) werden 30 Tage aufbewahrt, dann gelöscht.
Bricht ein Fix-Prompt meine App?add
RLS zu aktivieren WIRD Queries brechen die auf unauthentifizierte Reads setzen. Genau das ist gewollt. Der Fix-Prompt weist die AI an, passende Policies hinzuzufügen damit die App für eingeloggte Nutzer weiterhin funktioniert.
Wie oft sollte ich einen Security-Scan laufen lassen?add
Täglich. AI-Tools regenerieren Code bei jeder Änderung; eine mittags sichere App kann abends leaken, weil ein Feature eine neue Tabelle ohne RLS angelegt hat. Deshalb läuft in jedem Pantra-Plan alle 24 Stunden ein Full-Scan.
Kann ich die Ergebnisse mit meinem CTO oder Kunden teilen?add
Ja. Jeder Scan hat eine öffentlich teilbare URL unter pantra.io/scan/[domain]. Pro und Agency erlauben dir, das Pantra-Badge von diesen Seiten zu entfernen.
Was ist mit OWASP Top 10?add
Pantra deckt die OWASP-Issues ab die sich als extern sichtbare Fehlkonfigurationen zeigen — Broken Access Control (RLS), kryptographische Schwächen (HTTP-Leg), Fehlkonfiguration (Header), verwundbare Komponenten (Dependency-Banner). Issues die authentifizierten Zugriff brauchen, wie SSRF oder Business-Logic-Fehler, brauchen einen klassischen Pen-Test.