Una plataforma permite que clientes consulten solicitudes o documentos propios. El menú puede mostrar solo sus registros, pero la protección necesita existir también cuando el sistema entrega cada dato. La pregunta de aceptación es sencilla: qué evidencia demuestra que una persona no puede recibir información que pertenece a otra. Esa revisión debe hacerse de forma defensiva, con cuentas y datos ficticios en un entorno autorizado. No requiere explorar sistemas ajenos ni utilizar información real. Necesita reglas claras de pertenencia y pruebas que cubran los distintos caminos por los que la aplicación consulta o descarga registros.
Define pertenencia y excepciones del negocio
Un registro puede pertenecer a una persona, a una empresa o a un equipo. Escribe quién puede consultarlo y bajo qué condiciones se comparte. Si un administrador de una organización ve información de sus miembros, ese alcance debe estar previsto y no depender de un permiso amplio accidental. Considera cambios de pertenencia, cuentas desactivadas y registros transferidos. La regla necesita responder con claridad a casos cotidianos. Sin esa definición, el equipo técnico puede implementar una separación diferente de la que ventas o soporte promete a los clientes durante la contratación del servicio.
Comprueba permisos en cada entrega de información
OWASP explica que referencias a objetos necesitan controles de autorización y que identificadores complejos no sustituyen esa comprobación. Para el negocio, eso significa que una dirección difícil de adivinar no basta para proteger un documento. El servidor debe decidir si la cuenta actual puede recibir el recurso solicitado. Incluye listas, búsquedas, archivos y vistas de detalle dentro del alcance. Un control correcto en la página principal puede coexistir con una descarga sin la misma verificación. Pide que la revisión cubra los recorridos reales y que el resultado quede documentado por perfil y tipo de recurso.
Usa una matriz de pruebas con datos ficticios
Prepara dos organizaciones de ensayo, varios roles y registros claramente diferenciados. El equipo autorizado comprueba acciones permitidas y respuestas cuando no corresponde acceso. No utilices clientes reales para demostrar separación. Revisa también exportaciones y enlaces compartidos, porque pueden entregar más información que la pantalla visible. El dueño del negocio puede validar la matriz y observar resultados sin ejecutar técnicas ofensivas. Lo importante es confirmar que las reglas se aplican de manera consistente y que una denegación no revela contenido del registro que se intentaba proteger.
Repite la revisión cuando cambien roles o recursos
Añadir una búsqueda global, un archivo adjunto o un nuevo rol puede introducir un camino de acceso distinto. Incluye pruebas de autorización dentro de esos cambios y conserva casos de referencia para detectar regresiones. Si se encuentra una falla, limita su exposición y coordina la corrección mediante el procedimiento del proyecto. Evita concluir que todo el sistema es seguro porque una sola pantalla pasó la revisión. La evidencia debe describir qué se comprobó, con qué cuentas y en qué versión. Esa precisión permite mantener la separación de información a medida que la aplicación crece.
DE LA LECTURA A LA ACCIÓN
Para aplicar hoy
- Define pertenencia y excepciones antes de diseñar permisos de registros.
- Verifica autorización en listas, detalles, archivos y exportaciones.
- Usa cuentas ficticias y repite las pruebas al cambiar roles o recorridos.
Fuentes y referencias
Documentación para profundizar. Los ejemplos de esta guía son didácticos.