API renvoyant une exception Java. Sûr?
Je voulais juste demander si mes préoccupations ici sont valables.
Je suis conscient qu'il n'est pas sûr pour l'API de renvoyer une trace de pile. J'ai une situation similaire, mais moins flagrante, que j'essaie de juger.
Existe-t-il également une norme concernant l'empaquetage des exceptions Java dans une réponse 500? Par exemple, renvoyer des éléments tels que «DataIntegrityViolationException», «NullPointerException», etc., mais sans la trace de la pile.
En d'autres termes, lorsqu'une exception non gérée se produit, le nom de l'exception est renvoyé dans la réponse 500. Il n'y a pas de trace de pile, mais nous pouvons déduire du côté client si, par exemple, la requête a tenté de modifier la base de données d'une manière non valide.
J'avertis actuellement mon équipe contre cela et je leur dis qu'ils devraient «mettre sur liste blanche» leurs réponses de serveur (c'est-à-dire n'envoyer du contenu que si vous avez une raison consciente de le faire). Je voulais juste savoir si je perds leur temps avec ça.
Est-ce une bonne idée?
Ou devrait-il être plus générique que cela?
Réponses
La norme dans la gestion des erreurs pour le client est de ne rien révéler sur le fonctionnement interne et de ne fournir que ce qui sera utile pour que l'utilisateur réussisse.
Le contenu des messages d'erreur Java n'aide en rien l'utilisateur. Ce que vous finissez par faire, c'est exposer votre logique de code, qui peut être utilisée contre vous par un utilisateur malveillant.
Les exemples d'OWASP sont simplement pour déclarer qu'il y a une erreur. Et c'est la norme. Toute information au-delà de cela doit avoir une justification.