← Alle Artikel
Aktualisiert am May 29, 20267 min read

Warum du sensibles JSON nicht in Online-Tools einfügen solltest

JWT-Tokens, API-Keys, PII und Datenbank-Exports werden routinemäßig in Online-Formatierer geklebt. Was mit diesen Daten serverseitig passiert — und warum browsernative Tools die sicherere Wahl sind.

Ein Entwickler stößt auf einen Parse-Fehler, kopiert das JSON aus der API-Antwort und fügt es in den ersten Online-Formatter ein, der bei Google auftaucht. Das JSON enthält User-IDs, E-Mail-Adressen, Session-Tokens oder eine interne Config-Datei. Das passiert Dutzende Male am Tag in jedem Engineering-Team. Dieser Artikel erklärt genau, welche Risiken das schafft —— und warum ein browsernatives Tool sie ausschließt.

Welche Art von Daten landet in Online-JSON-Tools

In der Praxis fügen Entwickler ein, was gerade das unmittelbare Problem verursacht. Das heißt:

  • JWT-Tokens —— enthalten User-Identity-Claims, Rollen und Ablauf. Die Signatur verhindert Manipulation, aber der Payload ist Base64url-codierter Klartext: Jeder, der dein Token loggt, kann jedes Feld lesen.
  • API-Antworten mit PII —— Namen, E-Mail-Adressen, Telefonnummern, Geburtsdaten, Adressen. Eine einzige Suchergebnisseite aus einer kundenseitigen API kann hunderte Datensätze enthalten.
  • Konfigurationsdateien —— Datenbankverbindungs-Strings, Drittanbieter-API-Keys, Feature-Flag-Einstellungen, interne Service-URLs.
  • Datenbank-Exports —— JSON-Dumps ganzer Tabellen, manchmal zum Debuggen erzeugt und einfach so eingefügt.
  • Interne Geschäftsdaten —— Preisregeln, Vertragsbedingungen, unveröffentlichte Produktdaten, die keine öffentliche Klassifizierung haben, aber trotzdem sensibel sind.

Nichts davon fühlt sich im Moment sensibel an. Der Entwickler will die Struktur verstehen, nicht Daten teilen. Aber der Akt des Einfügens in ein Online-Tool ist nicht von einer Übermittlung an Dritte zu unterscheiden.

Was passiert, wenn du Daten an ein Online-Tool sendest

Die meisten Online-Formatter, -Validatoren und -Diff-Tools schicken deine Eingabe an einen Server-Endpoint, verarbeiten sie dort und liefern das Ergebnis zurück. Selbst Tools, die behaupten „client-side" zu sein, senden manchmal Daten für Logging, Analytics oder Error-Tracking. Hier ist, was Daten auf diesem Weg passieren kann.

Serverseitiges Logging

Webserver loggen in vielen Frameworks standardmäßig Request-Bodies. Ein einziger POST deines JSON-Payloads kann landen in:

  • Application-Logs auf Disk oder in einem Logging-Service (Datadog, Splunk, CloudWatch)
  • Error-Tracking-Tools (Sentry, Bugsnag) —— besonders wenn das Parsen fehlschlägt
  • Einer Datenbankzeile in einer „Analytics"- oder „Usage"-Tabelle
  • CDN- oder Load-Balancer-Zugriffslogs, die der Tool-Betreiber möglicherweise gar nicht überwacht

Log-Retention-Policies variieren stark. Manche Tools behalten Logs 90 Tage, andere unbegrenzt. So oder so: Der Betreiber —— und jeder, der Zugang zu seinen Systemen bekommt —— kann lesen, was du gesendet hast.

Drittanbieter-Analytics

Viele Online-Tools binden Drittanbieter-JavaScript für Analytics oder Werbung ein. Diese Skripte können Netzwerk-Requests, Form-Submissions und Input-Events beobachten. Wenn ein Tool deine Daten an seinen eigenen Server schickt, kann die Analytics-Schicht die HTTP-Transaktion ebenfalls sehen.

Caching und CDN-Storage

