Strumenti per sviluppatori · Generatore UUID
Gli ID sequenziali trapelano dati aziendali: perché le API pubbliche espongono gli UUID
· Perché è importante
uuid crittografia API del browser
Gli ID a incremento automatico indicano agli esterni quanti ordini prendi e rendono ogni record enumerabile. Questo post spiega cosa risolve l'esposizione degli UUID, cosa no e come introdurli senza una migrazione.
I numeri delle tue fatture indicano ai concorrenti il tuo volume: la fuga di informazioni in /orders/10482
Un endpoint API che restituisce /orders/10482 dice a un esterno più dei dettagli dell'ordine stesso. L'identificatore numerico segnala che hai elaborato almeno diecimila ordini, implica informazioni sul tuo tasso di crescita e rende indovinabile ogni ordine. Un semplice ciclo attraverso numeri sequenziali recupera tutti i record senza controlli di autenticazione o autorizzazione. Questo modello appare ovunque, negli URL, nelle chiavi del database, nei numeri delle fatture e negli ID delle transazioni, anche quando il sistema richiede l'autenticazione per visualizzare ogni singolo record. Il problema si aggrava nel reporting e nell'analisi. Un utente malintenzionato in grado di recuperare /orders/1, /orders/2, e continuare fino a /orders/10482 ottiene una visione completa della cronologia e delle tendenze degli ordini.
Enumerazione e scraping: come gli ID sequenziali trasformano un record esposto in tutti i record
Lo schema sequenziale rivela le tendenze relative all'arrivo degli ordini, ai prodotti menzionati e ai modelli di prezzo. Un osservatore apprende la velocità con cui la tua attività cresce o si contrae. Tali informazioni, derivate solo dall’enumerazione degli ID, possono informare la strategia competitiva, guidare l’ingegneria sociale o informare i tempi per altri attacchi. Scoprire l'esposizione non costa nulla e viene visualizzato negli URL, nella cronologia del browser, nelle pagine memorizzate nella cache e nei log del server. Questo non è teorico: le società di intelligence competitiva e gli ingegneri curiosi estraggono regolarmente parametri aziendali da ID enumerabili pubblicamente. Un campione di numeri d'ordine rivela il tasso di produzione e il volume totale a chiunque sia sufficientemente motivato da raccogliere dati ed eseguire analisi di base.
Il problema dei carri armati tedeschi in un paragrafo: stima dei totali da un campione di numeri sequenziali
L'enumerazione applica l'analisi statistica per stimare i volumi totali e tenere traccia dei modelli temporali. Se il primo ordine è avvenuto in una data nota e si acquisiscono prove di dieci ordini distribuiti in una settimana, l'intervallo medio stima il tasso complessivo. Concorrenti, investitori e aggressori possono sfruttare la tua velocità senza accedere ai dati dei clienti oltre agli ID stessi. Gli identificatori sequenziali garantiscono che ogni ID maggiore del numero corrente predice ordini futuri; ogni ID inferiore al minimo in un campione conferma che l'operazione precedente era inferiore. I dati storici creano una sequenza temporale di crescita e consentono previsioni. Questo stesso principio si applica a tutti i settori: transazioni finanziarie, ordini di spedizione, cartelle cliniche e qualsiasi sistema che esponga ID sequenziali.
Cosa risolvono gli UUID: riferimenti non indovinabili e nessun segnale di crescita nell'ID stesso
Un UUID generato casualmente contiene 122 bits di entropia quando generato da una fonte crittograficamente sicura come RFC 9562 specifica per la versione 4. L’identificatore non è indovinabile, non è enumerabile e non rivela nulla sul tasso di crescita o sul volume agli osservatori esterni. Un utente malintenzionato che conosce /orders/9a1f4e2b-7c3e-4d1a-8a5f-1b2c3d4e5f60 non può prevedere il UUID dell'ordine successivo o scorrere all'indietro i tuoi ID storici con ragionevole sicurezza. Lo stesso UUID diventa un riferimento unico ma completamente opaco. La distribuzione casuale significa che più query non rivelano schemi, progressioni e informazioni sulla velocità agli osservatori esterni che monitorano il tuo API.
Ciò che gli UUID non risolvono: un ID non riconoscibile non è un'autorizzazione e l'oscurità necessita ancora di controlli di accesso dietro di esso
La sostituzione di ID sequenziali con UUID nelle API pubbliche è operativamente semplice e non richiede un coordinamento complesso tra i sistemi. Aggiungi una colonna UUID alla tabella degli ordini, generane una per ogni nuovo ordine, esponi UUID nelle risposte e depreca gradualmente la chiave numerica. I tuoi sistemi interni possono continuare a utilizzare chiavi primarie intere per prestazioni e semplicità; cambia solo l'interfaccia pubblica. Il vecchio ID sequenziale rimane nel database per riferimento personale o audit trail, ma i clienti e le terze parti vedono solo UUID. Questo approccio a doppia chiave è una best practice per mantenere la performance dell’indice esistente esponendo al tempo stesso gli identificatori opachi al mondo esterno.
Esempio funzionante: aggiunta di una colonna pubblica UUID accanto a una chiave intera interna ed esposizione solo della prima
Questo approccio è diverso dall'autorizzazione effettiva perché UUID non è una password e l'oscurità non è un controllo di sicurezza. Un cliente che ha accesso legittimo a /orders/{their-uuid} dovrebbe essere in grado di visualizzarlo, ma /orders/{someone-elses-uuid} deve comunque essere rifiutato dai controlli di accesso. UUID nasconde il numero dell'ordine dall'ispezione casuale e impedisce l'analisi statistica tramite enumerazione, ma la logica di autenticazione e autorizzazione rimane di responsabilità del codice dell'applicazione. La protezione è a più livelli: UUID blocca le fughe di informazioni nell'identificatore stesso e il controllo degli accessi impone chi può agire su quell'identificatore.
Ciò che questo non copre: i compromessi tra indice e performance delle chiavi casuali, discussi in un post separato
Il confine operativo è importante perché gli UUID risolvono la perdita di informazioni nell'ID stesso ma non sostituiscono i meccanismi di controllo dell'accesso. Se un cliente dispone di una chiave API e di autorizzazioni sufficienti, può comunque effettuare richieste al tuo sistema. L'ambito a cui possono accedere è determinato dal modello di autorizzazione e dalle definizioni dei ruoli, non dal formato dell'ID. Il vantaggio degli UUID è semplicemente che l'identificatore smette di trasmettere dati su volume, sequenza e crescita a chiunque possa osservarlo. Un sistema ben progettato combina l'opacità di UUID con controlli espliciti di controllo degli accessi su ogni richiesta a API.
Conclusione: separare i riferimenti pubblici dalle chiavi interne: il generatore ToolAcre fornisce UUID supportati da CSPRNG per il lato pubblico
Una migrazione pratica evita un giorno di bandiera supportando gradualmente entrambi i formati. Se esegui la versione dei tuoi endpoint, v1 API può continuare a restituire ID interi mentre v2 restituisce UUID. I clienti effettuano la transizione al proprio ritmo senza richiedere un passaggio coordinato. Le query del tuo database interno rimangono invariate: continuano a filtrare in base all'ID intero perché i tuoi indici sono costruiti su quella colonna e le tue chiavi esterne fanno riferimento ad essa. Cambiano solo i dati restituiti ai client. Il generatore ToolAcre UUID produce il formato versione-4 che utilizzerai; ogni output è un RFC 9562 UUID corretto pronto per scenari di archiviazione, distribuzione e migrazione graduale.