Respuesta.

Las pruebas manuales de acceso y roles permiten verificar que diferentes tipos de usuarios tengan el nivel de acceso correcto a la funcionalidad y los datos de la aplicación.

Historia de la pregunta

A medida que crece el número de usuarios y sus escenarios de trabajo, incluso las aplicaciones simples han adoptado un modelo de roles. Los errores en los permisos a menudo conducen a filtraciones de datos graves o a la restricción de operaciones comerciales. De aquí surge la necesidad de probar los roles manualmente con precisión.

Problema

Pasar por alto errores en la restricción de acceso a datos sensibles;
Configuración incorrecta de roles que permite a los usuarios realizar acciones no permitidas (por ejemplo, acceso a funciones administrativas para usuarios regulares);
Dificultad para verificar roles combinados o escenarios de acceso no estándar.

Solución

Documentar todos los roles existentes y las acciones correspondientes para cada rol;
Formar conjuntos de pruebas para cada rol, incluyendo intersecciones condicionales de roles;
Verificar el acceso no solo a las funciones, sino también a diferentes partes de los datos (CRUD);
Validar tanto el acceso directo (a través de la interfaz de usuario), como los intentos de acceso a través de enlaces directos o API.

Características clave:

Cobertura integral de escenarios: cada tipo de usuario debe ser probado en todos los roles y acciones posibles;
Pruebas de roles combinados y fronterizos: a menudo, los errores aparecen al superponerse los derechos de diferentes roles;
Verificación de la elusión de interfaces estándar: prueba de acceso directo a páginas/acciones a las que el usuario no tiene derechos oficialmente.

Preguntas capciosas.

¿Es suficiente probar solo los roles principales (por ejemplo, "Administrador" y "Usuario")?

No. Es precisamente en los roles intermedios, raramente utilizados y combinados donde más frecuentemente se ocultan defectos.

¿Es suficiente la restricción de la interfaz de usuario (botones y elementos ocultos) para la seguridad?

No. El control de la interfaz de usuario no protege de intentos de acceso directo mediante la dirección o a través de API, es necesario restringir los permisos a nivel de lógica del servidor.

¿Debo probar los derechos de acceso a través de diferentes canales de la aplicación (por ejemplo, tanto por web como por aplicación móvil)?

Definitivamente. A menudo, las diferencias en la implementación conducen a diferencias en el comportamiento y errores en la restricción de derechos.

Errores comunes y antipatrónes

Verificación solo de roles estándar
Enfoque exclusivamente en la interfaz externa, sin validación de restricciones del servidor
Desprecio por roles no estándar y combinados

Ejemplo de la vida real

Caso negativo

Solo se probó la interfaz de usuario y solo tres roles principales. Como resultado, los usuarios con una combinación no estándar de roles obtuvieron acceso a funciones administrativas a través de un enlace directo.

Ventajas:

Pruebas rápidas
Simplicidad del proceso

Desventajas:

Vulnerabilidad crítica detectada en producción
Violación de la seguridad y confianza de los usuarios

Caso positivo

Para las pruebas se crearon usuarios de prueba con diversas combinaciones de roles, se realizó una auditoría de API y acceso directo. Se encontraron y corrigieron errores antes del lanzamiento.