Manche Tools cachen Ergebnisse nach Input-Inhalt. Wenn zwei User identisches JSON einreichen, bekommt der zweite eine gecachte Antwort. Das Input kann Stunden oder Tage im Cache bleiben. In pathologischen Fällen haben falsch konfigurierte Caches User-Submissions öffentlich zugänglich über eine vorhersagbare URL gemacht.

Suchmaschinen-Indexierung

Formatter, die einen teilbaren Permalink erzeugen (eine URL, die dein formatiertes JSON enthält oder referenziert), wurden historisch von Suchmaschinen gecrawlt. Einen markanten String aus einer internen Config-Datei zu suchen und ihn auf der Domain eines JSON-Formatters zu finden, ist eine unangenehme Erfahrung.

Regulatorisches Risiko

Wenn deine Organisation personenbezogene Daten nach DSGVO, HIPAA, CCPA oder ähnlichen Rahmenwerken verarbeitet, kann das Einfügen von Userdaten in ein Drittanbieter-Online-Tool eine unautorisierte Datenübermittlung darstellen —— selbst wenn es versehentlich war und das Tool seriös ist. Das Regelwerk unterscheidet nicht zwischen absichtlichem Teilen und nachlässiger Tool-Wahl. Die Frage, die es stellt, lautet: haben personenbezogene Daten die autorisierte Verarbeitungsgrenze verlassen?

Für HIPAA-Covered-Entities speziell: Geschützte Gesundheitsinformationen an einen Drittanbieter-Service zu senden, der kein Business Associate Agreement (BAA) unterzeichnet hat, ist ein meldepflichtiger Vorfall, unabhängig davon, ob die Daten missbraucht wurden.

Wie browsernative Tools anders funktionieren

Moderne Browser können komplexe Logik —— Parsen, Validieren, Diffen, Formatieren, Encoden —— vollständig innerhalb der JavaScript-Engine ausführen, ohne Netzwerkaufruf. Ein Tool, das auf diesem Modell aufbaut, verhält sich wie eine lokale Anwendung, die zufällig über das Web ausgeliefert wird.

Wenn du JSON in ein browsernatives Tool einfügst:

  • Der Text geht in eine JavaScript-Variable im Speicher deines Browsers.
  • Ein Parser (auch JavaScript) verarbeitet ihn im selben Tab.
  • Die Ausgabe wird ins DOM gerendert.
  • Es geht kein HTTP-Request an irgendeinen Server mit deinen Daten als Payload.

Die Daten verlassen deine Maschine nie. Sie können nicht geloggt, gecacht oder indexiert werden, weil sie nie übertragen wurden.

Wie du prüfst, ob ein Tool wirklich lokal ist

Aussagen wie „wir speichern deine Daten nie" sind häufig und von außen nicht überprüfbar. Die einzige verlässliche Prüfung ist das Network-Panel deines Browsers:

  1. Öffne DevTools (F12 oder Cmd+Option+I).
  2. Geh in den Tab Network und aktiviere Preserve log.
  3. Füge dein JSON ins Tool ein und löse die Operation aus (Formatieren, Validieren etc.).
  4. Filter Requests nach XHR/Fetch. Wenn ein ausgehender Request dein Input als Payload trägt, ist das Tool nicht client-side.

Ein echtes lokales Tool zeigt keinen ausgehenden POST oder Fetch mit deinen Daten. Du siehst evtl. Requests für statische Assets (CSS, JS) oder Analytics-Pings, aber keiner davon enthält deinen JSON-Payload.

// Was ein lokales Tool tut —— kein Netzwerkaufruf:
const result = JSON.parse(userInput);   // läuft im Browser
render(result);                         // aktualisiert das DOM

// Was ein serverseitiges Tool tut:
const res = await fetch('/api/format', {
  method: 'POST',
  body: JSON.stringify({ input: userInput }),  // deine Daten verlassen die Maschine
});

Praktische Patterns: BAAs, WebCrypto und Redaction-Helper

