Cuando sale en las noticias una brecha de seguridad, imaginamos un hacker de película rompiendo criptografía militar. La realidad de las auditorías es mucho menos glamurosa: casi nunca es un zero-day. Son los mismos diez errores, una y otra vez, en aplicaciones de todo tamaño.

Esos diez errores tienen nombre: el OWASP Top 10, el ranking de riesgos más críticos en aplicaciones web que publica la Open Worldwide Application Security Project — una comunidad sin ánimo de lucro que es la referencia mundial en seguridad aplicada. No es teoría académica: se construye analizando cientos de miles de aplicaciones reales. Si haces una sola cosa por la seguridad de tu aplicación este año, que sea entender esta lista.

Los Diez, en Una Imagen

La lista completa (edición vigente):

1. A01 — Control de acceso roto. El usuario puede actuar fuera de sus permisos: ver datos de otros, ejecutar acciones de administrador, manipular IDs en las URLs.
2. A02 — Fallos criptográficos. Datos sensibles expuestos: contraseñas con MD5, tráfico sin cifrar, tarjetas en logs.
3. A03 — Inyección. Datos del usuario interpretados como comandos: SQL, LDAP, sistema operativo. La clásica ' OR 1=1 --.
4. A04 — Diseño inseguro. El fallo está en la idea, no en el código: flujos de negocio que permiten abuso (p. ej. recuperación de contraseña que revela si un email existe).
5. A05 — Configuración incorrecta. Debug activado en producción, credenciales por defecto, cabeceras de seguridad ausentes, buckets públicos.
6. A06 — Componentes vulnerables y desactualizados. Librerías con CVEs conocidos que nadie actualiza.
7. A07 — Fallos de autenticación. Contraseñas débiles permitidas, sin 2FA, sesiones que no caducan, fuerza bruta sin límite.
8. A08 — Fallos de integridad de datos y software. Actualizaciones sin verificar, pipelines de CI/CD sin proteger, deserialización insegura.
9. A09 — Fallos de registro y monitorización. El ataque no aparece en ningún log: te enteras por el cliente, o por la prensa.
10. A10 — SSRF. El servidor hace peticiones a donde le dice el atacante: metadatos de la nube, red interna, servicios que no deberían ser alcanzables.

Los Tres Que Encontramos en Casi Toda Auditoría

De los diez, hay tres que aparecen con una frecuencia que debería avergonzarnos como industria.

1. Control de acceso roto (IDOR)

El patrón: la aplicación comprueba quién eres pero no qué puedes tocar:

// VULNERABLE: cualquier usuario autenticado ve cualquier pedido
public function show(int $id): Response
{
    $pedido = $this->pedidos->find($id);
    return $this->json($pedido);
}

Cambia /pedidos/1234 por /pedidos/1235 en la URL y estás viendo el pedido de otro cliente. Es la vulnerabilidad número uno del ranking y la más fácil de explotar: no hace falta más herramienta que el navegador.

// CORRECTO: el recurso se valida contra el propietario
public function show(int $id): Response
{
    $pedido = $this->pedidos->find($id);
    if (!$pedido || $pedido->clienteId() !== $this->getUser()->id()) {
        throw $this->createAccessDeniedException();
    }
    return $this->json($pedido);
}

2. Inyección SQL

// VULNERABLE: concatenar entrada del usuario en la consulta
$usuarios = $db->query("SELECT * FROM usuarios WHERE email = '$email'");

Con $email = "' OR '1'='1" la consulta devuelve toda la tabla. La solución existe desde hace décadas — consultas parametrizadas — y aun así sigue en el top 3:

// CORRECTO: parámetros, nunca concatenación
$usuarios = $db->executeQuery(
    'SELECT * FROM usuarios WHERE email = :email',
    ['email' => $email],
);

3. Configuración incorrecta

El modo debug de Symfony o Laravel mostrando stack traces con rutas y variables de entorno en producción. El adminer olvidado en una URL pública. El .env servido por el servidor web. No requiere habilidad alguna: requiere un buscador.

Cómo Empezar (en Orden de Impacto)

1. Audita tus dependencias. composer audit en PHP, npm audit en JS. Cinco minutos, resultado inmediato. Ponlo en el CI y que falle con CVEs críticos.
2. Tests de autorización. Para cada endpoint con datos de usuario, un test que intenta acceder con otro usuario. El IDOR se caza en tests, no en revisión manual.
3. Revisa la configuración de producción. Debug off, errores genéricos, cabeceras de seguridad (CSP, X-Frame-Options, HSTS), nada de ficheros sensibles servidos.
4. Parametriza y valida. Todo dato del usuario es hostil: consultas parametrizadas en la base de datos, validación en la entrada, escape en la salida.
5. Logging de seguridad. Login fallidos, accesos denegados, cambios de permisos. Si no lo registras, no lo detectas.
6. Auditoría profesional periódica. Los scanners automáticos encuentran lo conocido; un auditor encuentra lo específico de tu lógica de negocio (ahí vive el A04, diseño inseguro).

Errores Comunes

1. Tratar el Top 10 como checklist anual. Se pasa la auditoría, se archiva el informe, se mergean 400 PRs sin mirar seguridad. La seguridad es proceso, no evento.
2. El WAF como sustituto. Un WAF mitiga; no arregla el código vulnerable que hay detrás. Es el cinturón, no el airbag… y tampoco es el cinturón.
3. Solo scanners automáticos. Ningún scanner entiende que «descargar la factura de otro cliente» es un fallo en tu negocio. Las vulnerabilidades de lógica requieren humanos.
4. Ignorar las dependencias transitivas. Tu código usa 30 librerías; esas librerías usan 300. El CVE suele estar en el nivel que no ves.
5. Seguridad = el equipo de backend. La mayoría de estos fallos nacen en decisiones de producto y diseño (A04). La seguridad es de todo el equipo o no es.

En Resumen

El OWASP Top 10 no es una lista para expertos en seguridad: es el mínimo que todo equipo de desarrollo debería tener interiorizado. La mayoría de las brechas reales explotan errores conocidos, con técnicas documentadas y defensas maduras. La diferencia entre las aplicaciones que los sufren y las que no es un hábito: auditar dependencias, testear autorizaciones, revisar configuraciones y mirar los logs.

Si hace tiempo que nadie mira tu aplicación con ojos de atacante, es literalmente nuestro trabajo: auditorías de seguridad con informe priorizado por riesgo y plan de remediación. Solicita una auditoría →

Sigue leyendo: La pirámide de testing: guía práctica para suites que no se desmoronan — porque los tests de autorización son tu primera línea de defensa.