← Tutti gli articoli
Aggiornato il May 29, 20267 min read

Perché non dovresti incollare JSON sensibile in strumenti online

Token JWT, chiavi API, PII ed export di database vengono incollati di routine nei formattatori online. Ecco cosa succede a quei dati lato server — e perché gli strumenti nativi del browser sono la scelta più sicura.

Uno sviluppatore inciampa in un errore di parsing, copia il JSON dalla risposta API e lo incolla nel primo formatter online che esce su Google. Il JSON contiene ID utente, indirizzi email, token di sessione o un file di configurazione interno. Succede decine di volte al giorno in ogni team di ingegneria. Questo articolo spiega esattamente che rischi questo crea —— e perché uno strumento browser-native li elimina.

Che tipo di dati finisce negli strumenti JSON online

In pratica, gli sviluppatori incollano qualsiasi cosa stia causando il problema immediato. Cioè:

  • Token JWT —— contengono claim di identità utente, ruoli e scadenza. La firma impedisce la manomissione, ma il payload è testo in chiaro codificato Base64url: chiunque logghi il tuo token può leggere ogni campo.
  • Risposte API con PII —— nomi, indirizzi email, numeri di telefono, date di nascita, indirizzi. Una sola pagina di risultati di ricerca da un'API rivolta al cliente può contenere centinaia di record.
  • File di configurazione —— connection string del database, API key di terze parti, impostazioni di feature flag, URL di servizi interni.
  • Export di database —— dump JSON di intere tabelle, a volte generati per il debug e incollati così come sono.
  • Dati di business interni —— regole di prezzo, termini contrattuali, dati di prodotti non rilasciati che non hanno classificazione pubblica ma sono comunque sensibili.

Nulla di tutto questo sembra sensibile sul momento. Lo sviluppatore vuole capire la struttura, non condividere dati. Ma l'atto di incollarlo in uno strumento online è indistinguibile dall'invio a una terza parte.

Cosa succede quando invii dati a uno strumento online

La maggior parte dei formatter, validator e diff tool online funzionano inviando il tuo input a un endpoint server, processandolo lì e restituendo il risultato. Anche strumenti che dichiarano di essere «client-side» a volte mandano dati per logging, analytics o error tracking. Ecco cosa può succedere ai dati lungo quel percorso.

Logging lato server

I web server in molti framework loggano di default i request body. Un singolo POST del tuo payload JSON può finire in:

  • Log applicativi salvati su disco o in un servizio di logging (Datadog, Splunk, CloudWatch)
  • Strumenti di error tracking (Sentry, Bugsnag) —— soprattutto se il parsing fallisce
  • Una riga di database in una tabella «analytics» o «usage»
  • Log di accesso CDN o load balancer che l'operatore dello strumento potrebbe nemmeno monitorare

Le policy di retention dei log variano molto. Alcuni strumenti tengono i log per 90 giorni; altri li tengono indefinitamente. In entrambi i casi, l'operatore —— e chiunque acceda ai suoi sistemi —— può leggere quello che hai inviato.

Analytics di terze parti

Molti strumenti online includono JavaScript di terze parti per analytics o pubblicità. Questi script possono osservare richieste di rete, submission di form ed eventi di input. Se uno strumento manda i tuoi dati al suo server, anche il layer di analytics può vedere la transazione HTTP.

Caching e storage CDN

Alcuni strumenti cachano i risultati indicizzati sul contenuto di input. Se due utenti inviano lo stesso JSON, il secondo ottiene una risposta cachata. L'input può restare nella cache per ore o giorni. In casi patologici, cache mal configurate hanno reso le submission utente pubblicamente accessibili tramite un URL prevedibile.

Indicizzazione da motori di ricerca

I formatter che generano un permalink condivisibile (un URL che contiene o referenzia il tuo JSON formattato) hanno storicamente visto il loro output essere crawlato dai motori di ricerca. Cercare una stringa distintiva da un file di config interno e trovarla sul dominio di un formatter JSON è un'esperienza spiacevole.

Esposizione normativa

Se la tua organizzazione processa dati personali sotto GDPR, HIPAA, CCPA o framework simili, incollare i dati di un utente in uno strumento online di terze parti può costituire un trasferimento di dati non autorizzato —— anche se è stato accidentale e lo strumento è reputato. Il framework non distingue tra condivisione intenzionale e scelte di tooling sbadate. La domanda che fa è: i dati personali hanno lasciato il confine di processing autorizzato?

Per le entità coperte da HIPAA in particolare, mandare informazioni sanitarie protette a un servizio di terze parti che non ha firmato un Business Associate Agreement (BAA) è una violazione da segnalare a prescindere se i dati siano stati usati impropriamente.

Come gli strumenti browser-native lavorano diversamente

I browser moderni sono in grado di eseguire logica complessa —— parsing, validazione, diff, formattazione, encoding —— interamente all'interno del motore JavaScript, senza alcuna richiesta di rete necessaria. Uno strumento costruito su questo modello si comporta come un'applicazione locale che capita di essere consegnata via web.

Quando incolli JSON in uno strumento browser-native:

  • Il testo va in una variabile JavaScript nella memoria del tuo browser.
  • Un parser (anche lui JavaScript) lo processa nella stessa tab.
  • L'output viene renderizzato nel DOM.
  • Non viene fatta nessuna richiesta HTTP a nessun server con i tuoi dati come payload.

