¿Es mala práctica usar directamente el ID del usuario en las URLs?

Dance

Hola a todos, estoy desarrollando una API REST para una aplicación de gestión de usuarios. Tengo una duda sobre la seguridad y buenas prácticas: ¿es aceptable exponer el ID del usuario en las rutas, por ejemplo /api/users/123? He visto que algunos dicen que es inseguro porque cualquiera podría adivinar IDs y acceder a datos de otros usuarios. ¿Debería usar algo como un UUID o token en su lugar? ¿O es suficiente con validar permisos en el backend? Me gustaría saber cómo lo manejan ustedes en producción.

Podcasts

No es una mala práctica en sí misma, siempre que tengas una buena autorización. El ID numérico es simple y eficiente para índices de base de datos. Lo clave es que en cada endpoint verifiques que el usuario autenticado tenga permiso para acceder al recurso. Si usas UUIDs, el rendimiento puede verse afectado en tablas grandes con índices. Yo prefiero IDs numéricos con autorización robusta.

Traveler

Discrepo parcialmente. Aunque la autorización es obligatoria, usar IDs numéricos secuenciales permite a un atacante enumerar usuarios fácilmente. Si por error hay un fallo de permisos, se expone mucha información. Recomiendo usar UUIDs v4 o hashes cortos (como hashids) para ofuscar los IDs. Es una capa extra que no cuesta tanto y puede prevenir fugas accidentales.

Dance

Gracias por las respuestas. Entonces, ¿recomiendan que implemente UUID incluso si tengo autorización? Me preocupa el rendimiento, pero también la seguridad. ¿Alguien ha usado hashids en producción? ¿Funciona bien con consultas a la base de datos?

Security

Yo uso hashids en varios proyectos y va muy bien. Solo codificas el ID para la URL y lo decodificas en el backend. Las consultas siguen usando el ID numérico internamente, así que no hay impacto en el rendimiento de la BD. Es un buen compromiso entre seguridad y eficiencia. Además, si usas caché, las claves pueden ser los hash en lugar de los IDs.

ScienceFan

Otra opción es usar IDs numéricos pero no secuenciales, por ejemplo, IDs aleatorios generados al crear el usuario (como un serial aleatorio). Así evitas la enumeración sin recurrir a UUIDs o hashes. Eso sí, necesitas un campo adicional o modificar la generación de la clave primaria.

Dance

Me parece buena idea lo de los IDs no secuenciales, pero quizás sea más sencillo empezar con hashids. Voy a probarlo en un entorno de prueba. ¡Gracias a todos por los consejos!

Soul

Hashids es decente para ofuscar, pero no es criptográficamente seguro. Si alguien se toma la molestia, puede revertir la codificación con un poco de esfuerzo. Si realmente te preocupa la enumeración, mejor usa UUIDs en la URL o tokens aleatorios largos con secrets.token_urlsafe(32). Además, con Hashids sigues exponiendo un patrón: las longitudes de los hash varían según el ID, lo que filtra información. Para un proyecto pequeño vale, pero para algo serio no lo recomendaría.