Lancer une erreur 404 pour chaque requête invalide peut être discutable, un attaquant peut commencer à suspecter ce comportement spécialement s'il connaît le service qu'il cible.
Cela aide-t-il à protéger votre service ? cela dépend vraiment de la persévérance de l'attaquant.
Modifier :
L'attaquant peut détecter la différence si vous ne créez pas correctement l'en-tête de réponse 404 comme le ferait le serveur
Voici un PoC pour le cas du serveur Java (Tomcat8) :
Il s'agit d'un statut 404 "véridique" renvoyé par le serveur lui-même pour toute ressource introuvable :
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
Celui-ci est retourné par la 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
Vous remarquez la valeur du paramètre "Content-length" dans les deux cas, celui-ci pourrait attirer l'attention de l'agresseur.
Attention, cacher le code d'erreur réel sent un peu l'obscurcissement. Il n'y a rien de vraiment mauvais du point de vue de la sécurité, mais cela ajoute peu de sécurité, voire aucune. Pensez-vous vraiment que les attaquants acceptent aveuglément les codes d'erreur ? Vous savez qu'ils peuvent être modifiés à volonté, et ils le font aussi. Ok, cela peut être utile contre les script kiddies mais pas face à une attaque sérieuse, donc vous devriez vraiment réfléchir à quel est votre modèle de menace avant d'aller dans cette direction.
Et il pourrait y avoir un inconvénient ici. À moins que vous ne construisiez un système de journalisation spécial qui consigne l'erreur interne, vous vous retrouverez dans des journaux contenant uniquement des erreurs 404. Cela signifie que vous avez perdu toute possibilité d'analyse des logs pour tenter de découvrir des attaques sur votre site et d'éventuelles failles de sécurité. Les codes d'erreur IMHO sont plus utiles pour le mainteneur d'une application que pour un attaquant...