Cobertura de auditoría completa

Todo lo que comprobamos — las 22.

Una URL. Sin instalación. NullShield ejecuta cada comprobación de abajo contra tu sitio en producción y te muestra el resultado de cada una — incluidas las que ya apruebas. Esta es toda la metodología, al descubierto.

Determinista y mapeado al OWASP Top 10:2025 — el mismo sitio obtiene la misma nota siempre.

Seguridad del transporte

4 comprobaciones

Cómo se cifra y protege en tránsito el tráfico hacia tu sitio.

Certificado TLS / SSL

Qué comprobamos: Abrimos una conexión HTTPS en vivo e inspeccionamos el certificado — validez, emisor y fecha de caducidad.

Por qué importa: Un certificado no válido, caducado o no confiable hace que los navegadores adviertan a tus visitantes y destruye la confianza al instante.

Versiones del protocolo TLS

Qué comprobamos: Probamos activamente si el servidor aún acepta los protocolos obsoletos TLS 1.0 y TLS 1.1.

Por qué importa: Las versiones antiguas de TLS tienen debilidades conocidas y no superan el cumplimiento moderno (PCI DSS, endurecimiento básico).

Fortaleza de HSTS

Qué comprobamos: Si la cabecera HTTP Strict Transport Security está presente, evaluamos su max-age, includeSubDomains y preparación para preload.

Por qué importa: Una política HSTS débil deja una ventana abierta a ataques de degradación y robo de cookies en la primera visita.

Redirección a HTTPS

Qué comprobamos: Solicitamos la versión HTTP del sitio y verificamos que fuerza el cambio a HTTPS.

Por qué importa: Sin redirección, los visitantes y los buscadores pueden acabar en la versión sin cifrar del sitio.

Cabeceras de seguridad

2 comprobaciones

Las cabeceras HTTP que indican al navegador cómo proteger a tus visitantes.

Cabeceras de seguridad HTTP

Qué comprobamos: Comprobamos el conjunto completo de cabeceras de protección — HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy y las cabeceras de aislamiento cross-origin.

Por qué importa: Estas cabeceras son la defensa más barata y de mayor impacto contra el clickjacking, el MIME sniffing y las fugas de datos.

Content Security Policy

Qué comprobamos: Si hay una CSP definida, evaluamos su calidad — unsafe-inline, unsafe-eval, fuentes comodín y directivas que faltan.

Por qué importa: Una CSP laxa da una falsa sensación de seguridad; una estricta es la mejor defensa contra el cross-site scripting (XSS).

Cookies y sesiones

1 comprobaciones

Si las cookies que define tu sitio están protegidas contra robo y abuso.

Atributos de las cookies

Qué comprobamos: Inspeccionamos cada cookie que define el sitio en busca de los atributos Secure, HttpOnly y SameSite.

Por qué importa: Las cookies de sesión sin estos atributos pueden robarse por la red o mediante un script malicioso, permitiendo el secuestro de la cuenta.

Integridad del frontend y del contenido

4 comprobaciones

Los scripts, bibliotecas y HTML que se sirven a los navegadores de los visitantes.

Contenido de la página y formularios

Qué comprobamos: Analizamos el HTML renderizado en busca de contenido mixto (HTTP) y formularios enviados sin protección CSRF.

Por qué importa: El contenido mixto rompe silenciosamente el cifrado, y los formularios sin protección invitan al cross-site request forgery.

Subresource Integrity

Qué comprobamos: Listamos los scripts y estilos de terceros cargados sin un hash de integridad (SRI).

Por qué importa: Si un CDN del que dependes resulta comprometido, es precisamente SRI lo que impide que el código del atacante se ejecute en tu sitio.

Source maps expuestos

Qué comprobamos: Probamos si tus source maps de JavaScript son accesibles públicamente.

Por qué importa: Unos source maps publicados entregan a un atacante tu código fuente original y comentado — incluida la lógica que querías ocultar.

Bibliotecas JavaScript obsoletas

Qué comprobamos: Identificamos las bibliotecas del frontend y señalamos las versiones sin soporte (jQuery, Bootstrap, AngularJS, Moment.js antiguos).

