Una aplicación de notas permite a Alice guardar el “Borrador del presupuesto trimestral” como la nota 1. Bob inicia sesión en su propia cuenta, solicita GET /notes/1 y recibe la nota de Alice, ya que el servidor verifica que Bob ha iniciado sesión, pero nunca comprueba si Bob es el propietario de la nota 1. Bob no necesitó la contraseña de Alice ni permisos especiales, solo un identificador predecible. Si Bob solicita la nota 1, ¿debería la API devolver el contenido de Alice? El pequeño ejemplo local que aparece a continuación muestra la solicitud y la respuesta inseguras:
Este código devuelve el registro JSON de Alice identificando a Bob como el usuario que realiza la acción. El fallo observable es un control de acceso deficiente (o roto), donde el servidor permite que una persona autenticada realice una acción para la cual no tiene permiso. La medida preventiva inmediata consiste en verificar la propiedad en el servidor antes de leer la nota; la señal de detección es una entrada en el registro que incluye a Bob, la nota 1 y una decisión de autorización denegada. Seguiremos reparando esta aplicación de notas, de modo que cada regla de seguridad permanezca vinculada a una solicitud, a un fragmento de código y a un método para verificar la corrección.
La ausencia de una verificación de propiedad es relevante porque el navegador se encuentra fuera del límite de confianza del servidor de API. Un límite de confianza es el punto donde la aplicación recibe datos o instrucciones que pueden ser influenciados por terceros; por tanto, el servidor debe validarlos y aplicar sus propias reglas. La cookie de Bob y el ID de la nota solicitada pasan de un cliente no confiable al servidor; la API envía una consulta a la base de datos únicamente después de haber tomado la decisión de autorización.
La misma aplicación cuenta con más de un punto de entrada. Un usuario de Internet no autenticado puede enviar datos de inicio de sesión o crear una nota. Un usuario con privilegios limitados, como Bob, puede proporcionar IDs y texto de notas tras iniciar sesión. Una dependencia comprometida puede introducirse durante la fase de compilación, cuando el registro de paquetes suministra código que el servidor ejecutará posteriormente. Los activos que requieren protección son las sesiones activas, las notas de Alice, los secretos del servidor y los registros que indican qué solicitudes se han producido. El diagrama sigue el recorrido de cada entrada hasta el componente que debe decidir si confiar en ella: