OWASP Top 10 explicado fácil — 10 ejemplos | Data Hogo

El término "OWASP Top 10" aparece en ofertas de trabajo, en code reviews de colegas, en artículos de seguridad. Pero si nunca te detuviste a entender qué significa exactamente, no estás solo. La mayoría del contenido disponible en español es o una traducción densa de la documentación oficial o un listado genérico sin contexto real.

Esta guía es diferente. El OWASP Top 10 explicado fácil — en español LATAM, con ejemplos del tipo de apps que tú construyes: side projects, MVPs, apps generadas con Cursor o ChatGPT.

Y la razón por la que este tema importa más hoy que hace cinco años: el 45% del código generado por IA tiene al menos una vulnerabilidad (Veracode, 2025). Las categorías que OWASP lleva documentando desde 2001 son exactamente las mismas que los modelos de IA siguen reproduciendo — porque aprendieron de décadas de código inseguro. Si usas Cursor o ChatGPT para escribir tu código, este post es para ti — y la guía sobre riesgos de seguridad del vibe coding cubre los 5 problemas más frecuentes con números concretos.

¿Qué es OWASP y por qué debería importarte si no eres experto en seguridad?

OWASP (Open Web Application Security Project) es una organización sin fines de lucro que desde 2001 publica guías y listas de referencia para la seguridad en aplicaciones web. El Top 10 es su publicación más conocida: una lista de las 10 categorías de vulnerabilidades web más comunes y peligrosas, actualizada cada 3-4 años con datos de miles de aplicaciones reales.

No es un estándar para empresas grandes. Es el estándar que usan los auditores cuando revisan tu app, las herramientas de análisis automático para categorizar hallazgos, y los equipos de seguridad para priorizar qué arreglar primero. Cuando alguien en un PR review escribe "esto huele a OWASP #3", saben exactamente a qué se refieren.

La edición actual es la de 2021 y sigue vigente como referencia oficial. Palo Alto Networks lanzó en enero de 2026 el framework SHIELD específicamente para seguridad en código generado por IA — y lo construyeron sobre el OWASP Top 10. Eso dice algo: el problema no está disminuyendo.

En diciembre de 2025, investigadores de Tenzai encontraron un promedio de 69 vulnerabilidades al analizar 5 herramientas populares de vibe coding. Casi todas esas vulnerabilidades caen en alguna de las 10 categorías de abajo.

Aquí están las 10, con su nombre oficial en inglés (así las vas a ver en el mundo real), una descripción simple, y los cambios respecto a la edición anterior:

Checklist rápido: ¿tu proyecto cumple?

Antes de leer cada categoría en detalle, haz un autodiagnóstico rápido. Si no puedes responder "sí" a alguna pregunta, esa sección te interesa especialmente:

• #1 Access Control — ¿Todos tus endpoints verifican que el usuario tiene permiso para acceder a ese recurso específico?
• #2 Crypto — ¿Las contraseñas se hashean con bcrypt o argon2, y tu app usa HTTPS en producción?
• #3 Injection — ¿Todas tus queries usan parámetros en lugar de concatenar strings?
• #4 Design — ¿Los permisos se validan en el servidor, no solo en el frontend?
• #5 Config — ¿CORS está restringido a tu dominio y el debug mode está desactivado en producción?
• #6 Components — ¿Corriste npm audit en el último mes?
• #7 Auth — ¿Tus JWT tienen fecha de expiración y los tokens de sesión están en cookies httpOnly?
• #8 Integrity — ¿Las decisiones de permisos se basan en datos del servidor, no del cliente?
• #9 Logging — ¿Registras intentos de login fallidos y errores 4xx en tus APIs?
• #10 SSRF — ¿Validas las URLs que tu servidor fetch para evitar acceso a IPs internas?

Si marcaste 7 o más, tu proyecto está mejor que la mayoría. Si marcaste menos de 5, calcula tu Security Score gratis para saber exactamente dónde empezar.

OWASP #1: Broken Access Control — cuando cualquiera puede ver lo que no debería