Por qué importa: Las bibliotecas sin mantenimiento acumulan vulnerabilidades públicas sin parchear que los bots buscan activamente.

Fugas de datos e información

4 comprobaciones

Archivos, rutas y mensajes de error que el público nunca debería ver.

Rutas sensibles expuestas

Qué comprobamos: Probamos de forma segura unas dos docenas de rutas de riesgo — .env, .git, archivos de configuración, almacenes de credenciales y paneles de administración.

Por qué importa: Un solo archivo .env o directorio .git accesible puede filtrar contraseñas de base de datos, claves API y todo tu código.

Listado de directorios

Qué comprobamos: Comprobamos las carpetas habituales en busca de páginas de índice generadas automáticamente que exponen su contenido.

Por qué importa: Un listado de directorios abierto permite a cualquiera navegar y descargar archivos que nunca quisiste publicar.

Fugas de errores y depuración

Qué comprobamos: Provocamos un estado de error y buscamos trazas de pila y salidas de depuración de ASP.NET, PHP, Python o la base de datos.

Por qué importa: Los errores detallados entregan a un atacante tu framework, tus rutas de archivos y tus consultas — una guía para el siguiente ataque.

Fugas de versiones y banners

Qué comprobamos: Leemos las cabeceras de identificación (Server, X-Powered-By, X-AspNet-Version) en busca de nombres de software y números de versión.

Por qué importa: Exponer versiones exactas permite a un atacante emparejar tu stack con exploits conocidos en segundos.

Configuración del servidor y la API

4 comprobaciones

Cómo responde tu servidor a las solicitudes y qué revela sobre sí mismo.

Métodos HTTP

Qué comprobamos: Comprobamos qué métodos ofrece el servidor y probamos el peligroso método TRACE.

Por qué importa: Los métodos peligrosos y TRACE permiten el cross-site tracing y escrituras no deseadas en tu aplicación.

Archivos de política cross-domain

Qué comprobamos: Comprobamos archivos crossdomain.xml y clientaccesspolicy.xml demasiado permisivos.

Por qué importa: Una política cross-domain comodín permite que el código de sitios ajenos lea respuestas destinadas solo a tus usuarios.

Configuración de CORS

Qué comprobamos: Probamos tu política CORS en busca de orígenes comodín, orígenes reflejados y acceso con credenciales.

Por qué importa: Una política CORS mal configurada puede permitir que cualquier sitio lea tus respuestas de API autenticadas en nombre del visitante.

Introspección de GraphQL

Qué comprobamos: Probamos los endpoints de GraphQL habituales para ver si la introspección del esquema es accesible públicamente.

Por qué importa: Una introspección abierta mapea toda tu API — cada tipo, campo y mutación — para que el atacante la estudie.

Correo y dominio (DNS)

1 comprobaciones

Los registros DNS que evitan la suplantación de tu dominio y tus correos.

Registros de correo y DNS

Qué comprobamos: Resolvemos los registros DNS del dominio — SPF, DKIM, DMARC, DNSSEC y CAA.

Por qué importa: La ausencia de SPF/DKIM/DMARC significa que cualquiera puede enviar un correo que parezca venir de tu dominio.

Higiene de publicación

2 comprobaciones

Pequeños archivos esperados que indican que un sitio se gestiona profesionalmente.

robots.txt

Qué comprobamos: Obtenemos el robots.txt y comprobamos que está presente y no revela accidentalmente rutas sensibles.

Por qué importa: Un robots.txt sensato guía a los buscadores; uno descuidado puede exponer justo las rutas que querías ocultar.

security.txt

Qué comprobamos: Buscamos /.well-known/security.txt con campos Contact y Expires válidos (RFC 9116).

Por qué importa: Un security.txt da a los investigadores una vía para informarte de una vulnerabilidad en lugar de hacerla pública.

Ve tu propio informe en 60 segundos.

Cada comprobación de arriba, ejecutada contra tu sitio, con la corrección exacta para todo lo que falle — y un nuevo análisis en 14 días para demostrar la mejora.

Analizar mi sitio — 49 $/mes

Cancelación en dos clics · sin permanencia