Los usuarios pueden cambiar `?account_id=123` por `124` y ver los datos de otros usuarios. ¿Qué categoría es y cómo se corrige?

Cuando cambiar account_id=123 por 124 devuelve los datos de otra persona, la aplicación identifica el objeto pero nunca pregunta si este usuario tiene permiso para verlo. Es una referencia directa a objeto insegura (IDOR), una forma de control de acceso roto — la categoría de riesgo número uno de OWASP.

La corrección correcta: autorización a nivel de objeto en el servidor

En cada solicitud que toque un objeto concreto, el servidor debe comprobar que el principal autenticado está autorizado para ese objeto exacto — por ejemplo, que la cuenta pertenece al usuario actual (o está compartida con él) — y denegar en caso contrario. Esta comprobación debe residir en el servidor y ejecutarse en todas las rutas de acceso, no solo en la interfaz que "normalmente" muestra la cuenta correcta. La referencia en sí puede seguir siendo un entero simple; lo que importa es la decisión de autorización tras ella.

Por qué los distractores son erróneos

• Sanear el número valida el formato, no la propiedad. 124 es un entero perfectamente válido y aun así pertenece a otra persona.
• Cifrar u ofuscar el account_id es seguridad por oscuridad. Los ID cifrados o aleatorios se filtran en URL, registros, encabezados Referer e historial del navegador, y pueden reproducirse; pasar a UUID eleva la barrera de adivinación pero sigue devolviendo datos a cualquiera que obtenga una referencia válida. El defecto real es la falta de comprobación de autorización.
• Cambiar de GET a POST cambia el verbo HTTP y dónde viaja el parámetro, no si el servidor autoriza la solicitud. El atacante simplemente envía un POST.

Qué evalúa el entrevistador

Quiere que nombres correctamente la clase de vulnerabilidad (control de acceso roto / IDOR), que resistas las correcciones tentadoras pero superficiales y que sitúes el control en el lugar adecuado: una decisión de autorización por objeto, en el servidor, aplicada de forma uniforme. Los buenos candidatos añaden que esto se aplica mejor de forma centralizada — mediante una capa de autorización compartida o middleware — para que ningún endpoint olvide la comprobación, y que la ofuscación es a lo sumo defensa en profundidad, nunca la solución.