Iniciar sesión demuestra quién entra a una aplicación; no demuestra qué información puede consultar. En una plataforma mexicana que atiende a varias empresas o clientes, cada pedido, factura o expediente necesita una comprobación de permisos propia. Una cuenta válida no debería poder acceder a datos ajenos por cambiar una referencia, utilizar una función de exportación o llamar directamente a una API.
Esta guía explica cómo evaluar esa separación con cuentas y datos de prueba autorizados. No describe una vulnerabilidad nueva en un producto específico ni invita a probar sistemas sin permiso. Su propósito es ayudar a responsables de negocio, desarrollo y seguridad a formular una pregunta verificable: ¿el servidor impide que un cliente vea o modifique información de otro en todos los caminos relevantes?
Identificar a la persona y autorizar cada acción
La autenticación identifica a un usuario o a un servicio. La autorización determina qué operaciones puede realizar sobre recursos concretos. Ambas funciones se complementan. Una plataforma puede tener contraseñas robustas y autenticación multifactor, pero conservar errores en la decisión que relaciona cada registro con su propietario, organización o rol autorizado.
OWASP incluye la autorización a nivel de objeto entre los riesgos principales de las API. La recomendación práctica es verificar permisos cuando una solicitud accede a un recurso mediante un identificador. Ese identificador puede estar en una ruta, un parámetro o el cuerpo de la petición. Su apariencia no cambia el requisito: el servidor debe comprobar que la operación corresponde al usuario y al contexto autorizado.
Los identificadores difíciles de adivinar reducen ciertas oportunidades de descubrimiento, pero no reemplazan el control. Un usuario puede obtener referencias a través de un enlace compartido, un registro o una integración. Si conocer la referencia basta para acceder, la separación depende de un secreto accidental en lugar de una decisión de autorización explícita.
También conviene separar la pertenencia a una empresa del rol dentro de ella. Un operador y un administrador pueden compartir organización sin tener las mismas facultades. La prueba necesita contemplar separación entre clientes y separación entre funciones. Revisar solamente que dos empresas no se mezclen puede dejar abiertas operaciones administrativas dentro de un mismo cliente.
Construir una matriz que el negocio pueda aprobar
Antes de enviar solicitudes de prueba, el propietario del producto debe definir qué comportamientos son correctos. Las reglas pueden depender de organización, propietario del registro, rol, estado del proceso y delegaciones válidas. Si esa decisión no existe, un equipo técnico podría probar contra supuestos que no corresponden a la operación real.
La matriz debe contener acciones, no solamente pantallas. Consultar, modificar, exportar, borrar, aprobar y compartir tienen consecuencias diferentes. Una cuenta puede estar autorizada para leer un pedido y carecer de permiso para cambiar su destinatario. El alcance de una prueba debe indicar esos matices, junto con los entornos, horarios, límites y contactos responsables.
| Escenario autorizado de prueba | Resultado esperado | Evidencia que conviene guardar |
|---|---|---|
| Cliente A consulta un pedido propio | Acceso permitido al dato necesario | Solicitud y respuesta depuradas |
| Cliente A solicita un pedido de B | Acceso rechazado sin datos de B | Respuesta y registro del control |
| Operador intenta aprobar una operación | Acción rechazada si no tiene ese rol | Estado antes y después |
| Usuario exporta un listado | Solo filas y campos autorizados | Archivo sintético y filtros aplicados |
| Integración actúa en nombre de un cliente | Permisos limitados a ese contexto | Identidad del servicio y trazabilidad |
Las cuentas deben ser creadas para la evaluación, con datos ficticios claramente diferenciados. Es preferible representar dos clientes y varios roles de forma controlada a utilizar expedientes reales. Si se requiere una validación en producción, su autorización debe incluir protección de datos, límites de impacto y procedimiento de interrupción. El entorno real no debe convertirse en una excusa para pruebas abiertas.
Revisar las rutas que una pantalla no muestra
La interfaz puede ocultar botones o filtrar filas, pero el servidor sigue siendo responsable de los permisos. Una persona con una cuenta legítima puede emitir una solicitud distinta a la generada por la pantalla. La evaluación debe revisar la API que realmente procesa la operación y no limitarse a observar el diseño visual.
Los listados, búsquedas y exportaciones merecen atención propia. Un endpoint de detalle podría aplicar controles correctos mientras un reporte mezcla registros. También existen tareas en segundo plano, notificaciones, descargas de adjuntos y enlaces temporales. El inventario de funciones ayuda a detectar estos caminos y a relacionarlos con la misma política de acceso.
Las propiedades del objeto requieren otra decisión. Aunque una persona pueda ver su pedido, no necesariamente debe recibir campos internos, notas de otros usuarios o indicadores de riesgo. OWASP diferencia los problemas de autorización sobre objetos y sobre propiedades. Devolver el objeto completo para que la interfaz oculte campos sensibles puede exponer información que nunca debía salir del servidor.
La modificación de campos exige controles equivalentes. El cliente de una aplicación no debería poder cambiar su rol, la organización propietaria o un estado reservado simplemente añadiendo una propiedad a la solicitud. La evaluación debe comprobar que el servidor acepta únicamente los campos permitidos para esa operación y que las transiciones de negocio requieren autorización específica.
Incluir integraciones y cambios de contexto
Una plataforma con varias organizaciones puede permitir que una persona trabaje para más de una. El cambio de contexto necesita reglas claras y verificación en cada operación relevante. No basta con guardar la selección en una pantalla si una solicitud puede indicar otro cliente sin comprobar la relación del usuario con él.
Las cuentas de integración también deben tener permisos definidos. Un conector que atiende a varios clientes puede concentrar facultades amplias. La arquitectura debe explicar cómo separa cada operación y qué controles impiden que un error de configuración dirija datos al destino equivocado. Las credenciales del servicio no deben tratarse como autorización ilimitada para cualquier recurso del sistema.
Los enlaces de descarga y las tareas diferidas necesitan conservar el contexto adecuado. Si una exportación se genera minutos después, debe producir el conjunto autorizado y entregarlo al destinatario correcto. Si cambian permisos durante ese intervalo, el producto debe tener una regla explícita sobre la ejecución y la entrega. Estas decisiones requieren análisis del proceso, no una respuesta universal.
Obtener evidencia sin ampliar innecesariamente el impacto
Una evaluación de Ethical Hacking puede validar estos controles mediante un alcance acordado y casos representativos. El valor de la prueba está en mostrar una operación concreta, su resultado y la condición que permite o impide el acceso. No debe basarse en recopilar grandes cantidades de datos para demostrar una falla que puede verificarse con registros sintéticos.
Si se encuentra acceso indebido, conviene detener la ampliación del caso y comunicarlo por el canal acordado. La evidencia puede preservar identificadores de prueba, respuestas depuradas y secuencia mínima de acciones. Se deben evitar secretos o datos personales innecesarios en informes, capturas y herramientas de colaboración. La protección de la evidencia forma parte de la evaluación.
La corrección debe dirigirse a la decisión del servidor. Cambiar el botón, ocultar un identificador o bloquear una única ruta puede dejar otros caminos abiertos. Desarrollo necesita identificar la regla común, revisar dónde se aplica y añadir verificaciones de regresión sobre operaciones permitidas y denegadas. Una prueba positiva asegura que el cliente legítimo sigue trabajando; una negativa verifica que el acceso indebido se rechaza.
El código de estado de una respuesta no basta para determinar el resultado. Una petición rechazada puede dejar una modificación realizada antes del fallo. Una respuesta aparentemente vacía puede generar una descarga posterior. La validación debe comprobar efectos y registros, además del mensaje mostrado, siempre dentro del alcance aprobado.
Pedidos separados en una plataforma logística
Imaginemos un portal logístico en Monterrey que permite consultar pedidos y descargar comprobantes. Es un caso hipotético. Las cuentas de dos empresas reciben datos ficticios distintos. La pantalla muestra únicamente los pedidos correctos, pero el equipo aún necesita comprobar qué ocurre al solicitar directamente un comprobante del otro cliente o al ejecutar una exportación.
La prueba incluye lectura, descarga y reporte. Si el detalle rechaza el acceso y el reporte mezcla filas, la separación todavía es incompleta. El hallazgo se describe con el camino concreto y los datos sintéticos utilizados. El equipo corrige la autorización del reporte, revisa funciones semejantes y repite tanto las solicitudes legítimas como las que deben rechazarse.
Este ejemplo muestra por qué un Análisis de Vulnerabilidades automatizado necesita complementarse con evaluación de lógica y contexto. Un escaneo puede identificar componentes o configuraciones, pero no conoce por sí solo quién debería aprobar un pedido o qué campos puede ver cada cliente. Las reglas de negocio necesitan participación del propietario del producto.
Mantener la separación después del lanzamiento
Las autorizaciones deben formar parte del diseño de cada función nueva. Una especificación de exportación debe definir qué registros y campos incluye para cada rol. Un cambio de integración debe explicar su contexto. Una función administrativa debe indicar quién puede utilizarla y qué ocurre si se intenta fuera de ese rol. Así se evita tratar la revisión de permisos como actividad tardía.
El equipo puede mantener un conjunto de pruebas con clientes sintéticos que se ejecute después de cambios relevantes. Debe cubrir caminos representativos sin convertirse en una colección inmanejable de casos duplicados. Cuando aparece un fallo, se añade un caso que reproduzca la regla y se revisan funciones equivalentes. La cobertura debe evolucionar con el producto.
La formación en Insylux Academy puede ayudar a desarrollo, producto y soporte a reconocer la diferencia entre iniciar sesión y autorizar una operación. Los ejercicios deberían utilizar el modelo real de roles y clientes, con entornos controlados. Explicar un catálogo de riesgos sin conectarlo con las decisiones del producto deja una brecha entre conocimiento y aplicación.
Los registros ayudan a investigar intentos y errores, pero no reemplazan la prevención. Conviene conservar contexto suficiente para relacionar usuario, operación y recurso sin registrar secretos. Las alertas deben tener propietario y ruta de atención. Una lista de accesos rechazados que nadie revisa puede producir volumen sin mejorar la capacidad de detectar problemas.
Qué pedir en la próxima revisión del producto
Empiece por una función que maneje información relevante para varios clientes. Defina dos organizaciones sintéticas, sus roles y las acciones permitidas. Inventaríe detalle, búsqueda, exportación y descarga. Compruebe resultados y efectos, corrija la regla del servidor y deje pruebas de regresión. Después amplíe a integraciones y funciones administrativas según el riesgo.
La dirección puede pedir tres evidencias comprensibles: una matriz aprobada, resultados de operaciones permitidas y denegadas, y confirmación de correcciones verificadas. El número de solicitudes ejecutadas no demuestra por sí solo que la separación sea adecuada. La conclusión debe expresar qué funciones se probaron, en qué versión y qué límites permanecen.
Preguntas frecuentes
¿La autenticación multifactor evita que un cliente vea datos de otro?
Ayuda a proteger la entrada a la cuenta, pero no decide los permisos sobre cada objeto o acción. Una cuenta auténtica sigue necesitando autorización correcta en el servidor para acceder a información de un cliente determinado.
¿Usar identificadores aleatorios resuelve el problema?
No. Puede dificultar adivinar referencias, pero conocer una referencia no debe otorgar permiso. El servidor debe comprobar la relación autorizada entre usuario, operación y recurso, independientemente del formato del identificador.
¿Podemos probar con clientes reales sin avisar?
Una evaluación necesita autorización y alcance. Lo recomendable es usar cuentas y datos sintéticos. Cualquier validación en producción debe acordarse con responsables y contemplar protección de información, límites y una ruta para detener la actividad.
Fuentes primarias de seguridad de API
Esta guía utiliza OWASP API1: autorización a nivel de objeto, OWASP API3: autorización a nivel de propiedades y OWASP API5: autorización a nivel de función. Son referencias generales; no constituyen evidencia de una falla en una empresa o plataforma mexicana concreta.