Drei Patterns schließen den meisten Restrisikoraum:

  • Business Associate Agreements (BAAs) für HIPAA-nahes Arbeiten —— wenn dein Team geschützte Gesundheitsinformationen verarbeitet, braucht jeder Drittanbieter-Service, der sie berührt, ein unterzeichnetes BAA in der Akte. Deshalb ist das Einfügen von PHI in einen zufälligen Formatter, selbst einen der „lokal läuft", ebenso ein Dokumentationsproblem wie ein technisches.
  • Client-seitige WebCrypto —— wenn du im Browser wirklich hashen, signieren, ver-/entschlüsseln oder Schlüssel generieren musst, macht die Standard-API crypto.subtle das ohne Server-Roundtrip. Es ist das richtige Primitiv für „entschlüssele dieses Payload, damit ich es ansehen kann", ohne den Ciphertext irgendwohin zu schicken.
  • Redaction-Helper —— fürs Debugging schick das JSON erst durch einen kleinen Redactor, der Werte bei bekannten sensiblen Keys (password, token, email, ssn) maskiert, bevor du es irgendwo einfügst. Eine 20-Zeilen-Funktion schlägt das Entdecken von Tokens im Request-Log eines Analytics-Tools.

Team-Policies, die sich lohnen

Individuelles Bewusstsein bringt nur so weit. Eine leichtgewichtige Policy füllt die Lücke:

  • Klassifiziere, bevor du einfügst. Wenn das JSON Namen, E-Mails, IDs, Tokens oder Schlüssel enthält —— ist es sensibel. Nutze ein lokales Tool oder ein genehmigtes internes.
  • Pflege eine genehmigte Tool-Liste. Eine kurze Liste verifizierter Local-first-Tools ist einfacher zu befolgen als eine pauschale „Sei vorsichtig"-Regel.
  • Teile niemals Produktions-Credentials in Debugging-Sessions. Rotiere jedes Token oder jeden Schlüssel, der in ein Online-Tool eingefügt wurde, auch wenn das Tool sicher aussieht.
  • Nutze gereinigte Samples zum Debuggen. Ersetze echte Userwerte vor dem Einfügen durch synthetische Daten. Eine Struktur mit "email": "test@example.com" ist zum Debuggen eines Parse-Fehlers genauso nützlich wie die echte Adresse.

Häufig gestellte Fragen

Ist es sicher, sensibles JSON in Online-Tools einzufügen?

Nur wenn das Tool alles in deinem Browser verarbeitet. Serverseitige Formatter können dein Input loggen, cachen oder indexieren —— und das Einfügen von PII bei einem Dritten kann an sich DSGVO oder HIPAA verletzen, unabhängig von der Absicht.

Wie prüfe ich, ob ein JSON-Tool lokal läuft?

Öffne DevTools → Network, aktiviere „Preserve log" und führe die Operation aus. Wenn kein ausgehender Request dein Input als Payload trägt, ist das Tool client-side. Statische-Asset- und Analytics-Requests sind in Ordnung; ein POST deines JSON nicht.

Was soll ich tun, wenn ich bereits ein Token in ein Online-Tool eingefügt habe?

Rotier es. Behandle jedes Credential oder jeden Schlüssel, der ein Drittanbieter-Tool berührt hat, als kompromittiert, auch wenn das Tool seriös aussieht. Denk dran: ein Base64-codiertes Token ist immer noch Klartext.

Wie kann mein Team das ganz vermeiden?

Nutzt browsernative Tools, pflegt eine genehmigte Tool-Liste, und debuggt mit gereinigten Sample-Daten ("email": "test@example.com") statt echter Datensätze.

Was fixjson.org tut

Jedes Tool auf fixjson.org —— JSON-Reparatur, JSON-Diff, YAML-Formatter, JSON Stringify, Base64-Encode/Decode und URL-Decode —— läuft vollständig in deinem Browser. Parser, Diff-Engine und Formatter sind alle lokal ausgeführtes JavaScript. Du kannst das im Network-Tab überprüfen: Kein POST-Request trägt dein Input.

Die Seite lädt statische Assets (HTML, CSS, JS) einmal von einem CDN. Danach funktioniert sie offline. Kein Input wird an irgendeinen Server gesendet. Keine Daten werden geloggt, gespeichert oder geteilt.