Hash-Blocklist im Voice-Linter gegen Datenleaks

Würdigung — Aufmerksamkeit ist keine Sicherheitsschicht#

Die ehrlichste Erkenntnis aus dem Betrieb einer inhaltsstarken Website ist unbequem: „Ich passe schon auf" skaliert nicht. Ein einzelner Mensch, der dreißig oder vierzig Fachartikel schreibt, übersieht früher oder später eine Kleinigkeit — einen Eigennamen in einem Beispiel, eine Domain in einem Screenshot-Text, einen zu konkreten Bezug auf einen beobachteten Fall. Das ist kein Disziplin-Problem, sondern ein Mengen-Problem. Und es verschärft sich, sobald nicht mehr eine Person allein schreibt, sondern ein Team oder ein KI-Assistent mitarbeitet, der frühere Formulierungen wieder aufgreift.

Genau deshalb behandeln wir Anonymität nicht als Vorsatz, sondern als Mechanik — auf derselben Ebene wie ESLintESLint · zum GlossarStatischer Code-Analyzer für JavaScript/TypeScript — fängt Style-Brüche und Anti-Patterns. oder TypeScriptTypeScript · zum GlossarJavaScript mit statischer Typprüfung — fängt Tippfehler und Datenform-Bruch beim Build statt im Produktivbetrieb.. Diese Werkzeuge verlassen sich nicht darauf, dass ein Entwickler keinen Tippfehler macht; sie fangen ihn strukturell ab. Ein Schutz gegen versehentliche Daten-Lecks gehört in dieselbe Kategorie: ein Wächter, der bei jedem Commit prüft, statt eines Vorsatzes, der beim dreißigsten Artikel müde wird. Für eine Kanzlei, deren ganzes Geschäft auf Verschwiegenheit beruht, ist genau dieser Unterschied — Mechanik statt Hoffnung — der eigentliche Punkt.

Das Problem: eine Wortliste verrät, was sie schützen soll#

Die naheliegende Lösung wäre eine einfache Datei mit verbotenen Begriffen: eine Liste von Namen und Domains, gegen die jeder Text geprüft wird. Das Problem ist offensichtlich, sobald man es ausspricht: Diese Datei liegt im Code-Repository. Eine Klartext-Liste mit genau den Namen, die niemals öffentlich werden dürfen, ist selbst das Leck, das sie verhindern soll — sie sammelt die schützenswerten Begriffe an einer Stelle und macht sie für jeden lesbar, der Zugriff auf das Repo bekommt.

Die Anforderung ist also paradox: Der LinterLinter · zum GlossarAutomatischer Prüfer für Code, Inhalt oder Konfiguration — fängt Drift, bevor sie produktiv wird. muss erkennen, ob ein verbotener Begriff im Text vorkommt, ohne diesen Begriff selbst zu kennen — jedenfalls nicht in lesbarer Form. Die Lösung dafür ist eine kryptografische Standard-Technik, dieselbe, mit der seriöse Systeme Passwörter prüfen, ohne sie zu speichern.

Die Lösung: gesalzene Hashes statt Klartext#

Statt der Begriffe selbst speichert der Linter nur deren Hash-Werte. Ein Hash ist eine Einbahnstraße: Aus dem Begriff lässt sich der Hash berechnen, aber aus dem Hash nicht der Begriff zurückgewinnen. Bei uns kommt SHA-256 zum Einsatz, ergänzt um einen festen Zusatz (einen sogenannten Salt), der vor jedem Begriff steht, bevor gehasht wird. Der Salt sorgt dafür, dass die Hashes nicht über generische, im Netz auffindbare Hash-Tabellen rückwärts geknackt werden können.

In der Praxis heißt das: Die im Repository liegende Datei enthält ausschließlich eine Liste unverständlicher Zeichenketten — die gesalzenen SHA-256-Hashes der verbotenen Begriffe. Selbst wer diese Datei öffnet, lernt nichts über die geschützten Namen. Trotzdem kann der Linter zuverlässig prüfen, ob ein Text einen davon enthält: Er zerlegt den geprüften Text in einzelne Wörter, hasht jedes Wort auf exakt dieselbe Weise (mit demselben Salt) und vergleicht das Ergebnis mit der Hash-Liste. Stimmt ein Hash überein, ist ein verbotener Begriff gefunden — ohne dass er je im Klartext gespeichert war. Im Fehler-Bericht erscheint der Treffer entsprechend nur als Platzhalter, nicht als lesbarer Begriff.

Was der Linter mit dem Text macht#

Damit der Vergleich funktioniert, muss der eingegebene Text zuerst in vergleichbare Einheiten zerlegt werden. Der Linter geht dabei bewusst schlicht vor:

• Wörter herauslösen: Aus dem Text werden Token mit mindestens vier Zeichen extrahiert (kürzere Fragmente erzeugen zu viele Fehlalarme).
• Vereinheitlichen: Jeder Token wird in Kleinbuchstaben überführt, damit Groß- und Kleinschreibung keine Rolle spielt.
• Hashen und vergleichen: Auf jeden so vorbereiteten Token wird derselbe gesalzene SHA-256-Hash angewendet und gegen die Liste geprüft.

