Si tienes este problema Y,
es incorrecto devolver un 404 cuando el recurso no existe porque esto ayuda a enumerar los recursos existentes.
entonces esto significa que tienes este problema X:
La enumeración de recursos debe evitarse .
Esto, a su vez, puede afectar solo a todos los recursos o recursos no autenticados. En otras palabras, es posible que pueda mitigar el problema al requerir la autenticación antes de solicitar un recurso determinado.
De lo contrario, podría hacer que dicho recurso sea difícil de adivinar e implementar algún tipo de detección de escáner (simplemente almacenando qué recursos se obtienen por 404 por qué red durante algún tiempo podría ser suficiente. Tal vez podría descargar el problema a una instalación de fail2ban ).
El problema que se menciona tiene poco sentido porque no puede devolver un recurso válido si se solicitó uno inválido. En general, ¡no puede recuperar recursos razonables y creíbles de la nada! Así que siempre habrá una manera de distinguir entre los recursos que existen y los que no. Por supuesto, suministrar la información en un encabezado de estado HTTP simplifica las cosas para el atacante, pero también facilita las cosas para usted .
En algunos casos, es posible que pueda sintetizar un recurso no existente. Por ejemplo, digamos que ofreces algo parecido a un servicio de avatar. Entonces /users/lserni/avatar.png podría devolver mi imagen, mientras que /users/someoneelse/avatar.png podría devolver una imagen aleatoria generada usando "someoneelse" como semilla aleatoria, de modo que la misma otra persona siempre recupere el mismo PNG. Pero como puede ver, este tipo de enfoque requiere un conocimiento de dominio específico, no puede haber una regla de talla única para todos.