I dati non lasciano mai la tua macchina. Non possono essere loggati, cachati o indicizzati perché non sono mai stati trasmessi.

Come verificare che uno strumento sia davvero locale

Affermazioni come «non memorizziamo mai i tuoi dati» sono comuni e non verificabili dall'esterno. L'unico check affidabile è il pannello Network del tuo browser:

  1. Apri DevTools (F12 o Cmd+Option+I).
  2. Vai nella tab Network e spunta Preserve log.
  3. Incolla il tuo JSON nello strumento e fai partire l'operazione (format, valida, ecc.).
  4. Filtra le richieste per XHR/Fetch. Se qualche richiesta in uscita porta il tuo input come payload, lo strumento non è client-side.

Uno strumento genuinamente locale non mostrerà nessun POST o fetch in uscita che porti i tuoi dati. Puoi vedere richieste per asset statici (file CSS, JS) o ping di analytics, ma nessuno di quelli conterrà il tuo payload JSON.

// Cosa fa uno strumento locale —— nessuna chiamata di rete:
const result = JSON.parse(userInput);   // gira nel browser
render(result);                         // aggiorna il DOM

// Cosa fa uno strumento lato server:
const res = await fetch('/api/format', {
  method: 'POST',
  body: JSON.stringify({ input: userInput }),  // i tuoi dati lasciano la macchina
});

Pattern pratici: BAA, WebCrypto e helper di redazione

Tre pattern chiudono la maggior parte del rischio residuo:

  • Business Associate Agreement (BAA) per lavoro vicino a HIPAA —— se il tuo team gestisce informazioni sanitarie protette, qualsiasi servizio di terze parti che le tocca ha bisogno di un BAA firmato agli atti. È per questo che incollare PHI in un formatter qualsiasi, anche uno che «gira in locale», è tanto un problema di documentazione quanto tecnico.
  • WebCrypto lato client —— quando hai davvero bisogno di hashare, firmare, cifrare o generare chiavi nel browser, l'API standard crypto.subtle lo fa senza round-trip al server. È la primitive giusta per «decifra questo payload per dargli un'occhiata» senza mandare il ciphertext da nessuna parte.
  • Helper di redazione —— per il debug, passa prima il JSON in un piccolo redattore che maschera i valori in key note come sensibili (password, token, email, ssn) prima di incollarlo da qualsiasi parte. Una funzione di venti righe batte lo scoprire token nel request log di uno strumento di analytics.

Policy di team che vale la pena avere

La consapevolezza individuale arriva solo fino a un certo punto. Una policy leggera copre il gap:

  • Classifica prima di incollare. Se il JSON contiene nomi, email, ID, token o chiavi —— è sensibile. Usa uno strumento locale o uno interno approvato.
  • Mantieni una lista di strumenti approvati. Una lista corta di strumenti verificati come local-first è più facile da seguire di una regola generica «stai attento».
  • Non condividere mai credenziali di produzione nelle sessioni di debug. Ruota qualsiasi token o chiave che è stato incollato in uno strumento online, anche se lo strumento sembra sicuro.
  • Usa sample ripuliti per il debug. Sostituisci i valori utente reali con dati sintetici prima di incollare. Una struttura con "email": "test@example.com" è utile quanto l'indirizzo vero per il debug di un errore di parse.

Domande frequenti

È sicuro incollare JSON sensibile in strumenti online?

Solo se lo strumento processa tutto nel tuo browser. I formatter lato server possono loggare, cachare o indicizzare il tuo input —— e incollare PII presso una terza parte può di per sé violare GDPR o HIPAA, indipendentemente dall'intento.

Come faccio a verificare se uno strumento JSON gira in locale?

Apri DevTools → Network, spunta «Preserve log», ed esegui l'operazione. Se nessuna richiesta in uscita porta il tuo input come payload, lo strumento è client-side. Richieste di asset statici e analytics vanno bene; un POST del tuo JSON no.

Cosa devo fare se ho già incollato un token in uno strumento online?

Ruotalo. Tratta qualsiasi credenziale o chiave che ha toccato uno strumento di terze parti come compromessa, anche se lo strumento sembra reputato. Ricorda che un token codificato in Base64 è ancora testo in chiaro.

Come può il mio team evitarlo del tutto?

Usate strumenti browser-native, tenete una lista di strumenti approvati, e fate debug con dati di sample ripuliti ("email": "test@example.com") invece di record reali.

Cosa fa fixjson.org

Ogni strumento su fixjson.org —— riparazione JSON, JSON diff, formatter YAML, JSON Stringify, encoding/decoding Base64 e decoding URL —— gira interamente nel tuo browser. Il parser, il motore di diff e i formatter sono tutti JavaScript che esegue in locale. Puoi verificarlo nella tab Network: nessuna richiesta POST porta il tuo input.

Il sito carica gli asset statici (HTML, CSS, JS) una volta da un CDN. Dopo di che, funziona offline. Nessun input viene inviato a nessun server. Nessun dato viene loggato, memorizzato o condiviso.

  • JSON Fix —— ripara e formatta JSON non valido, client-side
  • JSON Diff —— confronta due documenti JSON o YAML, client-side
  • Encode & Decode Base64 —— ispeziona payload JWT e data URI senza mandarli da nessuna parte
  • URL Decode —— decodifica percent delle query string in locale
  • Base64 non è cifratura —— perché i dati codificati restano leggibili da chiunque ottenga la stringa