Imagina una plataforma donde cada cliente entra para consultar contratos, pedidos o reportes. Todos tienen una cuenta válida, pero cada uno debería ver únicamente su información. La seguridad de ese producto depende de que esa separación se mantenga en cada consulta, descarga y modificación, incluso cuando cambia la interfaz.

La distinción es importante para quienes dirigen el negocio: comprobar la identidad de una persona no resuelve por sí solo qué puede hacer. Una pantalla que oculta un botón tampoco demuestra que la operación esté bloqueada. Es necesario revisar la regla que autoriza el acceso cuando la plataforma recibe la solicitud.

Escribe los permisos en lenguaje de negocio

La guía de autorización de OWASP diferencia autenticación y autorización, recomienda limitar privilegios y verificar permisos en cada solicitud. Esa base técnica se vuelve más fácil de evaluar cuando la empresa puede describir quién debe acceder a cada recurso y bajo qué condiciones.

Prepara una tabla simple con tipos de usuario y acciones. En vez de “cliente con rol estándar”, escribe “puede descargar sus contratos vigentes, pero no los de otra empresa”. Para soporte, especifica si puede leer documentos, corregir datos o actuar en nombre del cliente. Las excepciones necesitan explicación tanto como la regla general.

Piensa en cambios de contexto, no solo en cargos

Una misma persona puede participar en varias organizaciones o cambiar de responsabilidad. Define qué sucede al dejar una empresa, al ser suspendida o al perder una autorización temporal. Pregunta si una sesión ya abierta conserva permisos antiguos y cómo se comprueba que una baja se hizo efectiva.

Considera también las cuentas de proveedores. Un desarrollador que ayuda durante una entrega puede necesitar acceso por un período limitado. El área que lo solicita debería explicar para qué lo necesita y quién revisará su cierre. Esto evita que los accesos temporales se conviertan silenciosamente en parte permanente de la operación.

Incluye todos los lugares donde aparecen los datos

En una revisión autorizada, pide cubrir páginas, búsquedas, reportes, archivos descargables y conexiones entre sistemas. Es fácil pensar solo en la ficha principal de un cliente y olvidar el PDF que genera, la búsqueda global o el archivo exportado por un administrador. Cada salida necesita respetar la misma decisión de acceso.

  • ¿Quién puede generar un reporte y quién puede descargarlo después?
  • ¿Los enlaces compartidos tienen las restricciones que espera el negocio?
  • ¿Una búsqueda muestra nombres o documentos de otras organizaciones?
  • ¿Los procesos automáticos respetan los límites de la cuenta que los solicita?

Estas preguntas no afirman que tu plataforma tenga una falla. Sirven para establecer el alcance de la evaluación. El equipo debe responderlas con pruebas sobre cuentas y datos preparados para ese propósito, sin utilizar información privada de clientes como material de experimentación.

Pide evidencia que permita corregir

Si se encuentra un problema, el informe debe identificar la operación, el tipo de usuario, la información potencialmente afectada y la condición que permitió el acceso. El equipo de desarrollo necesita entender cuál es la regla incorrecta. Bloquear una sola pantalla podría dejar el mismo problema en una descarga o en una conexión móvil.

Después de corregir, conviene comprobar tanto el rechazo de accesos indebidos como el funcionamiento normal de las personas autorizadas. Una corrección que bloquea a todos puede cerrar una vía de exposición y, a la vez, paralizar el trabajo. Negocio debe ayudar a validar que la regla final corresponde a la forma real de operar.

Vuelve a revisar cuando cambie la organización

Si tu servicio reúne información de varias empresas, una evaluación enfocada puede aclarar este riesgo. En ethical hacking acordamos qué cuentas, funciones y límites probar. Cuando la causa está en reglas repetidas dentro del desarrollo, una auditoría de código permite examinar también cómo se implementaron.