Hoe je gevoelige gegevens uit logs en JSON verwijdert voordat je deelt.

Op het moment dat je een logbestand, een API-response of een error-dump plakt in een Jira-ticket, een Slack-kanaal of een GitHub-issue, deel je mogelijk meer dan je denkt. E-mails, authenticatietokens, interne IP-adressen, telefoonnummers, gebruikers-ID’s — allemaal in platte tekst, begraven in geneste JSON of verstopt in stack traces. Het gebeurt elke dag, en de meeste mensen merken het pas achteraf.

Wat je waarschijnlijk lekt zonder het te weten

Gevoelige gegevens verbergen zich op plekken waar je ze niet verwacht:

• JWT-tokens in Authorization-headers — ze zien eruit als eyJhbGciOi... en zijn in seconden te decoderen, waardoor user claims en de vervaldatum zichtbaar worden
• API-keys in query strings en headers — sk_live_..., AKIA..., xoxb-... — eén zo’n key in een gedeelde log is een gelekte credential
• E-mailadressen in gebruikersobjecten, foutmeldingen en audit-logs
• Interne IP-adressen in netwerklogs — 10.x.x.x, 192.168.x.x, 172.16.x.x — ze onthullen de topologie van je interne netwerk
• UUID’s die verwijzen naar echte gebruikersrecords in je database
• Telefoonnummers in internationaal formaat — +44..., +1... — in contactobjecten of SMS-logs
• Lange hexadecimale strings die in werkelijkheid session ID’s, refresh tokens of bestandspaden met echte gebruikersnamen zijn

Het probleem is niet dat één van deze dingen moeilijk te ontdekken is. Het is dat een productie-error-dump er tientallen kan bevatten, genest over meerdere objecten, en dat je hem snel wilt delen omdat er iets kapot is.

Waarom handmatig redigeren faalt

Je opent de log, zoekt op @ en maskeert de vijf e-mailadressen die je vindt. De zesde, die drie niveaus dieper in een genest metadata.contact_info-object zit, ontgaat je. Je zoekt op strings die op tokens lijken en vangt de Authorization-header, maar mist de refresh token in de body van de response. Je maskeert het e-mailadres maar laat de user_id staan die er in je database direct naar verwijst.

Handmatig redigeren faalt omdat:

• Je haast hebt — productie ligt eruit en je hebt gewoon hulp nodig
• Echte logs diep geneste structuren hebben waarin hetzelfde type waarde op verschillende niveaus voorkomt
• Stack traces verwijzen naar bestandspaden met echte gebruikersnamen — /home/jsmith/app/src/handler.py
• Je de voor de hand liggende waarden vindt maar de minder voor de hand liggende mist, die nog steeds naar echte gegevens verwijzen

Hoe de Privacy Opschoner werkt

De Privacy Opschoner draait volledig in je browser. Er wordt niets naar een server gestuurd — je plakt je tekst, hij verwerkt die lokaal en geeft je een opgeschoonde versie om te kopiëren.

Dit doet hij:

1. Detecteert JSON automatisch wanneer de input als JSON te parseren is en verwerkt deze structureel — hij doorloopt de objectboom en vervangt gevoelige waarden terwijl keys en structuur intact blijven
2. Valt terug op tekstmodus voor CSV, XML, ruwe logs en elk ander formaat — hij zoekt patronen en vervangt treffers inline
3. Maskeert veelvoorkomende gevoelige patronen:
   • E-mailadressen
   • Telefoonnummers (internationaal en Amerikaans formaat)
   • IP-adressen (IPv4 en IPv6)
   • JWT-tokens (eyJ...)
   • API-keys en tokens (lange alfanumerieke strings die overeenkomen met gangbare formaten)
   • UUID’s
   • Lange hexadecimale strings die lijken op session ID’s of geheimen
4. Labelt wat hij vervangt — de uitvoer toont [REDACTED-EMAIL], [REDACTED-TOKEN], [REDACTED-IP] enzovoort, zodat je ziet wat er is opgepakt

JSON-modus vs tekstmodus — wat is het verschil

De JSON-modus behoudt structuur en geldigheid. Waarden worden vervangen, maar keys en nesting blijven intact. De uitvoer is nog steeds geldige JSON die je in een ticket kunt plakken, en een andere ontwikkelaar kan de vorm van de response begrijpen zonder de echte gegevens te zien.

De tekstmodus vervangt treffers inline, waar ze ook verschijnen. De structuur van je log of CSV blijft ongewijzigd, maar gevoelige waarden worden verwisseld voor redactielabels. Dit is beter voor:

• Logregels over meerdere regels met gemengde tekst en gestructureerde gegevens
• CSV-exports waarbij je de kolommen intact wilt houden
• XML met inline waarden
• Stack traces met bestandspaden en gebruikersnamen

De tool detecteert automatisch welke modus wordt gebruikt, maar je ziet het aan de uitvoer — als je gestructureerde JSON ziet met [REDACTED-*]-waarden, was het de JSON-modus. Als je inline vervangingen in vrije tekst ziet, was het de tekstmodus.

Wanneer de opgeschoonde uitvoer veilig is om te delen

De opschoner pakt de gangbare patronen — e-mails, tokens, IP’s, UUID’s, telefoonnummers en strings die op geheimen lijken. Maar hij kent jouw domein niet. Voordat je de uitvoer plakt, controleer je op:

• Interne projectcodenamen — de tool weet niet dat “Project Sundance” een vertrouwelijke interne naam is
• Klant-ID’s die geen UUID’s zijn — een veld customer_id: 847291 wordt niet opgepakt omdat het eruitziet als een gewoon geheel getal
• Bestandspaden met echte gebruikersnamen — /home/jsmith/ of /Users/sarah.chen/ in stack traces
• Foutmeldingen die echte mensen noemen — “Fout bij het verwerken van de betaling van John Smith” wordt niet gemarkeerd omdat de tool niet weet dat John Smith een klant is

De opschoner is een sterke eerste ronde. Leg er je eigen domeinkennis overheen voordat je deelt.

Scenarios uit de praktijk

Bugrapport in Jira: je plakt de volledige API-response, schoont hem op en deelt de structuur zonder de gegevens. De ontwikkelaar kan de vorm van de response, de foutcode en de nesting zien — zonder echte e-mails of tokens te zien.

Slack-bericht tijdens een incident: in plaats van een screenshot van een log te maken (moeilijk doorzoekbaar en onmogelijk te kopiëren), plak je de tekst, schoon je hem op en deel je de schone versie. Je collega’s krijgen doorzoekbare tekst en je lekt geen credentials in een chat die gearchiveerd wordt.

GitHub-issue voor een third-party library: je stuit op een bug in een API-client en wilt de request en response plakken. Schoon eerst op — de maintainer heeft je echte API-key niet nodig om het probleem te reproduceren, en zodra het in een publiek issue staat, wordt het geïndexeerd door zoekmachines.

Aan boord nemen van een leverancier of aannemer: je moet een voorbeeldexport van gegevens delen zodat die een integratie kan bouwen. Plakken, opschonen, en de structuur delen — kolomkoppen, veldnamen, neststructuur — zonder de echte klantrecords.

Opschonen voordat je deelt — elke keer

De Privacy Opschoner kost ongeveer vijf seconden. Plakken, klikken, kopiëren, delen. Het is sneller dan handmatig zoeken en vervangen, hij pakt de geneste velden die je zou missen en hij stuurt nooit iets naar een server.

Zet hem in je bladwijzers. De volgende keer dat de productie eruit ligt en je een log in een ticket moet plakken, ben je blij dat je het gedaan hebt.