Das sollte man niemals in ein zufälliges Online-Tool einfügen

Jeder, der an einem Computer arbeitet, landet irgendwann auf einer zufälligen Website und tut etwas, das die IT-Abteilung seines Unternehmens lieber nicht hätte. Das ist kein Urteil - es ist einfach wahr. Formatter für ein obskures Konfigurationsformat, JSON-Prettifier, Base64-Decoder, Regex-Tester, Diff-Checker. Diese Tools sind genuinen nützlich, und alles intern aufzubauen ist nicht realistisch.

Aber es gibt ein Gefälle zwischen “ein Beispiel-JSON-Blob einfügen” und “den Produktions-Datenbankverbindungsstring einfügen”, und das Gefälle ist wichtig. Das hier geht darum zu verstehen, wo die Grenze liegt.

Das tatsächliche Bedrohungsmodell

Vor der Liste lohnt es sich, präzise darüber zu sein, was tatsächlich passiert, wenn man Daten in ein Web-Tool einfügt - weil es leicht ist, sich entweder zu viel oder zu wenig vorzustellen.

Der Server empfängt, was man tippt

Sofern ein Tool nicht explizit und nachprüflicherweise client-seitig ist (dazu später mehr), werden Daten, die man in ein Formularfeld eingibt oder an ein Tool hochlädt, an einen Server übertragen. Sie gehen durch:

• Den Webserver und Anwendungscode des Tool-Betreibers
• Welche Logging-Infrastruktur auch immer sie haben (oft mehr als beabsichtigt - App-Server protokollieren Request-Bodies im Debug-Modus, und der Debug-Modus leckt manchmal in die Produktion)
• Ein CDN vor dem Tool (Cloudflare, Fastly usw.) - CDNs protokollieren typischerweise keine Request-Bodies, sehen sie aber
• Welche Drittanbieter-Analytics-, Fehlerüberwachungs- oder Observability-Tools auch immer in die Seite eingebettet sind (Sentry, Datadog, Mixpanel usw.)

Das sind vier verschiedene Orte, an denen ein Geheimnis landen könnte, ohne dass irgendjemand etwas offensichtlich Falsches getan hat.

Browser-Erweiterungen sehen alles

Jede Browser-Erweiterung, die Content-Scripts ausführt - was die meisten Erweiterungen einschließt, die irgendeine sinnvolle Fähigkeit haben - kann den Inhalt von Eingabefeldern und Textareas auf jeder Seite lesen, es sei denn, die Erweiterung schließt sie spezifisch aus. Eine bösartige oder kompromittierte Erweiterung kann still alles exfiltrieren, was man tippt, auf jeder Website.

Das ist nicht theoretisch. Mehrere hochkarätige Erweiterungs-Supply-Chain-Angriffe in den letzten Jahren (einschließlich Erweiterungen mit Millionen von Nutzern) beinhalteten genau das. Die Erweiterung war legitim, wurde erworben oder kompromittiert, und der neue Eigentümer hat ein Update gepusht, das Datenexfiltration hinzufügte.

Wenn man 40 Browser-Erweiterungen installiert hat und nicht benennen kann, was jede tut, ist das einen Blick wert.

Suchindizierung und Caches

Einige Tools (insbesondere ältere oder DSGVO-naive) schließen Benutzereingaben in URLs oder Seitentitel ein. Dinge in URLs können in Browserverlauf, Serverlogs, Referrer-Headern bei ausgehenden Links, Google Search Console und Web-Archiv-Crawls enden. Das ist bei Eingabedaten weniger häufig, aber nicht unmöglich - insbesondere bei Tools, die GET-Parameter verwenden, um Ergebnisse zu teilen.

Die “Ich vertraue diesem Dienst”-Annahme