Broken Access Control llegó al primer lugar en 2021 (antes estaba en el #5) porque aparece en más del 94% de las aplicaciones evaluadas. Es la vulnerabilidad más común en aplicaciones web hoy.

"Control de acceso" son las reglas que determinan quién puede ver o hacer qué en tu app. Broken Access Control significa que esas reglas no existen o se pueden saltar fácilmente.

El escenario más frecuente para un desarrollador indie: tienes una app de e-commerce donde un usuario puede ver el detalle de su pedido en /api/pedidos/1234. Si cambias ese número por 1235, ¿ves el pedido de otro usuario? Si la respuesta es sí, tienes Broken Access Control. Esto se llama IDOR (Insecure Direct Object Reference) — acceder a recursos de otros usuarios simplemente cambiando un ID en la URL.

Las herramientas de IA reproducen este patrón constantemente. Cuando le pides a Cursor "crea el endpoint que devuelve los pedidos de un usuario", genera la funcionalidad — pero si no especificas "verifica que el pedido pertenece al usuario autenticado", lo omite. El endpoint funciona perfectamente para el caso feliz. El problema es que también funciona para todos los demás.

Este es un ejemplo simplificado del problema y su corrección:

// MAL: devuelve el pedido sin verificar a quién pertenece
app.get("/api/pedidos/:id", async (req, res) => {
  const pedido = await db.pedidos.findById(req.params.id);
  return res.json(pedido);
});
 
// BIEN: verificar que el pedido pertenece al usuario autenticado
app.get("/api/pedidos/:id", requireAuth, async (req, res) => {
  const pedido = await db.pedidos.findById(req.params.id);
  if (pedido.usuarioId !== req.user.id) return res.status(403).json({ error: "Prohibido" });
  return res.json(pedido);
});

En Data Hogo detectamos este patrón como "rutas sin verificación de autenticación" e "IDOR patterns" — y es el hallazgo más frecuente en repos con código generado por IA.

OWASP #2: Cryptographic Failures — tus datos sensibles viajan o se guardan sin protección

Cryptographic Failures (antes "Sensitive Data Exposure") señala la causa raíz: los datos de tus usuarios no tienen la protección criptográfica que deberían.

Los ejemplos más comunes: contraseñas en texto plano (sin bcrypt o argon2), app sobre HTTP en lugar de HTTPS, algoritmos de hash obsoletos como MD5 o SHA-1, y tokens de sesión sin cifrar en la base de datos.

Los modelos de IA generan esquemas con un campo password: string sin hashing automático — funcionalmente el modelo cumplió, pero el resultado queda inseguro. En Data Hogo detectamos uso de MD5/SHA-1, datos sensibles sin cifrar, y apps que responden sobre HTTP en producción.

OWASP #3: Injection — cuando tu app ejecuta código que no debería

Injection bajó del #1 al #3 en 2021, pero se expandió para cubrir SQL, NoSQL, y command injection.

La idea central: si tu buscador de usuarios está mal construido, alguien puede escribir comandos de base de datos en el campo de búsqueda — y tu app los ejecuta. La IA reproduce este patrón porque genera queries con concatenación de strings, el patrón más común en su training data. Los ORMs como Prisma previenen esto automáticamente, pero las queries SQL en crudo generadas por IA frecuentemente no.

-- MAL: concatenación de strings — el input del usuario entra directo a la query
SELECT * FROM usuarios WHERE nombre = '" + nombre + "';
-- Un atacante puede escribir: ' OR '1'='1 y obtener todos los registros
 
-- BIEN: query parametrizada — el input nunca se trata como código SQL
SELECT * FROM usuarios WHERE nombre = $1;
-- El valor de $1 se pasa por separado, nunca se interpreta como SQL

Data Hogo detecta queries sin parametrizar, uso de eval() y exec() con input del usuario, y patrones similares en Python, PHP y otros lenguajes.

¿No estás seguro si tus queries están bien escritas? Escanea tu repo gratis — Data Hogo detecta patrones de inyección en menos de un minuto. Si escribes JavaScript, la guía de 10 vulnerabilidades JavaScript comunes tiene el código inseguro y el fix para cada una. Si usas Supabase, también puedes verificar tus políticas RLS gratis.

OWASP #4: Insecure Design — el problema empieza antes de escribir el código

Insecure Design es nueva en 2021. No se trata de una línea de código incorrecta — se trata de decisiones de arquitectura que ningún parche puede arreglar después.

El ejemplo más frecuente: poner toda la lógica de autorización en el frontend. Ocultas el botón de admin para usuarios normales — pero si el endpoint de la API no verifica ese rol en el servidor, cualquiera con Postman puede llamarlo directamente.

Regla de oro: siempre valida permisos en el servidor, nunca solo en el cliente. El cliente es terreno del atacante. El servidor es tuyo. Las herramientas de IA generan validaciones en el frontend porque el contexto del prompt está en la UI — la validación del servidor hay que pedirla explícitamente.

OWASP #5: Security Misconfiguration — la configuración por defecto es casi siempre insegura

Security Misconfiguration ha estado en todas las ediciones del OWASP. La mayoría de frameworks y servicios vienen configurados para desarrollo — no para producción.

Los ejemplos que reconocerás:

• CORS abierto con Access-Control-Allow-Origin: * en producción
• Debug mode activo mostrando stack traces completos
• Error responses que revelan nombres de tablas o rutas internas

La IA reproduce misconfigurations porque fue entrenada con tutoriales — y los tutoriales siempre usan la configuración fácil de correr localmente. Puedes verificar tus security headers gratis para saber si tu configuración HTTP es correcta. El hallazgo más frecuente en Data Hogo es CORS abierto:

// MAL: cualquier origen puede hacer requests a tu API
app.use(cors({ origin: "*" }));
 
// BIEN: solo permite tu propio dominio
app.use(cors({ origin: "https://tuapp.com" }));

OWASP #6: Vulnerable and Outdated Components — las librerías que instalaste hace seis meses ya no son seguras

Vulnerable and Outdated Components subió del #9 al #6. Cada paquete que instalas con npm install es código de terceros con bugs — algunos son vulnerabilidades publicadas en bases de datos de CVE (Common Vulnerabilities and Exposures).

El escenario típico: usaste Cursor a mediados de 2025 para armar tu proyecto. Para principios de 2026, varios paquetes tienen CVEs conocidos — pero nunca corriste npm audit. El código se ve limpio. La vulnerabilidad está en node_modules. Las dependencias desactualizadas son uno de los tres problemas más frecuentes que cubrimos en la guía de seguridad para programadores principiantes.

Data Hogo corre npm audit y consulta la base de datos OSV en cada escaneo automáticamente.

OWASP #7: Identification and Authentication Failures — cuando cualquiera puede hacerse pasar por otro usuario

Identification and Authentication Failures (antes "Broken Authentication") cubre cuando tu sistema no verifica adecuadamente que quien hace una petición es quien dice ser.

Los ejemplos más comunes: JWT tokens sin fecha de expiración (un token robado es válido para siempre), tokens de sesión en localStorage en lugar de cookies httpOnly, y APIs que solo validan el token en el login pero no en cada petición.

Los modelos de IA reproducen este patrón regularmente. Cuando el prompt dice "implementa autenticación JWT", la expiración es un detalle de seguridad, no un requisito funcional. El código "funciona" — solo queda inseguro.

// MAL: token sin expiración — válido para siempre si alguien lo roba
const token = jwt.sign({ userId: user.id }, SECRET_KEY);
 
// BIEN: token con expiración corta + refresh token para sesiones largas
const token = jwt.sign({ userId: user.id }, SECRET_KEY, { expiresIn: "15m" });

Data Hogo detecta JWT sin expiración configurada, tokens guardados en localStorage, y endpoints que no verifican el token en cada request.

OWASP #8: Software and Data Integrity Failures — cuando confías en código o datos que no controlaste

Software and Data Integrity Failures es nueva en 2021 y cubre dos cosas:

Supply chain: paquetes de npm o PyPI alterados maliciosamente. El ataque "event-stream" de 2018 es el caso más conocido — un paquete legítimo con millones de descargas fue comprometido para robar criptomonedas.

Datos del cliente: cuando tu app toma decisiones de permisos basándose en datos que el usuario puede manipular — como una cookie role=admin que tu app usa directamente. Si el usuario puede cambiar ese valor, puede darse permisos que no tiene.

Regla práctica: nunca tomes decisiones de seguridad basándote en datos del cliente sin verificarlos en el servidor.

OWASP #9: Security Logging and Monitoring Failures — si alguien entra a tu app, ¿lo sabrías?

Security Logging and Monitoring Failures es la categoría más ignorada en proyectos indie. Si alguien está intentando fuerza bruta en tu login con cientos de intentos por hora, ¿lo sabrías? La mayoría de proyectos solos no tienen esta infraestructura.

Como mínimo, registra: intentos de login fallidos (con IP y timestamp), errores 4xx en tus APIs, y cambios a datos sensibles de usuarios (contraseña, correo, permisos). No necesitas un SIEM completo — Sentry o Logtail cubren el mínimo necesario.

OWASP #10: Server-Side Request Forgery (SSRF) — cuando tu servidor hace requests que no debería

SSRF es nueva en 2021. Tu app tiene un previsualizador de links o importador de imágenes donde el usuario ingresa una URL. Tu servidor hace fetch() hacia ella. Si no validas qué URLs acepta, un atacante puede ingresar http://169.254.169.254/latest/meta-data/ — la URL que devuelve credenciales de AWS en instancias EC2.

La IA genera fetch(urlDelUsuario) porque el prompt decía "obtén el contenido de esa URL". La validación de qué URLs son permitidas hay que pedirla explícitamente. Corrección: valida que el hostname no apunte a rangos de IP privados (10.x.x.x, 172.16.x.x, 192.168.x.x, 169.254.x.x).

Data Hogo detecta patrones de fetch() con URLs controladas por el usuario sin validación de origen.

¿Cuáles de estas vulnerabilidades tiene tu proyecto ahora mismo?

De los repos que hemos escaneado en Data Hogo, las cuatro categorías más frecuentes son Broken Access Control (#1), Injection (#3), Security Misconfiguration (#5), y Vulnerable Components (#6) — exactamente las que los modelos de IA reproducen más porque están sobrerepresentadas en su training data.

Una revisión manual de las 10 categorías toma horas. En la práctica, no lo vas a hacer — tienes features que enviar. Para eso existe un scanner automatizado: conectas tu GitHub, lanzas el escaneo, y en menos de 60 segundos tienes tu security score con cada hallazgo categorizado por OWASP, explicado en español.

El plan gratuito incluye 3 escaneos al mes, sin tarjeta de crédito.

Escanea tu repo gratis — resultados en menos de 60 segundos →

Preguntas frecuentes

¿Qué es OWASP Top 10 y para qué sirve?

OWASP es una organización sin fines de lucro que desde 2001 publica guías de seguridad web. El Top 10 son las 10 categorías de vulnerabilidades más comunes en aplicaciones web reales. La edición actual (2021) sigue siendo el estándar que usan auditores, herramientas de análisis y equipos de seguridad para categorizar hallazgos.

¿Cuál es la vulnerabilidad más peligrosa del OWASP Top 10?

Broken Access Control (#1) es la más común — aparece en más del 94% de las apps evaluadas. Injection (#3) puede ser la más destructiva porque permite acceso total a la base de datos. Las dos deben ser prioridad.

¿Aplica a proyectos pequeños o solo a empresas grandes?

Aplica a cualquier aplicación web. Los proyectos pequeños son blancos más fáciles porque no tienen equipos de seguridad dedicados. Si tu codebase fue generado mayoritariamente por IA, las probabilidades de tener estas vulnerabilidades son aún mayores.

¿Cómo sé si mi aplicación tiene alguna de estas vulnerabilidades?

La forma más rápida es escanear tu repo con una herramienta automatizada. Data Hogo detecta las categorías más comunes en menos de 60 segundos. El plan gratuito incluye 3 escaneos al mes.

¿Cuál es la diferencia entre la edición 2021 y la 2017?

La edición 2021 agregó tres categorías nuevas: Insecure Design (#4), Software and Data Integrity Failures (#8) y SSRF (#10). También renombró varias para reflejar la causa raíz — por ejemplo, "Sensitive Data Exposure" pasó a "Cryptographic Failures" porque el problema es la falta de cifrado, no la exposición en sí.

¿Cada cuánto se actualiza?

Aproximadamente cada 3-4 años. La edición 2021 sigue vigente en 2026. La próxima se espera que incluya explícitamente los patrones de vulnerabilidades en código generado por IA.

Ahora ya sabes qué significa cada categoría del OWASP Top 10 y cómo puede aparecer en el tipo de proyectos que tú construyes. El siguiente paso es ver cuáles tiene tu código específicamente.

Escanea tu repo gratis → — resultados en menos de 60 segundos, hallazgos explicados en español.