Un endpoint de API vincula todo el cuerpo JSON al modelo de usuario, de modo que un usuario puede enviar `"isAdmin": true`. ¿Qué es esto y la corrección?
Respuesta breve
Es un fallo de asignación masiva (over-posting): el servidor mapea a ciegas el JSON del cliente sobre campos sensibles del modelo. Corrígelo vinculando solo una lista blanca explícita de campos permitidos (DTO / strong params) para que atributos privilegiados como isAdmin no los pueda establecer el cliente. Ocultar el campo en el frontend y añadir validación en el cliente se evitan ambos con una solicitud cruda. Renombrar isAdmin es oscuridad, fácilmente descubierta. Controla qué campos se vinculan, en el servidor.
El endpoint toma todo el objeto JSON entrante y mapea cada propiedad directamente sobre el modelo de usuario. Un cliente normal envía name y email; un atacante añade "isAdmin": true y el framework lo establece diligentemente. Esto es asignación masiva (también llamada over-posting o auto-binding), una forma de autorización rota a nivel de propiedades de objeto.
La corrección correcta: vinculación con lista blanca en el servidor
Decide, en el servidor, exactamente qué campos puede establecer una solicitud dada, y vincula solo esos. En concreto:
- Usa un DTO / view model / «strong parameters» que contenga solo los campos editables para esta operación, y mapea desde él — nunca vincules la solicitud cruda directamente al modelo de persistencia.
- Trata los atributos privilegiados (
isAdmin,role,balance,verified) como nunca establecibles por el cliente; solo cambian mediante flujos dedicados y autorizados.
Una lista blanca es el valor por defecto seguro porque todo lo que olvides queda por defecto sin vincular. Una lista negra de campos «prohibidos» falla en cuanto alguien añade una nueva columna sensible y no actualiza la lista.
Por qué los distractores son erróneos
- Ocultar el campo en el frontend confunde la IU con la API. El atacante no usa tu formulario — envía una solicitud HTTP cruda con el JSON que quiera.
- Renombrar isAdmin es seguridad por oscuridad. Los nombres de campo se filtran por respuestas de API, source maps, documentación y mensajes de error, y se adivinan o descubren rápido.
- Añadir validación en el cliente se ejecuta en el navegador del atacante, que él controla por completo; se evita trivialmente con curl o un proxy de interceptación.
Qué evalúa el entrevistador
Si reconoces que la confianza debe imponerse en el servidor, en la capa de vinculación, sabes nombrar el patrón DTO/strong-params y entiendes por qué la lista blanca supera tanto los trucos de IU como las listas negras. La señal de una respuesta débil es corregirlo donde el cliente puede ver — porque el cliente es precisamente en quien no se puede confiar.
Posibles preguntas de seguimiento
- ¿Cómo imponen la lista blanca los DTO o los «strong parameters», y dónde ocurre la vinculación?
- ¿Cómo encontrarías todos los endpoints propensos a asignación masiva en una API grande?
- ¿Por qué una lista blanca es más segura que una lista negra de campos prohibidos?