Selbst wenn man dem Tool-Betreiber heute vertraut, hat dieses Vertrauen eine Lebensdauer. Unternehmen werden erworben. Startups schließen und verkaufen ihre Nutzerdaten als Vermögenswert. Entwicklungsteams machen Fehler. Eine Logging-Konfigurationsänderung kann damit beginnen, aufzunehmen, was zuvor nicht aufgezeichnet wurde. Ein Junior-Entwickler fügt Request-Body-Logging hinzu, um ein Produktionsproblem zu debuggen, und vergisst es zu entfernen.

Vertrauen ist keine permanente Eigenschaft. Ein Tool, das die eigenen Daten nicht hat, kann sie nicht verlieren.

Was man nicht in ein zufälliges Online-Tool einfügen sollte

Keine erschöpfende Liste, aber das sind die Kategorien, die konsistent wichtig sind:

Credentials und Geheimnisse

• Produktions-Datenbankverbindungsstrings (enthalten Host, Port, Benutzername, Passwort, Datenbankname - oft alles in einem String)
• API-Schlüssel und -Token für irgendeinen Dienst (AWS, Stripe, Twilio, GitHub, OpenAI usw.)
• Inhalte von .env-Dateien - das sind im Wesentlichen ein Manifest jedes Geheimnisses, das die Anwendung verwendet
• JWTs aus Produktionssystemen - der Payload enthält Benutzeridentitäts-Claims; ein geleaktes JWT ist ein gültiges Sitzungstoken, bis es abläuft
• Privaten SSH-Schlüssel
• TLS-Privatschlüssel oder Zertifikat-Bundles
• OAuth-Client-Geheimnisse
• Webhook-Geheimnisse, die für die Signaturverifikation verwendet werden

Persönliche Daten anderer

• Kundennamen, E-Mails, Telefonnummern - selbst ein kleiner Export
• Alle Daten, die unter Art. 9 DSGVO fallen (Gesundheit, Religion, politische Ansichten, biometrische Daten)
• Mitarbeiterdaten
• Schuldaten (wenn man in einer Bildungseinrichtung ist)

Unternehmensvertrauliche Inhalte

• Quellcode proprietärer Systeme (nicht nur aus NDA-Gründen - Quellcode enthält oft hartcodierte Anmeldedaten, interne Hostnamen und Architekturdetails)
• Interne Architekturdiagramme oder Design-Dokumente
• Finanzprojektionen, M&A-Ziellisten, Vorstandsmaterialien
• Rechtliche Einreichungen bevor sie öffentlich sind

Alles unter einem regulatorischen Rahmen

• HIPAA: alle Informationen, die einen Patienten in einem Gesundheitskontext identifizieren könnten
• PCI DSS: Karteninhaberdaten, PANs, selbst in Test/Staging-Umgebungen, wenn die Daten real sind
• SOC-2-kontrollierte Daten gemäß der eigenen Unternehmensklassifizierungsrichtlinie

Der gemeinsame Faden: wenn etwas in einem Benachrichtigungsschreiben über einen Breach an Kunden erscheinen würde, sollte es nicht in ein ungeprüftes Web-Tool gehen.

Was generell sicher ist

Einige Dinge können im Wesentlichen überall eingefügt werden:

• Synthetische oder offensichtlich gefälschte Daten - {"user": "john_doe", "id": 12345} als Beispiel
• Öffentliche Daten - etwas, das man sowieso in ein GitHub-README setzen würde
• Eigene persönliche Inhalte ohne Drittanbieter-PII - Notizen, Entwürfe, eigener Code für ein Nebenprojekt
• Nicht sensible Code-Snippets - ein CSS-Selektor, den man testen möchte, ein Regex-Muster ohne echte Daten darin, ein SQL-Schema ohne tatsächliche Tabellendaten
• Fehlermeldungen und Stack Traces - normalerweise in Ordnung, obwohl man alle Werte im Trace bereinigen sollte, die wie Geheimnisse oder Benutzeridentifikatoren aussehen

Selbst für “sichere” Daten ist es eine vernünftige Gewohnheit, einen Moment darüber nachzudenken, was drin ist.

