API que devuelve la excepción de Java. ¿Seguro?

Oct 23 2020

Solo quería preguntar si mis preocupaciones aquí son válidas.

Soy consciente de que no es seguro que la API devuelva un seguimiento de pila. Tengo una situación similar, pero menos atroz, que estoy tratando de juzgar.

¿Existe también algún estándar con respecto al empaquetado de excepciones de Java en una respuesta 500? Por ejemplo, devolver cosas como "DataIntegrityViolationException", "NullPointerException", etc., pero sin el seguimiento de la pila.

Dicho de otra manera, cuando se produce una excepción no controlada, el nombre de la excepción se devuelve en la respuesta 500. No hay seguimiento de pila, pero podemos inferir en el lado del cliente si, por ejemplo, la solicitud intentó alterar la base de datos de una manera no válida.

Actualmente estoy advirtiendo a mi equipo contra esto y les digo que deben "incluir en la lista blanca" las respuestas de sus servidores (es decir, solo enviar contenido si tiene una razón consciente para hacerlo). Solo quería saber si les estoy perdiendo el tiempo con esto.

¿Es esta una buena idea?

¿O debería ser más genérico que esto?

Respuestas

1 schroeder Oct 28 2020 at 00:05

El estándar en el manejo de errores para el cliente es no exponer nada sobre el funcionamiento interno y solo proporcionar lo que será útil para que el usuario tenga éxito.

El contenido del mensaje de error de Java no ayuda al usuario. Lo que terminas haciendo es exponer la lógica de tu código, que un usuario malintencionado puede usar en tu contra.

Los ejemplos de OWASP son simplemente para indicar que hay un error. Y ese es el estándar. Cualquier información más allá de esto debe tener una justificación.