Autenticación y autorización por endpoint, leída

5 tareas · 40 min · Principiante

En un contrato OpenAPI la seguridad se declara en dos niveles: una regla global y la que cada operación escribe para sí misma. Leer el contrato operación por operación es la forma más barata de encontrar un endpoint que quedó abierto o con un permiso menor del que merece. En Mayoristas Boquerón lees el contrato de la API de clientes y las reglas de acceso del equipo, y las comparas. Todo es lectura de archivos ficticios; no se llama a ninguna API.

0 de 5 · 0%

Objetivo de la sala

Un contrato define esquemas de seguridad (securitySchemes: OAuth 2.0 con sus alcances, clave de API, etc.) y luego los exige. La clave security en la raíz es el requisito por defecto de todas las operaciones. Una operación que escribe su propia security sustituye al requisito global. Si la operación escribe una lista vacía, security: [], no exige nada.

Por eso, para saber qué pide de verdad una operación hay que mirar dos sitios: si ella declara su seguridad, vale esa; si no la declara, hereda la global.

Responde para continuar

Una operación del contrato escribe su propia clave security. ¿Qué requisito se aplica a esa operación?

El de la propia operación, que sustituye al global El global y el de la operación, combinados, porque ambos aparecen escritos El global, porque el requisito de la raíz manda sobre cualquier otro escrito en el contrato

Ver pista de ayuda

Una lista vacía en la operación es la señal más clara de que sustituye al global.

Un servicio de estado que responde «ok» puede ser público sin riesgo: no devuelve datos. Pero una operación abierta que devuelve información de cuentas es una puerta sin cerradura. En el contrato de clientes, el equipo escribió una regla: solo el servicio de estado puede quedar sin autenticación.

Busca las operaciones sin credencial y descarta la que la regla permite.

Responde para continuar

Escribe el operationId de la operación sin credencial que la regla del equipo no permite.

Ver pista de ayuda

Busca `security: []` en `contratos/clientes.yaml` y lee `notas/reglas-de-acceso.txt`.

Las operaciones que no escriben security heredan el requisito global; aquí, el alcance de lectura. Es correcto para consultas, pero una herencia silenciosa en una operación que modifica datos sería un fallo. Contar las que heredan permite revisar si la herencia tiene sentido en cada una.

Responde para continuar

¿Cuántas operaciones del contrato de clientes no declaran security y heredan el requisito global?

Ver pista de ayuda

Cuenta las operaciones de `contratos/clientes.yaml` que no tienen la clave `security`.

Los alcances (scopes) de OAuth 2.0 limitan lo que un token puede hacer. Una operación destructiva con un alcance de lectura permite que un token que solo debía consultar borre datos. Esto es un fallo de autorización a nivel de función: el contrato lo hace visible si se compara con la regla del equipo, que dice qué alcance corresponde a cada acción.

Responde para continuar

Escribe el operationId de la operación que borra clientes y exige solo el alcance de lectura.

Ver pista de ayuda

Compara cada operación de `contratos/clientes.yaml` con las reglas de `notas/reglas-de-acceso.txt`.

El contrato declara qué credencial se exige y con qué alcance. No puede expresar «solo los clientes de tu propia cuenta»: esa comprobación vive en el código del servicio. Es la autorización a nivel de objeto, la primera categoría de la lista OWASP API Security Top 10 de 2023 (API1:2023). El contrato más perfecto del mundo no la garantiza.

Por eso la lectura del contrato se complementa con pruebas que usan dos cuentas distintas, y con la revisión del código que consulta el recurso.

Responde para continuar

Un contrato exige OAuth con el alcance correcto en verCliente. ¿Qué falta para saber que un usuario no ve clientes de otra cuenta?

Comprobar que el servicio verifica la pertenencia del cliente, con pruebas o revisando el código Añadir más alcances al contrato, uno por cada cuenta que use la API Nada: si el alcance es el correcto, el contrato ya garantiza esa pertenencia del cliente a la cuenta

Ver pista de ayuda

La regla sobre a quién pertenece cada cliente está anotada en el laboratorio como parte del código.

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 Seguridad global y seguridad por operación

2 La operación que quedó abierta Lab

3 Lo que se hereda Lab

4 Un alcance menor del que merece Lab

5 Lo que el contrato no puede decir

Whoami-Labs Pro utiliza cookies