Lanzar un error 404 para cada solicitud no válida podría ser cuestionable, un atacante puede comenzar a sospechar este comportamiento, especialmente si conoce el servicio al que se dirige.
¿Ayuda esto a proteger su servicio? esto realmente depende de la perseverancia del atacante.
Editar :
El atacante puede detectar la diferencia si no elabora correctamente el encabezado de respuesta 404 como lo haría el servidor
Aquí hay un PoC para el caso del servidor Java (Tomcat8):
Este es un estado 404 'veraz' devuelto por el propio servidor para cualquier recurso no encontrado:
Content-Language:en
Content-Length:1026
Content-Type:text/html;charset=utf-8
Date:Tue, 31 Jan 2017 09:15:54 GMT
Server:Apache-Coyote/1.1
Este es devuelto por el servlet:
Content-Language:en
Content-Length:992
Content-Type:text/html;charset=utf-8
Date:Tue, 31 Jan 2017 09:18:04 GMT
Server:Apache-Coyote/1.1
Observa el valor del parámetro de "Content-length" en ambos casos, éste podría atraer la atención del atacante.
Cuidado, ocultar el código de error real huele un poco a ofuscación. No hay nada realmente malo desde el punto de vista de la seguridad, pero agrega poca seguridad, si es que agrega alguna. ¿De verdad crees que los atacantes aceptan ciegamente los códigos de error? Sabes que se pueden cambiar a voluntad, y ellos también. De acuerdo, puede ser útil contra script kiddies pero no frente a un ataque serio, por lo que realmente debería pensar cuál es su modelo de amenaza antes de ir por ese camino.
Y podría haber un inconveniente aquí. A menos que cree un sistema de registro especial que registre el error interno, terminará con registros que contienen solo errores 404. Eso significa que tú han perdido toda posibilidad de análisis de registros para tratar de descubrir ataques a su sitio y posibles fallas de seguridad. En mi humilde opinión, los códigos de error son más útiles para el mantenedor de una aplicación que para un atacante...