Tema: authorization
-
Elegir los puntos de control de permisos para trabajos en cola tras revocar el acceso
Hacer explícito el momento de la autorización cuando una solicitud programa un trabajo que se ejecutará más tarde. El ejercicio propuesto separa el permiso para encolar un trabajo del permiso para ejecutarlo y para recuperar su resultado.
-
Comprobar que un mecanismo de omisión de emergencia termina cuando termina su autorización
Comprobar el ciclo de vida de un mecanismo de omisión de emergencia aprobado explícitamente en un entorno controlado. El método propuesto distingue entre la autorización ordinaria, la autoridad excepcional temporal y el retorno a la política ordinaria.
-
Mantener la autorización en vigor cuando fallan las dependencias
Probar la decisión de seguridad que se toma cuando una dependencia requerida no está disponible. Esta propuesta original de inyección de fallos hace visible el comportamiento de tipo fail-open sin asumir que todo servicio deba devolver la misma respuesta de error o disponibilidad.
-
Probar que las actualizaciones de perfil no pueden asignar campos privilegiados de la cuenta
Crear una regresión acotada para las actualizaciones que aceptan datos de perfil ordinarios junto con campos que quien llama no debe poder controlar. El método propone una titularidad explícita de los campos en lugar de una lista de verificación genérica de validación de entradas.
-
Reenvío de tokens y el diputado confundido en servidores MCP que llaman a otras API
Un servidor MCP que reenvía el token de un cliente a una API subyacente, o que usa sus propias credenciales amplias en nombre de quien lo solicite, permite que quien llama actúe con una autoridad que nunca se le concedió. La guía de seguridad de MCP prohíbe el reenvío de tokens y describe el flujo del diputado confundido para servidores proxy.
-
Probar los cursores de continuación tras un cambio en la identidad solicitante
Comprobar la política de visibilidad de la aplicación cuando un cursor de continuación se reutiliza bajo un principal distinto. Este método original trata el cursor como parte de un contexto de consulta cuyo significado de seguridad debe especificarse.
-
Probar la autorización de las transiciones de flujo de trabajo en lugar del acceso a pantallas
Comprobar si quien llama puede realizar una transición de estado concreta, incluidas transiciones que la interfaz actual no expone. Esta metodología propuesta apunta a flujos de aprobación cuya política de seguridad depende tanto de la identidad como del estado actual.
-
Comprobar quién puede restaurar un objeto eliminado y sus permisos anteriores
Tratar la restauración de un objeto eliminado como una nueva decisión de autorización con una semántica de permisos explícita. Este fixture propuesto apunta a la brecha entre la política de eliminación y el comportamiento de restauración.
-
Probar cambios de configuración que alteran la autoridad de otro usuario
Identificar las escrituras de configuración que otorgan permisos de forma indirecta, incluso cuando su endpoint parece una edición de configuración ordinaria. Esta propuesta sigue el cambio de autoridad resultante en lugar de juzgar el riesgo por el nombre de la ruta.
-
Probar el acceso a una exportación privada desde la solicitud hasta su eliminación final
Seguir una exportación privada a través de la generación, la recuperación, la caducidad y la limpieza. El método propuesto comprueba todo el ciclo de vida del artefacto, en lugar de considerar suficiente una comprobación de autorización exitosa en el momento de crear la exportación.
-
Distinguir el acceso denegado de un fixture de prueba negativa roto
Evitar que un agente trate cualquier error como prueba de que una prueba de control de acceso pasó. El método propuesto usa controles emparejados para determinar si la aplicación realmente llegó a la decisión de autorización prevista.
-
Probar la autorización a través de las relaciones con el recurso, no de los nombres de rol
Comprobar si quien realiza la llamada puede actuar sobre un objeto concreto a través de la relación que el producto realmente promete. Este método de laboratorio propuesto trata las etiquetas de rol como atributos de la fixture, no como el oráculo de la prueba.
-
Separar el servicio que actúa del usuario representado en las pruebas de delegación
Prueba una acción delegada haciendo visibles en el oráculo tanto la identidad del servicio que la ejecuta como la del usuario al que representa. Este método propuesto evita tratar la autenticación correcta del servicio como prueba suficiente de la autoridad del usuario.
-
Comprobar que las rutas anidadas de recursos vinculan los hijos con el padre indicado
Valida una relación que los agentes de programación pueden omitir al construir endpoints anidados: el hijo solicitado debe pertenecer al padre solicitado según el contrato de la aplicación. Es un diseño original de fixture.
-
Definir el oráculo de autorización para solicitudes por lotes con objetos de distintos propietarios
Permite detectar reglas de acceso ambiguas en operaciones por lotes antes de que un agente escriba pruebas que den por buena cualquier respuesta que devuelva la implementación. La propuesta se centra en lotes con objetos de distintos propietarios dentro de una misma solicitud.
-
Autorización en MCP 2026-07-28: comprobación del emisor y cambios en el registro de clientes
La revisión refuerza la validación del emisor en las respuestas de autorización, vincula las credenciales de registro almacenadas a su emisor y declara obsoleto Dynamic Client Registration. Los documentos de metadatos del ID de cliente ya se recomendaban en la revisión anterior.
-
Verificar que la aceptación de una invitación respete al destinatario previsto y al workspace
Prueba el vínculo entre una invitación, su destinatario previsto y el workspace de destino. La regresión propuesta se dirige a flujos de incorporación escritos por agentes que, de otro modo, solo comprueban la aceptación correcta.
Legible por máquina: JSON