¿Es una falla de seguridad registrar la clase y el nombre del método cuando ocurre una excepción?

Tengo lo siguiente:

public class doCheck(){

    public void performCheck(){
        try {
            perform all checks......
        }
        catch(Exception e){
            logger.error("Exception occured in class doCheck in method performCheck");
            thrown new MyNewException(e.getMessage());
        }
    }
}

¿Es seguro registrar la clase y el nombre del método?

Eso depende de si su base de código está oculta o no. Si envía el producto al cliente, él puede inspeccionar el código de bytes de Java de manera trivial de todos modos, por lo que registrar nombres de clase no revela ninguna información que el usuario no pueda obtener de todos modos.

Para una aplicación del lado del servidor, esto sigue siendo cierto. Sin embargo, puede ser un agujero de seguridad mostrar tales registros al cliente. Es por eso que la mayoría de los marcos de aplicaciones web distinguen entre una configuración de desarrollo y producción: durante el desarrollo, la información de depuración se muestra al usuario en caso de error. En producción, esta información se registra en el servidor, pero ya no se muestra en el navegador web / al cliente.

@Konrad respondió la pregunta directa, sin embargo, su manejo de excepciones tiene un problema menor y dos graves. Como originalmente publicó en codereview.SE, aquí están:

1. Registrar una excepción antes de lanzar no tiene sentido. Regístrelo donde lo maneje y no se moleste en atraparlo si no planea manejarlo.
2. Si va a registrar una excepción, registre la excepción; no diga simplemente "ocurrió una excepción" y espere que la gente adivine cuál es la excepción. Todos los marcos de registro comunes proporcionan un método de dos argumentos: el primero es el mensaje, el segundo es el que se puede lanzar.
3. Volver a lanzar una excepción con solo un mensaje es el mismo problema pero una instancia peor. Puedo entender (apenas) por qué es posible que no desee que se muestre un seguimiento de pila de excepción en sus registros. Pero una vez que lanza la nueva excepción, no tiene absolutamente ninguna manera de saber cuál es el verdadero problema . Especialmente si mantienes el hábito de atrapar y volver a lanzar.

OK, voy a agregar un cuarto problema: usted registra dónde ocurrió la excepción, pero no dice lo que estaba haciendo cuando sucedió, ni proporciona información contextual. Si registra la excepción real (punto 1), sabrá dónde sucedió. Más importante es decir algo como "no se puede abrir el archivo foo.txt".

No es particularmente inseguro, así que a menos que haya algo crítico que desee ocultar en esta clase o si la clase es parte de una ruta crítica (como un apretón de manos seguro o una función "oculta"), no consideraría esto un problema en absoluto.

Además, estamos hablando de Java aquí. Entonces, si estamos hablando de una aplicación del lado del cliente que ejecuta Java en el cliente, siempre pueden modificar su JRE para agregar sus propias rutinas de depuración y / o usar un cargador de clases personalizado y acceder a sus clases casi de la manera que quieran. Siempre es una posibilidad hacer que sea más difícil para ellos (ocultar cosas más profundas, o incluso ofuscar código), pero por lo general no es rentable si se considera el tiempo y el esfuerzo necesarios para lograr esto contra la pérdida causada por estadísticas improbables. usuarios maliciosos

Si estamos hablando de una pieza de software del lado del servidor que puede generar registros a los clientes (por ejemplo, al navegador del usuario), entonces probablemente no sea un gran problema, pero ya es más sencillo de solucionar: configure su contenedor en consecuencia, y utilice un marco de registro o multiplexor para enviar a los archivos apropiados en el servidor con fines de depuración. De esta forma, conserva los registros útiles para la depuración, pero no compromete la información potencialmente útil.

Pero en general, esto probablemente no sería un problema. es más lo que pones en el mensaje de depuración que podría ser un problema, ya que a menudo tendemos como desarrolladores a generar cosas en las que trabajamos (no quieres dejar estas salidas de depuración para nombres de usuario, contraseñas, sales y tokens de seguridad a la vista) )