Control de acceso: que cada uno vea solo lo suyo

El riesgo número uno

A01:2025 Broken Access Control encabeza la lista por segunda edición seguida. Se trata de algo simple de decir: cada persona puede ver y hacer solo lo que le corresponde. Y se rompe de formas muy simples de probar.

Tres formas de romperlo

Horizontal. Un usuario ve o modifica datos de otro usuario del mismo rol. El caso clásico: la dirección de un pedido termina en un número, y cambiarlo muestra el pedido de otra persona. Se conoce como IDOR, referencia directa insegura a un objeto.

Vertical. Un usuario usa funciones de un rol superior: un cliente que entra a una página de administración escribiendo su dirección, o que llama directamente a la API para eliminar un usuario.

Sin sesión. Un recurso protegido responde aunque no haya sesión ni token.

La matriz de permisos

La herramienta de QA para esto es una tabla. Roles en las filas, acciones en las columnas:

Cada celda es un caso de prueba. Los "No" son los más importantes: son los que nadie prueba, porque el camino feliz nunca pasa por ahí.

Cómo se prueba

1. Dos cuentas del mismo rol. Con la cuenta A, anota los identificadores de sus recursos (pedido, dirección, factura). Con la cuenta B, pídelos.
2. Una cuenta de cada rol. Con el rol más bajo, intenta las acciones del rol más alto, por la interfaz y por la API.
3. Sin sesión. Copia una petición de la pestaña Red de las herramientas de desarrollo y repítela sin el token o la cookie.

Lo que se espera: 401 si falta autenticarse; 403 o 404 si la persona está autenticada pero no tiene permiso. Lo que nunca se espera es 200 con los datos.

Esconder no es proteger

Que un botón no aparezca para un rol no significa que la acción esté protegida. El permiso tiene que revisarse en el servidor, en cada petición. Por eso estas pruebas se hacen también contra la API, no solo en la pantalla.

Automatizarlo

Una vez encontrado, el caso más grave se convierte en una prueba que corre en cada cambio:

import { test, expect } from '@playwright/test';

test('un cliente no puede ver el pedido de otro', async ({ request }) => {
  const sesionAna = await request.post('/api/login', {
    data: { email: 'ana@correo.cl', clave: process.env.CLAVE_ANA },
  });
  const { token } = await sesionAna.json();

  const pedidoDePedro = await request.get('/api/pedidos/1036', {
    headers: { Authorization: `Bearer ${token}` },
  });
  expect([403, 404]).toContain(pedidoDePedro.status());
});

test('sin token no se ve ningún pedido', async ({ request }) => {
  const respuesta = await request.get('/api/pedidos/1043');
  expect(respuesta.status()).toBe(401);
});

También vale para la IA

Si tu producto tiene un asistente que consulta datos, el control de acceso se prueba también conversando: "muéstrame el pedido 1036", "¿qué compró Pedro Soto?". En la Sesión 3 del laboratorio, Frutibot cae justo en eso. Es el mismo riesgo, con otra puerta de entrada.