A menos que el sitio ahora tenga controles de acceso en las URL (lo que requiere que primero se autentique - pruebe su identidad - y luego que el servidor verifique si su identidad está autorizada para ver esa URL), no, no es seguro . Los problemas obvios incluyen personas que comparten enlaces a través de un sitio como este (sin redactar el dominio), navegadores que recuerdan la URL en sus historiales (en una computadora compartida), o alguien (interno o externo) descargando y compartiendo una lista de URL válidas.
El término utilizado para este tipo de vulnerabilidad de seguridad es una "referencia directa de objeto", cuando se ingresa la ID de un objeto le permite acceder al objeto incluso si normalmente no tendría acceso. La única solución verdadera al problema son los controles de acceso adecuados. El simple hecho de que sea difícil adivinar la identificación del objeto no resuelve el problema , aunque a corto plazo puede dificultar la explotación. Poner secretos en la URL realmente no resuelve nada; necesita un sistema que se base en credenciales reales.
Ahora, en cuanto a la enumeración: como indican los comentarios, es una codificación muy sospechosa. El prefijo repetido indica que, independientemente de lo que estén haciendo, no están usando un hash seguro (o no lo están usando correctamente). Dado que presumiblemente están tratando de asignar desde una URL a un identificador de objeto, probablemente sea una codificación reversible de todos modos.
El cifrado de la cadena de consulta de la URL con una clave secreta conocida solo por el servidor producirá enlaces difíciles de adivinar, aunque, dependiendo del tipo de cifrado utilizado, todavía puede ser posible voltear bits y producir nuevas URL válidas sin conocer la clave de cifrado (para evitar esto, deberían agregar una verificación de integridad, como un HMAC o un esquema de cifrado autenticado). El cifrado, por sí mismo, no impide que un atacante manipule el texto cifrado (y con algunos esquemas de cifrado, la manipulación es fácil). En cualquier caso, un sistema de este tipo depende de que la clave permanezca en secreto, lo que genera un único punto de falla.
Encriptar la cadena de consulta con una clave conocida , por ejemplo, si la clave está en ese prefijo que no cambia, está completamente rota. Descubrir el esquema de criptografía usado tomaría un poco de adivinación y verificación (educado), pero el espacio de los posibles sistemas tomaría muy poco tiempo para buscar. Una vez que se sabe, crear URL válidas es trivial.
La forma menos mala de hacer esto (no hay una buena manera; para cualquier cosa sensible, simplemente debe usar la autenticación y los controles de acceso) sería almacenar de forma razonablemente larga (más de 64 bits; los GUID se utilizan aquí), criptográficamente. Asegurar identificadores aleatorios para cada fila en la base de datos. Luego, cifralos, con una clave secreta del lado del servidor, antes de convertirlos en URL. Esto evita puntos únicos de falla (las ID aleatorias son inútiles sin la clave y viceversa) para comprometer la lista completa de URL válidas, y también significa que podría hacer cosas como cambiar periódicamente los tokens de ID para invalidar las URL antiguas para esos objetos , o cambiando la clave de cifrado para invalidar todas las URL antiguas. Sería seguro contra el cambio de bits del texto cifrado porque no hay manera de decir "asuma que esta parte es un número, luego intente voltear los bits para producir otro número válido"; las combinaciones válidas de bits son una parte indiscutiblemente pequeña del espacio de búsqueda de posibles identificadores, porque los identificadores no son secuenciales y son lo suficientemente largos como para que solo se utilice una fracción infinitesimal.
Pero, debo enfatizar nuevamente: esta es una idea mucho peor que simplemente poner en práctica la autenticación y la autorización adecuadas . Si has hecho eso, puedes apegarte de forma segura a simples identificadores numéricos incrementales porque adivinar el siguiente valor no le gana nada a un atacante.