Es un escenario típico con .NET MVC: las URL amigables para los motores de búsqueda son el resultado directo de la implementación adecuada. Pero tengamos algo claro: estos no son directorios web, sino rutas MVC, ¿verdad?
Los probadores de lápiz paranoicos a menudo son incómodos cuando la interfaz de administración está expuesta de alguna manera en la URL, ya que puede atraer atención no deseada, o puede ser recolectada y utilizada para difuminar.
Si desea mejorar esto, es posible que deba abusar del motor de enrutamiento ASP.NET para ofuscar la ruta, si su preocupación es que la interfaz de administración está "expuesta", eso sería una solución rápida, pero la ofuscación es Nunca la forma correcta de arreglar las cosas.
Una alternativa es usar un administrador de recursos y el enrutamiento se basa en tokens de recursos, pero eso implicaría modificaciones importantes en la aplicación. Cada recurso tiene su propia ID de token de recursos y se puede generar dinámicamente cuando un usuario inicia sesión. Luego, cada recurso (página, estilo, imagen) es un enlace al administrador de recursos. Luego, obtener una hoja de estilo se verá así:
<link rel="stylesheet" type="text/css" href="/Resource/80af9420ab0401-00291844a/91009abff01">
Lo mismo se aplica a las URL. Esto puede generar una gran cantidad de gastos generales y un rendimiento deficiente, escalabilidad deficiente, etc. No lo recomiendo , pero en estos días la administración solo escucha a los "consultores" externos a los que les pagan y se niega. para reconocer el talento interno.
Desafortunadamente, a veces es una cuestión de compromiso: la seguridad no debe ser el resultado de escalabilidad o rendimiento deficientes ...