Validar · Seguridad
Auditoría de seguridad web
La diferencia entre una prueba de seguridad y una intrusión no es la técnica. Es la autorización, y se pone por escrito antes.
Respuesta directa
Una prueba de seguridad es legítima cuando existe autorización escrita, con alcance delimitado, ventana acordada y procedimiento de contacto si algo sale mal. Sin esos cuatro elementos, la misma acción técnica deja de ser una prueba.
KATA no ejecuta pruebas intrusivas sin esa autorización escrita, y no ofrece «hacking ético» como servicio abierto. Esta página explica qué son estas pruebas y cómo se piden bien; no las oferta.
Dos tipos de comprobación, muy distintos
| Aspecto | Pasiva | Activa |
|---|---|---|
| Qué hace | Observa: revisa configuración, cabeceras, dependencias y código. | Interactúa: intenta provocar el fallo para comprobar si existe. |
| Riesgo para el sistema | Prácticamente nulo. | Real: puede degradar, bloquear o alterar datos. |
| Autorización | Conviene acordarla. | Imprescindible y por escrito. |
| Qué demuestra | Que un control está o no está configurado. | Que un control funciona o no funciona de verdad. |
Los marcos que sí existen
Hay dos referencias públicas que evitan improvisar y que permiten que el resultado sea comparable y reproducible:
- OWASP ASVS, un estándar de verificación con requisitos organizados por niveles, que sirve para decir qué se ha verificado y con qué profundidad.
- OWASP WSTG, la guía de pruebas, en versión estable 4.2, que organiza las pruebas en categorías con identificadores estandarizados. Se publica bajo licencia CC BY-SA 4.0.
Una precisión sobre la autorización
Conviene ser exacto: la página del WSTG que hemos consultado no incluye una declaración explícita que exija autorización previa. La guía describe cómo probar, no bajo qué condiciones legales hacerlo.
La exigencia de autorización escrita es, por tanto, criterio operativo de KATA y obligación legal en la mayoría de jurisdicciones, no una cita de OWASP. Lo decimos así porque atribuir a una fuente algo que no dice es exactamente el error que este método intenta evitar.
Cómo se pide bien una prueba de seguridad
1 · Alcance por escrito
Qué sistemas entran, cuáles quedan fuera y qué técnicas se autorizan. Lo que no está escrito, no está autorizado.
2 · Entorno
Siempre que sea posible, en pruebas y no en producción. Si tiene que ser producción, con ventana acordada y responsable localizable.
3 · Datos
Sin datos personales reales. Si es inevitable, con base jurídica y contrato.
4 · Contacto de emergencia
Alguien a quien avisar en minutos si algo se degrada.
5 · Entregable
Hallazgos con severidad, evidencia reproducible, corrección propuesta y prueba de regresión.
Lo que no se debe aceptar de un proveedor
- Que empiece sin alcance escrito.
- Que entregue una lista de vulnerabilidades sin evidencia reproducible.
- Que declare un sistema «seguro»: no existe tal estado, solo controles verificados en una fecha.
- Que use el término «hacking ético» como reclamo comercial sin poder mostrar el alcance autorizado de cada trabajo.
Preguntas frecuentes
¿KATA hace pruebas de intrusión?
KATA no ejecuta pruebas intrusivas sin autorización escrita de alcance. Lo que sí hacemos de forma habitual es la parte pasiva: revisión de configuración, cabeceras, dependencias, superficies expuestas y código. Si un proyecto necesita pruebas activas, se acuerda su alcance por escrito antes de tocar nada.
¿Podéis decirme si mi web es segura?
No, y nadie puede. Se puede decir qué controles se han verificado, con qué método y en qué fecha. «Seguro» no es un estado comprobable: es una afirmación sin fecha de caducidad, y por eso no la hacemos.
¿Qué puedo hacer antes de contratar nada?
Lo que más rinde no suele ser una prueba de intrusión: es actualizar dependencias, activar verificación en dos pasos, comprobar que existe una copia restaurable y revisar quién tiene acceso administrativo. Es menos vistoso y evita más incidentes.
Fuentes primarias
Cada afirmacion sensible de esta pagina se apoya en una de estas fuentes, consultada en la fecha indicada. Las listas de bots, capacidades y borradores cambian: se reverifican en cada revision.
| Entidad | Documento | Consultada |
|---|---|---|
| OWASP | Web Security Testing Guide (WSTG), versión estable 4.2 | 2026-08-30 |
| OWASP | Application Security Verification Standard (ASVS) | 2026-08-30 |
La exigencia de autorización escrita es criterio operativo de KATA y obligación legal habitual, NO una cita de OWASP: la página consultada del WSTG no la declara.
Siguiente decisión
Continúa con una pregunta concreta
SEO técnico antes de indexar
Una lectura relacionada dentro del mismo método.
SEO técnico antes de indexar →
Auditoría web integral
Qué podemos abordar contigo y cómo delimitamos el trabajo.
Auditoría web integral →
Ilustraciones conceptuales; no son fotografías de clientes.