API che restituisce un'eccezione Java. Sicuro?
Volevo solo chiedere se le mie preoccupazioni qui sono valide.
Sono consapevole del fatto che non è sicuro per l'API restituire un'analisi dello stack. Ho una situazione simile, ma meno eclatante, che sto cercando di giudicare.
Esiste anche uno standard per impacchettare le eccezioni Java in una risposta 500? Ad esempio, inviare indietro cose come "DataIntegrityViolationException", "NullPointerException", ecc., Ma senza la traccia dello stack.
In altre parole, quando si verifica un'eccezione non gestita, il nome dell'eccezione viene restituito nella risposta 500. Non c'è traccia dello stack, ma possiamo dedurre dal lato client se, ad esempio, la richiesta ha tentato di alterare il DB in modo non valido.
Al momento sto avvertendo il mio team di ciò e dicendo loro che dovrebbero "inserire nella whitelist" le loro risposte al server (ad esempio, inviare il contenuto solo se hai una ragione consapevole per farlo). Volevo solo sapere se sto sprecando il loro tempo con questo.
E 'questa una buona idea?
O dovrebbe essere più generico di così?
Risposte
Lo standard nella gestione degli errori per il cliente è di non esporre nulla riguardo al funzionamento interno e fornire solo ciò che sarà utile per il successo dell'utente .
Il contenuto del messaggio di errore Java non fa nulla per aiutare l'utente. Quello che finisci per fare è esporre la logica del codice, che può essere utilizzata contro di te da un utente malintenzionato.
Gli esempi di OWASP sono semplicemente per affermare che c'è un errore. E questo è lo standard. Qualsiasi informazione oltre a questa deve avere una giustificazione.