Supponiamo che ci sia un sito Web con un'API che supporta la seguente chiamata REST in cui l'utente autenticato Alice può inviare un utente registrato a Bob un messaggio sul suo cellulare che ha registrato sul nostro sito (ipoteticamente, per il bene di questo esempio ):
curl --header "Authorization: JWT $someTokenForAuthz" \
--header "Content-Type: application/json" \
--request POST \
--data '{"phone":"+43 123 456","msg":"some text"}'
http://example.com/text/send
Supponiamo di classificare il numero di telefono come dati sensibili (PII) e supponiamo che l'API restituisca la risposta seguente nel caso in cui venga inviato un numero di telefono, che non è stato registrato sul sito:
{"error": {"code":404,"message":"Phone number not found"}}
Immagina Eve che scrive uno script che itera attraverso i numeri di cellulare da +43 000 001 a +43 999 999 (ignorando le limitazioni del numero di telefono del mondo reale). Con il codice di errore e dopo 1 000 000 iterazioni del suo script, Eve ha elencato tutti i numeri registrati nel sito e può ad es. indirizzare gli utenti del sito in un modo più specifico.
È un problema di sicurezza restituire un codice di errore HTTP 404 quando nel nostro sistema non sono stati trovati dati sensibili come un numero di cellulare? Quale sarebbe un modo migliore in termini di gestione degli errori (come una strategia di backup nel caso in cui i limiti delle richieste / i meccanismi di rilevamento già presenti potrebbero non riuscire) per impedire la scoperta di tali dati sensibili? Un errore di 401 - not authorized più generale o qualcosa di completamente diverso?