Diese Schlichtheit ist Absicht. Der Linter ist kein semantisches Wundermittel, das jede denkbare Schreibvariante errät — er fängt genau die eingetragenen Begriffe zuverlässig ab. Wo zusätzliche Varianten relevant sind, werden sie als eigene Einträge ergänzt. Neben der gehashten Liste gibt es zudem eine rein lokale, bewusst nicht ins Repository eingecheckte Klartext-Datei für sensible Begriffe, die nur auf den Arbeitsrechnern liegt — getrennt von der allgemeinen Slop- und Phrasen-Prüfung, die der Voice-Linter ohnehin macht.

Im Pre-Commit-Hook: das Versehen wird zum Build-Fehler#

Eine Prüfung, die man manuell starten muss, wird irgendwann vergessen — genau der Fehler-Modus, den wir vermeiden wollen. Deshalb läuft der Linter automatisch bei jedem Commit, der eine Inhalts- oder Code-Datei berührt (Markdown, TSX, HTML und ähnliche). Findet er einen Treffer, bricht der Commit mit einem Fehler ab; die Änderung kommt gar nicht erst ins Repository, geschweige denn auf die Live-Site. Es gibt einen dokumentierten Notfall-Schalter, um den Hook zu umgehen — der ist aber bewusst die Ausnahme, nicht der Normalfall, und für Anonymitäts-Treffer schlicht nicht vorgesehen.

Der Effekt: Das Versehen wird vom „hoffentlich fällt es jemandem auf" zum harten, unübersehbaren Stopp im Moment des Entstehens. Mechanik schlägt Aufmerksamkeit.

Was Kanzleien davon haben#

Auf den ersten Blick ist das ein internes Werkzeug-Thema. Der Mehrwert für eine Kanzlei liegt eine Ebene tiefer:

• Ein Dienstleister, der so denkt, passt zum Berufsstand: Wer Verschwiegenheit nicht dem Zufall überlässt, sondern technisch erzwingt, baut Websites für Mandanten, die unter dem Mandantengeheimnis (§ 203 StGB) stehen, mit der nötigen Grundhaltung — die berufsrechtlichen Grenzen dazu zeigt der Insight § 203 StGB und KI.
• Das Prinzip ist übertragbar: Dieselbe Mechanik-vor-Aufmerksamkeit-Logik schützt auch Mandantendaten in Kontaktformularen und in der laufenden Wartung — etwa im wöchentlichen Security-Sweep.
• Es ist Teil eines Systems, nicht ein Einzeltrick: Der Hash-Linter ist eine Schicht neben anderen Pre-Commit-Wächtern, die im Linter-und-Hooks-Insight zusammen beschrieben sind.

Für eine strukturierte Bewertung, wo Ihre aktuelle Website auf Aufmerksamkeit statt auf Mechanik setzt, empfehlen wir den Hebel-Audit (890 €, bei Mandanten-Boost-Beauftragung innerhalb von 60 Tagen voll anrechenbar).

Zusammenfassung#

Anonymität auf einer inhaltsstarken Website lässt sich nicht durch Vorsatz sichern, sobald mehrere Hände — menschliche oder maschinelle — an den Texten arbeiten. Eine naive Wortliste verbietet sich, weil sie die schützenswerten Begriffe selbst preisgibt. Die saubere Lösung speichert nur gesalzene SHA-256-Hashes: Der Linter zerlegt jeden Text in Wörter, hasht sie identisch und vergleicht, ohne den Klartext je abzulegen. Über den Pre-Commit-Hook wird ein Treffer zum harten Build-Fehler, bevor er das Repository erreicht. Das macht aus einem fragilen „aufpassen" eine verlässliche Mechanik — und zeigt zugleich die Grundhaltung, die ein Website-Dienstleister mitbringen sollte, der für verschwiegenheitsgebundene Kanzleien baut.

Quellen#

• StGB § 203 — Verletzung von Privatgeheimnissen
• DSGVO Art. 5 — Grundsätze für die Verarbeitung (Integrität und Vertraulichkeit) — abgerufen 2026-06-08
• DSGVO Art. 32 — Sicherheit der Verarbeitung — abgerufen 2026-06-08
• NIST FIPS 180-4 — Secure Hash Standard (SHA-256) — abgerufen 2026-06-08

Disclaimer: Beschreibung einer tatsächlich eingesetzten Bau-Schicht von fahoch2.de zum Zeitpunkt der Veröffentlichung. Allgemeine fachliche Information, keine Rechtsberatung. Ein Hash-Linter ersetzt keine sorgfältige redaktionelle Arbeit, sondern fängt deren Lücken ab; die Bewertung im Einzelfall hängt vom konkreten Inhalt und Verarbeitungszweck ab.