Wonach Semafio prüft
Der Katalog lehnt sich an bekannte Standards an: OWASP ASVS und Top 10, OWASP Top 10 für LLM-Anwendungen, BSI C5 und ISO 27001 für organisatorische Punkte, dazu DSGVO, KI-Verordnung, DDG und BFSG. Jedes Kriterium hat einen festen Code, eine Prüfmethode und eine Angabe, wie weit es automatisierbar ist. In Phase 1 prüft Semafio 15 Kriterien automatisch, die übrigen sind dokumentiert und folgen.
Sicherheit
Schlüssel im ausgelieferten Code, Header und TLS, Anmeldung, Datenbankregeln bei Supabase. Tiefe Prüfungen nur nach Domain-Nachweis und deiner Erlaubnis.
SEC-01Keine Geheimschlüssel im ausgelieferten Codein Phase 1
Alles, was im Browser ankommt, kann jeder lesen. Steht dort ein geheimer Schlüssel, kann ein Fremder damit in deinem Namen Daten lesen, Geld ausgeben oder Mails verschicken.
Prüfmethode: Scan der JS-Bundles und Source Maps auf API-Schlüssel, Service-Role-Keys, Passwörter (automatisch)
- Startseite und alle eingebundenen Skripte derselben Herkunft laden und nach bekannten Schlüsselformaten durchsuchen (Stripe, Supabase Service Role, OpenAI, Anthropic, AWS, GitHub, private Schlüssel und weitere).
- Supabase-Schlüssel dekodieren und unterscheiden: Der öffentliche Anon-Key ist erlaubt, der Service-Role-Key nie.
- Prüfen, ob Source Maps öffentlich abrufbar sind.
- Nur Code, der ohne Anmeldung ausgeliefert wird. Bereiche hinter einem Login sieht der passive Scan nicht.
- Gefundene Schlüssel werden maskiert gespeichert (Anfang und Prüfsumme), nie vollständig.
Grundlage: OWASP ASVS V14.3, OWASP Top 10 A02, A05
SEC-02Backend-Zugriffe abgesichert (Supabase RLS, Firebase Rules)in Phase 1
Bei Supabase entscheidet Row Level Security, wer welche Zeilen lesen darf. Fehlt sie, kann jeder mit dem öffentlichen Schlüssel aus deiner App die ganze Tabelle abrufen, zum Beispiel alle Kundendaten.
Prüfmethode: Mit dem öffentlichen Anon-Key Tabellen und Buckets abfragen; mit Lesezugriff Richtlinien direkt auswerten (automatisch)
- Nur nach Domain-Nachweis und deiner protokollierten Erlaubnis.
- Mit dem öffentlichen Anon-Key aus deiner App die freigegebenen Tabellen auflisten und je Tabelle prüfen, ob ohne Anmeldung Zeilen zurückkommen. Gespeichert wird nur der Tabellenname und ob Zeilen lesbar waren, nie Inhalte.
- Öffentlich lesbare Storage-Buckets erkennen.
- Schreibzugriffe werden nicht getestet.
- Firebase-Regeln und die Auswertung per Lese-Token folgen.
Grundlage: OWASP ASVS V4.1, OWASP Top 10 A01 · nur nach Domain-Nachweis und Erlaubnis
SEC-03Authentifizierung serverseitig, sichere Sitzungenin Phase 1
Wenn die App im Browser entscheidet, wer Admin ist, kann jeder diese Entscheidung umgehen. Sitzungs-Cookies ohne Schutzflags lassen sich leichter stehlen.
Prüfmethode: Prüfung, ob Login-Logik im Client liegt; Cookie-Flags, Token-Laufzeit, Passwortrichtlinie, MFA-Angebot (automatisch)
- Cookies der Startseite auf Secure, HttpOnly und SameSite prüfen.
- Ausgelieferten Code auf Rollen- oder Passwortprüfungen im Browser durchsuchen (zum Beispiel isAdmin im localStorage).
- Erkennen, ob ein zweiter Faktor angeboten wird, soweit das im ausgelieferten Code sichtbar ist.
- Ohne Testkonto prüft Semafio den Login-Ablauf nicht selbst. Token-Laufzeit und Passwortrichtlinie folgen mit Testkonten in Phase 2.
Grundlage: OWASP ASVS V2, V3 · nur nach Domain-Nachweis und Erlaubnis
SEC-04Zugriffstrennung zwischen Kunden (keine IDOR)folgt
Ein Kunde darf nie die Daten eines anderen Kunden sehen, auch nicht durch Ändern einer Nummer in der Adresse.
Prüfmethode: Zwei Testkonten, automatische Versuche, fremde Objekte zu lesen oder zu ändern (teilautomatisch)
Grundlage: OWASP ASVS V4.2, OWASP Top 10 A01 · nur nach Domain-Nachweis und Erlaubnis
SEC-05Transport und Headerin Phase 1
Verschlüsselung und Sicherheits-Header schützen deine Nutzer vor mitgelesenen Verbindungen, eingeschleustem Code und unsichtbar überlagerten Seiten.
Prüfmethode: TLS-Konfiguration, HSTS, CSP, CORS, Clickjacking-Schutz (automatisch)
- HTTPS erreichbar, Weiterleitung von HTTP auf HTTPS, Zertifikat gültig und nicht kurz vor Ablauf, TLS-Version.
- Header Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Schutz vor Einbettung (frame-ancestors oder X-Frame-Options).
- CORS: keine Freigabe für beliebige Herkunft zusammen mit Anmeldedaten.
- Geprüft wird die Startseite. Abweichende Header auf Unterseiten oder API-Pfaden sieht der Scan nur, wenn sie verlinkt sind.
Grundlage: OWASP ASVS V9, V14.4, BSI TR-02102-2
SEC-06Keine bekannten verwundbaren Abhängigkeitenin Phase 1
Fast jede App besteht zum größten Teil aus fremden Bibliotheken. Ist für eine davon eine Lücke bekannt, suchen Angreifer gezielt nach Apps, die sie noch einsetzen.
Prüfmethode: SCA gegen CVE-Datenbanken, aus Bundle-Fingerprints oder Lockfile; SBOM erzeugen (automatisch)
- Bibliotheken und Versionen aus dem ausgelieferten Code erkennen (zum Beispiel React, Vue, jQuery, Lodash, Axios, Next.js).
- Erkannte Versionen gegen die öffentliche Schwachstellendatenbank OSV abgleichen.
- Daraus eine Stückliste (SBOM) im Bericht erzeugen.
- Ohne Lockfile erkennt Semafio nur Bibliotheken, die ihre Version im Bundle hinterlassen. Der Abgleich mit dem Repository folgt.
Grundlage: OWASP Top 10 A06, OWASP ASVS V14.2 · nur nach Domain-Nachweis und Erlaubnis
SEC-07Typische Injektionen und XSSfolgt
Eingaben, die ungeprüft in Datenbankabfragen oder auf der Seite landen, erlauben Fremden, Daten auszulesen oder Code bei deinen Nutzern auszuführen.
Prüfmethode: DAST mit authentifizierter Sitzung; SAST (z. B. Semgrep) bei Repository-Zugang (automatisch)
Grundlage: OWASP Top 10 A03, OWASP ASVS V5 · nur nach Domain-Nachweis und Erlaubnis
SEC-08Keine offenen internen Werkzeugein Phase 1
Vergessene Konfigurationsdateien, Git-Ordner oder Debug-Seiten verraten oft Zugangsdaten oder den ganzen Quellcode.
Prüfmethode: Suche nach ungeschützten Admin-Pfaden, Dashboards, Debug-Endpunkten (automatisch)
- Nur nach Domain-Nachweis und deiner protokollierten Erlaubnis.
- Eine feste, veröffentlichte Liste bekannter Pfade abrufen (zum Beispiel /.env, /.git/HEAD, /phpinfo.php, /server-status, offene API-Dokumentation) und prüfen, ob dort echte Inhalte statt einer Fehlerseite kommen.
- Nur die veröffentlichte Pfadliste, keine Wörterbuchsuche. Anmeldeversuche finden nicht statt.
Grundlage: OWASP Top 10 A05, OWASP ASVS V14.3 · nur nach Domain-Nachweis und Erlaubnis
SEC-09Fehler in der Geschäftslogik (Preise, Rechte, Abläufe)folgt
Manche Fehler findet nur ein Mensch, der versteht, was die App tun soll, zum Beispiel einen Rabatt, der sich mehrfach einlösen lässt.
Prüfmethode: Manueller Pentest durch Partner, nur in der höchsten Stufe (manuell)
Grundlage: OWASP Top 10 A04 · nur nach Domain-Nachweis und Erlaubnis
Datenschutz
Tracking vor Einwilligung, Drittdienste im Abgleich mit der Datenschutzerklärung, Hosting-Orte.
DSG-01Kein Tracking vor Einwilligung (TDDDG § 25)in Phase 1
Analyse- und Werbedienste dürfen erst laden, wenn deine Besucher zugestimmt haben. Das gilt auch für Google Fonts vom Google-Server, weil dabei die IP-Adresse übertragen wird.
Prüfmethode: Headless-Browser lädt die Seite ohne Einwilligung und protokolliert Cookies und Requests an Drittanbieter (automatisch)
- Startseite ohne Einwilligung laden: Skripte und Verbindungen zu bekannten Tracking- und Werbediensten im ausgelieferten HTML erkennen.
- Cookies, die der Server vor jeder Einwilligung setzt, nach bekannten Tracking-Namen auswerten.
- Schriften von fonts.googleapis.com und fonts.gstatic.com erkennen.
- Mit dem Browser-Worker zusätzlich: alle tatsächlich ausgelösten Anfragen und gesetzten Cookies im Browser protokollieren.
- Ohne Browser-Worker wertet Semafio nur das ausgelieferte HTML und die Server-Cookies aus. Der Bericht sagt, welche Methode gelaufen ist.
Grundlage: TDDDG § 25, DSGVO Art. 6, Art. 7
DSG-02Datenschutzerklärung vorhanden und passendin Phase 1
Deine Nutzer müssen erfahren, an wen ihre Daten gehen. Eine Datenschutzerklärung aus einer Vorlage nennt oft nicht die Dienste, die deine App wirklich nutzt.
Prüfmethode: KI-Abgleich: Werden alle tatsächlich gefundenen Drittdienste (Supabase, OpenAI, Stripe, Analytics) genannt? (teilautomatisch)
- Datenschutzerklärung über Links der Startseite oder übliche Pfade finden.
- Alle im Scan erkannten Drittdienste (zum Beispiel Supabase, Stripe, OpenAI, Google Analytics) gegen den Text abgleichen und fehlende Nennungen melden.
- Semafio prüft, ob die Dienste genannt sind, nicht ob die Rechtsgrundlage stimmt. Das bleibt eine Einzelfallbewertung.
Grundlage: DSGVO Art. 13, Art. 14
DSG-03Hosting und Drittlandübermittlung transparentin Phase 1
Einkäufer wollen wissen, wo Daten liegen. Läuft ein Teil der App bei US-Anbietern, muss das in der Datenschutzerklärung stehen.
Prüfmethode: IP- und DNS-Auswertung der Hosting-Standorte; Abgleich mit Subprozessorliste; DPF-Status der US-Dienste (automatisch)
- Hosting-Anbieter der App aus DNS und Antwort-Headern erkennen, Region wo erkennbar (zum Beispiel Vercel-Region).
- Erkannte Drittdienste dem Sitz des Anbieters zuordnen und US-Anbieter kennzeichnen.
- Der genaue Rechenzentrumsstandort ist von außen nicht immer bestimmbar. Der Bericht sagt dann „nicht sicher bestimmbar“.
- Der Abgleich mit deiner Subprozessorliste folgt.
Grundlage: DSGVO Art. 13 Abs. 1 lit. f, Art. 44 ff.
DSG-04AVV für Geschäftskunden verfügbarfolgt
Geschäftskunden brauchen einen Vertrag zur Auftragsverarbeitung, bevor sie personenbezogene Daten in deine App geben.
Prüfmethode: Dokument hochladen; KI prüft Pflichtinhalte nach Art. 28 Abs. 3 (teilautomatisch)
Grundlage: DSGVO Art. 28
DSG-05Betroffenenrechte technisch umgesetztfolgt
Nutzer haben das Recht, ihre Daten zu bekommen und löschen zu lassen. Das sollte ohne Handarbeit funktionieren.
Prüfmethode: Testkonto anlegen, Datenexport und Löschung auslösen, Ergebnis prüfen (teilautomatisch)
Grundlage: DSGVO Art. 15, 17, 20 · nur nach Domain-Nachweis und Erlaubnis
DSG-06Technische und organisatorische Maßnahmenfolgt
Wer Daten verarbeitet, muss sie angemessen schützen und das belegen können.
Prüfmethode: Strukturierter Fragebogen mit Nachweisen (Backups, Zugriffskonzept), Plausibilität per KI (teilautomatisch)
Grundlage: DSGVO Art. 32, BSI C5
KI-Verordnung
Aufrufe an Modellanbieter erkennen, Hinweis, dass Nutzer mit einer KI sprechen.
KI-01KI-Funktionen erkannt und offengelegtin Phase 1
Einkäufer und Datenschutzbeauftragte fragen, welche KI-Modelle Daten verarbeiten. Die Antwort sollte zu dem passen, was die App tatsächlich tut.
Prüfmethode: Erkennung von Aufrufen an Modellanbieter; Abgleich mit Angaben des Anbieters (automatisch)
- Ausgelieferten Code auf Adressen und Bibliotheken von Modellanbietern durchsuchen (OpenAI, Anthropic, Google Gemini, Mistral, OpenRouter, Groq und weitere).
- Gefundene Anbieter im Bericht auflisten und mit der Datenschutzerklärung abgleichen (siehe DSG-02).
- Aufrufe, die nur dein Server macht, sind von außen unsichtbar. Der Abgleich mit deinen eigenen Angaben folgt.
Grundlage: KI-Verordnung Art. 50, DSGVO Art. 13
KI-02Transparenz nach Art. 50 (gilt seit 02.08.2026)in Phase 1
Wer mit einem Chatbot spricht, muss erkennen können, dass eine KI antwortet. Diese Pflicht gilt seit dem 02.08.2026.
Prüfmethode: Hinweis bei Chatbots, Kennzeichnung erzeugter Inhalte; Prüfung im Headless-Browser (teilautomatisch)
- Chat-Widgets und KI-Assistenten im ausgelieferten Code erkennen.
- Prüfen, ob in der Nähe ein Hinweis auf KI steht (zum Beispiel „KI“, „künstliche Intelligenz“, „AI“).
- Mit dem Browser-Worker zusätzlich: das Widget öffnen und den sichtbaren Hinweis prüfen.
- Grundprüfung. Ob erzeugte Bilder oder Texte gekennzeichnet sind, prüft Semafio in Phase 1 nicht.
Grundlage: KI-Verordnung Art. 50 Abs. 1 · nur nach Domain-Nachweis und Erlaubnis
KI-03Keine verbotenen Praktiken (Art. 5), Einordnung Hochrisiko (Anhang III)folgt
Einige KI-Anwendungen sind verboten, andere gelten als hochriskant und haben eigene Pflichten.
Prüfmethode: Geführte Selbsteinstufung mit KI-Plausibilitätsprüfung; Hochrisiko-Pflichten gelten nach dem Omnibus erst ab 02.12.2027 (teilautomatisch)
Grundlage: KI-Verordnung Art. 5, Art. 6, Anhang III
KI-04Robustheit gegen Prompt Injection und Datenabflussfolgt
Ein geschickt formulierter Text kann eine KI dazu bringen, Anweisungen zu ignorieren oder vertrauliche Daten preiszugeben.
Prüfmethode: Automatisierte Angriffe nach OWASP LLM Top 10 gegen die KI-Funktionen im Testkonto (automatisch)
Grundlage: OWASP Top 10 for LLM Applications LLM01, LLM02 · nur nach Domain-Nachweis und Erlaubnis
KI-05Kundendaten werden nicht zum Training genutztfolgt
Geschäftskunden wollen sicher sein, dass ihre Daten nicht in das Training fremder Modelle fließen.
Prüfmethode: Nachweis der Vertragsbedingungen des Modellanbieters, Konfiguration (teilautomatisch)
Grundlage: DSGVO Art. 28, KI-Verordnung
Betrieb
Bauplattform und Abhängigkeiten, security.txt als Meldeweg für Sicherheitslücken.
OPS-01Verfügbarkeitfolgt
Wer sich auf eine App verlässt, will wissen, wie oft sie wirklich erreichbar ist.
Prüfmethode: Eigenes Monitoring der Plattform ab Einreichung; Wert erscheint auf der Prüfseite (automatisch)
Grundlage: BSI C5 BCM
OPS-02Datensicherung und Wiederherstellungfolgt
Ohne Sicherung ist ein Bedienfehler oder ein Angriff das Ende aller Daten.
Prüfmethode: Nachweis (Backup-Konfiguration im Backend per Lesezugriff oder Screenshot mit Datum) (teilautomatisch)
Grundlage: BSI C5 OPS-06, DSGVO Art. 32 Abs. 1 lit. c
OPS-03Datenexport und Ausstiegfolgt
Kunden wollen ihre Daten mitnehmen können, wenn sie den Anbieter wechseln.
Prüfmethode: Export im Testkonto auslösen, Format prüfen (teilautomatisch)
Grundlage: Data Act Art. 23 ff., DSGVO Art. 20 · nur nach Domain-Nachweis und Erlaubnis
OPS-04Abhängigkeit von der Bauplattformin Phase 1
Liegt deine App nur bei einer Bauplattform, hängt dein Geschäft an deren Preisen und Verfügbarkeit. Einkäufer fragen danach.
Prüfmethode: Erkennen, ob Hosting und Code bei Lovable, Bolt o. Ä. liegen; Angabe, ob der Anbieter den Code besitzt (automatisch)
- Bauplattform und Hosting aus Domain, Headern und Spuren im Code erkennen (Lovable, Bolt, Replit, v0, Base44, Vercel, Netlify und weitere).
- Ob du den Code exportiert hast und besitzt, sieht Semafio von außen nicht. Das fragt der Bericht als Hinweis ab.
Grundlage: BSI C5 SSO
OPS-05Meldeweg für Sicherheitslückenin Phase 1
Wer eine Lücke in deiner App findet, braucht einen Weg, sie dir zu melden, bevor sie ausgenutzt wird.
Prüfmethode: security.txt, Kontaktadresse, Antwort auf Testmeldung (automatisch)
- /.well-known/security.txt abrufen und nach RFC 9116 prüfen: Contact und Expires vorhanden, Datum nicht abgelaufen, über HTTPS ausgeliefert.
- Die Antwort auf eine Testmeldung prüft Semafio in Phase 1 nicht.
Grundlage: RFC 9116, NIS-2 Art. 12
Recht
Impressum mit Pflichtangaben, Lizenzen der eingesetzten Bibliotheken.
REC-01Identität des Anbietersfolgt
Einkäufer wollen wissen, mit wem sie einen Vertrag schließen.
Prüfmethode: Abgleich mit Handelsregister und USt-ID, Identitätsprüfung der einreichenden Person (automatisch)
Grundlage: DDG § 5, HGB
REC-02Impressum (§ 5 DDG), AGB, Preisein Phase 1
Ein fehlendes oder unvollständiges Impressum ist in Deutschland abmahnfähig und für Einkäufer ein Warnsignal.
Prüfmethode: Auffinden und Pflichtangaben per KI prüfen (teilautomatisch)
- Impressum über Links der Startseite oder übliche Pfade finden.
- Pflichtangaben prüfen: Name oder Firma, Anschrift, E-Mail, weiterer schneller Kontaktweg, bei Gesellschaften Rechtsform, Vertretung und Registereintrag.
- AGB und Preisangaben auf Vorhandensein prüfen.
- Ob die Angaben stimmen, prüft Semafio in Phase 1 nicht (Abgleich mit dem Register folgt mit REC-01).
Grundlage: DDG § 5, PAngV
REC-03Barrierefreiheit (BFSG), soweit anwendbarfolgt
Seit dem 28.06.2025 müssen viele digitale Dienste für Verbraucher barrierefrei sein.
Prüfmethode: Automatische WCAG-Prüfung (z. B. axe) und Erklärung zur Barrierefreiheit (teilautomatisch)
Grundlage: BFSG, EN 301 549, WCAG 2.1 AA
REC-04Lizenzen der Abhängigkeitenin Phase 1
Manche Open-Source-Lizenzen verlangen, dass du deinen eigenen Code offenlegst, wenn du sie einbindest.
Prüfmethode: Aus der SBOM, Warnung bei Copyleft in proprietären Produkten (automatisch)
- Lizenzhinweise im ausgelieferten Code auswerten und Copyleft-Lizenzen (GPL, AGPL, LGPL) melden.
- Lizenzen der in SEC-06 erkannten Bibliotheken in der Stückliste angeben.
- Ohne Lockfile nur Bibliotheken, die im Bundle erkennbar sind.
Grundlage: SPDX, OpenChain ISO/IEC 5230 · nur nach Domain-Nachweis und Erlaubnis
Änderungsprotokoll
16.10.2026 · v1 Erste Veröffentlichung mit 29 Kriterien. 15 davon prüft Semafio automatisch, die übrigen folgen.