Wie man verifiziert, ob ein Tool tatsächlich client-seitig ist

Mehrere Tools behaupten, client-seitig zu sein. So prüft man das:

1. DevTools öffnen (F12 in den meisten Browsern) und zum Network-Tab gehen.
2. Zu Fetch/XHR oder Alle Anfragen filtern.
3. Die Daten einfügen oder hochladen und das Tool auslösen.
4. Nach ausgehenden Anfragen Ausschau halten. Ein genuinen client-seitiges Tool zeigt keine Anfragen, die die eigenen Eingabedaten übertragen - man sieht möglicherweise eine Anfrage für ein WASM-Binär oder eine Schriftart, aber nichts, das enthält, was man eingefügt hat.

Das dauert etwa 30 Sekunden und ist zuverlässiger als das Lesen einer Datenschutzerklärung.

Sichere Alternativen für sensible Operationen

Ein lokales Tool verwenden. Wenn man JSON formatieren muss, erledigt jq in einem Terminal das ohne jegliche Netzwerkbeteiligung. Wenn man Base64 dekodieren muss, base64 -d auf macOS/Linux. Die meisten “Ich brauche ein schnelles Tool dafür”-Probleme haben eine einzeilige CLI-Lösung.

Ein geprüftes Browser-only-Tool verwenden. Tools, die demonstrierbar client-seitig sind (und bei denen man das mit der Network-Tab-Methode oben verifizieren kann), sind sinnvoll sicherer. Für Dinge wie einen String hashen, ein starkes Passwort generieren oder Daten vor dem Teilen verschlüsseln, unser Hash Generator , Passwort-Generator oder AES Encrypt/Decrypt verwenden - alle verarbeiten Daten lokal.

Ein lokales LLM verwenden. Wenn man einen KI-Assistenten verwenden möchte, um Code zu erklären oder ein Dokument zu prüfen, verarbeitet ein lokal laufendes Modell (Ollama + Llama 3 beispielsweise) nichts extern. Das ist 2026 zunehmend praktikabel.

Ein internes Tool verwenden. Viele Unternehmen haben interne Entwicklerportale oder Tooling. Langsamer und weniger poliert als zufällige Web-Tools, aber von jemandem geprüft, der vermutlich die Interessen des eigenen Unternehmens im Sinn hatte.

Ein einmaliges Skript schreiben. Wenn man regelmäßig eine bestimmte Transformation an sensiblen Daten durchführen muss, ein kleines Python- oder Node-Skript dafür schreiben. Es dauert 10 Minuten, läuft lokal und man kontrolliert es.

Ein Entscheidungsbaum

Wenn man kurz davor ist, etwas in ein Web-Tool einzufügen:

Enthält die Datei Geheimnisse, Anmeldedaten oder PII?
+-- Nein --> Enthält sie vertrauliche Geschäftsinformationen?
|            +-- Nein --> Wahrscheinlich in Ordnung. Fortfahren.
|            +-- Ja --> Ist das Tool nachweislich client-seitig?
|                       +-- Ja --> Mit Network-Tab verifizieren, dann fortfahren.
|                       +-- Nein --> Eine lokale Alternative verwenden.
+-- Ja --> Ist das Tool nachweislich client-seitig UND vertraut man seinem Betreiber?
           +-- Beides Ja --> Mit Network-Tab verifizieren, dann vorsichtig fortfahren.
           +-- Eines Nein --> Nicht einfügen. Ein lokales Tool oder Skript verwenden.

Der Punkt ist nicht, dass Web-Tools schlecht sind. Es ist, dass die Entscheidung bewusst sein sollte. “Ich musste etwas schnell dekodieren und habe nicht darüber nachgedacht” ist der Beginn der meisten Vorfälle - nicht Bösartigkeit, nicht genau Nachlässigkeit, nur Gewohnheit, die dem Denken voraus läuft.

Diese Gewohnheit ist es gelegentlich wert, sie zu unterbrechen.