El 45% de las muestras de código generadas por más de 100 modelos de IA no pasan pruebas de seguridad basadas en el OWASP Top 10, según el GenAI Code Security Report 2025 de Veracode, que evaluó 80 tareas de programación en Java, Python, C# y JavaScript.
No hace falta que el código lo escriba una IA para que esto te importe. El testing de seguridad lleva siendo parte del trabajo de QA desde antes de que existiera ese dato, pero ahora mismo se publica más código, más rápido, y con menos ojos humanos revisándolo línea por línea que en cualquier momento anterior.
La buena noticia es que no hace falta ser pentester para cubrir la parte más básica y más rentable de esa revisión. Este artículo explica qué es el OWASP Top 10, qué partes puede probar cualquier QA sin herramientas especializadas y dónde empieza el trabajo de un especialista en seguridad.
De las muestras de código generadas por IA fallan pruebas de seguridad del OWASP Top 10, probando más de 100 modelos distintos en 80 tareas de programación.
Veracode, GenAI Code Security Report 2025
Qué es el testing de seguridad (y qué no es)
El testing de seguridad comprueba que una aplicación no deja hacer, ver o cambiar algo que no debería, a alguien que no tiene permiso para hacerlo. No busca que la aplicación "no tenga bugs": busca específicamente los fallos que exponen datos, credenciales o accesos.
No es lo mismo que un pentest. Un pentest es una auditoría formal, con alcance definido por contrato, que hace alguien certificado usando herramientas de escaneo automatizado y técnicas más agresivas. El testing de seguridad que puede hacer un QA es manual, dirigido a los errores más comunes y no sustituye esa auditoría en sistemas con datos sensibles o pagos, pero detecta una parte importante de los problemas antes de que llegue a ese punto.
El OWASP Top 10, explicado sin jerga de seguridad
OWASP (Open Worldwide Application Security Project) es una fundación sin ánimo de lucro dedicada a la seguridad del software. Su Top 10 es una lista, actualizada cada pocos años, con las categorías de vulnerabilidades más comunes y graves en aplicaciones web. No es una ley ni una certificación, es una referencia práctica que usan equipos de desarrollo y QA para priorizar.
No todas las categorías son igual de fáciles de probar sin herramientas especializadas. Estas son las que un QA puede revisar con pruebas manuales:
| Categoría OWASP | Qué significa en la práctica | Cómo la prueba un QA sin herramientas especializadas |
|---|---|---|
| Control de acceso roto | Un usuario puede ver o modificar datos que no son suyos | Cambiar un identificador en la URL o en la petición con otra cuenta de prueba, sin haber iniciado sesión con ella |
| Fallos criptográficos | Datos sensibles viajan o se guardan sin cifrar | Revisar en las herramientas de desarrollador del navegador si la contraseña o el token viajan en texto plano |
| Inyección | Un campo de entrada ejecuta algo que no era texto, por ejemplo una instrucción a la base de datos | Probar un apóstrofe, comillas o símbolos poco comunes en campos de formulario y buscar un error de servidor que revele información interna |
| Diseño inseguro | La función existe, pero nadie pensó en el caso de abuso al diseñarla | Preguntarse "¿qué pasa si alguien hace esto 1.000 veces seguidas o con datos falsos?" antes de dar por buena una funcionalidad nueva |
| Configuración de seguridad incorrecta | Mensajes de error demasiado detallados, paneles de administración accesibles o cabeceras mal configuradas | Provocar un error a propósito (una URL inexistente, un dato inválido) y comprobar qué información devuelve la aplicación |
| Identificación y autenticación débiles | No hay límite de intentos de login, o las sesiones no caducan correctamente | Probar varios intentos de login fallidos seguidos y comprobar si la aplicación bloquea o ralentiza algo |
Basado en las categorías del OWASP Top 10 (owasp.org), simplificadas para pruebas manuales sin herramientas de seguridad especializadas.
En 17lab.pro, la compra de un curso se puede registrar por dos caminos distintos: cuando el usuario vuelve a la web tras pagar, y por un aviso directo de Stripe como red de seguridad si no vuelve. Si la tabla de compras no tuviera una restricción que impida dos filas iguales para el mismo usuario y curso, un fallo en cualquiera de los dos caminos podría duplicar el acceso en vez de fallar de forma visible. Lo revisamos nosotros mismos antes de publicarlo, no vino incluido por defecto.
Checklist manual de seguridad para aplicar hoy
No necesitas instalar nada ni escribir una línea de código para empezar. Estas pruebas se hacen usando la aplicación como cualquier usuario, con algo de curiosidad extra.
- Prueba el control de acceso con dos cuentas. Crea dos usuarios de prueba y comprueba que uno no puede ver ni editar los datos del otro cambiando un número o un identificador en la URL.
- Busca claves o tokens en el código fuente. Clic derecho, "ver código fuente", y busca palabras como "key", "secret" o "token" seguidas de un valor real, no de una referencia a una variable.
- Prueba campos de formulario con símbolos raros. Comillas, apóstrofes, signos de porcentaje. Si la aplicación responde con un error técnico detallado en vez de un mensaje genérico, apunta ese fallo.
- Revisa qué pasa tras cerrar sesión. Intenta volver a una página privada pulsando "atrás" en el navegador después de cerrar sesión.
- Comprueba si hay límite de intentos de login. Si puedes probar contraseñas indefinidamente sin bloqueo ni retraso, es una debilidad real, no una exageración.
Qué sí necesita un especialista
Esta checklist cubre lo más común y lo más barato de arreglar si se detecta a tiempo. No sustituye una auditoría completa en un sistema que maneja pagos o datos sensibles de muchos usuarios.
- Control de acceso entre dos cuentas de prueba
- Claves o tokens visibles en el código fuente
- Mensajes de error que revelan información interna
- Límite de intentos de login
- Sesión que no caduca al cerrar sesión
- Escaneo automatizado de vulnerabilidades conocidas
- Inyección avanzada contra la base de datos
- Análisis de dependencias y librerías de terceros
- Cumplimiento normativo (RGPD, PCI DSS en pagos)
- Ataques dirigidos a infraestructura y servidores
Nada de esta checklist convierte a un QA en especialista en ciberseguridad de un día para otro. Pero sí cambia lo que se publica: estos fallos son, con diferencia, los más repetidos y los más baratos de corregir antes de salir a producción, no después. Si te interesa profundizar en el resto de técnicas de prueba que no son de seguridad pero comparten la misma lógica (pensar en el caso que nadie probó), el artículo sobre técnicas para escribir casos de prueba es el siguiente paso natural.
Preguntas frecuentes
¿Necesito ser hacker o pentester para hacer testing de seguridad?
No. Un pentester busca activamente formas nuevas de romper un sistema y suele certificarse para ello. Un QA haciendo testing de seguridad básico comprueba una lista conocida de errores comunes (control de acceso, inyección, credenciales expuestas) con pruebas manuales repetibles. Son disciplinas relacionadas pero distintas, y la segunda no exige formación en ciberseguridad para empezar.
¿Qué es el OWASP Top 10?
Es una lista publicada por OWASP (Open Worldwide Application Security Project), una fundación sin ánimo de lucro dedicada a la seguridad del software, con las diez categorías de vulnerabilidades más comunes y graves en aplicaciones web. No es una norma legal ni una certificación, es una referencia práctica que usan equipos de desarrollo, QA y seguridad para priorizar qué revisar primero.
¿Qué diferencia hay entre testing de seguridad y un pentest?
El testing de seguridad que puede hacer un QA es manual, dirigido y cubre los fallos más frecuentes y más fáciles de detectar sin herramientas especializadas. Un pentest es una auditoría formal, con alcance definido por contrato, que usa herramientas de escaneo automatizado, prueba de forma más agresiva y exhaustiva, y la realiza alguien certificado para ello. El testing de QA no sustituye un pentest en un sistema que maneja datos sensibles o pagos, pero detecta buena parte de los errores antes de que llegue esa auditoría.
¿Cómo pruebo el control de acceso roto sin saber programar?
Crea dos cuentas de prueba en la aplicación. Inicia sesión con la primera, identifica una URL o una petición que muestre datos propios (un pedido, un perfil, una factura) y cambia el identificador por el de la segunda cuenta sin haber iniciado sesión con ella. Si puedes ver o modificar esos datos, es un fallo de control de acceso roto, la categoría más repetida del OWASP Top 10 y una de las más fáciles de probar sin conocimientos técnicos.
¿Las herramientas de IA hacen innecesario el testing de seguridad manual?
Al contrario, lo hacen más necesario. El informe GenAI Code Security Report 2025 de Veracode encontró que el 45% de las muestras de código generadas por más de 100 modelos de IA fallaban pruebas de seguridad basadas en el OWASP Top 10. La IA genera código más rápido de lo que se revisa, así que el paso de comprobar manualmente qué se publica pesa más, no menos.
¿Dónde puedo practicar testing de seguridad sin meterme en problemas legales?
Nunca pruebes técnicas de seguridad contra una web real sin permiso explícito, es ilegal aunque no causes daño. Para practicar de forma segura existen aplicaciones construidas a propósito con vulnerabilidades conocidas, como OWASP Juice Shop, un proyecto open source mantenido por la propia fundación OWASP pensado exactamente para aprender a encontrar estos fallos sin riesgo legal.
¿Quieres entrar al sector?
Aprende QA desde cero, con formación práctica y orientada al mercado español.