La seguridad de una web no depende solo de tener HTTPS ni de pasar un test de cabeceras HTTP. Una organización puede tener certificado válido y, aun así, exponer problemas en DNS, correo, cookies, tecnologías, subdominios, reputación, almacenamiento cloud, Certificate Transparency, robots.txt, security.txt o configuración frente a bots de IA.
Este checklist te ayuda a revisar la postura pública de seguridad de un dominio desde la misma perspectiva que usaría un atacante, un auditor, un cliente o un motor de IA.
Con Hard2bit Scanner puedes analizar un dominio en minutos y obtener una visión accionable de su exposición pública:
Analiza tu dominio con Hard2bit Scanner
La herramienta realiza análisis pasivos y no requiere agentes, credenciales ni acceso interno. Solo necesitas introducir el dominio que quieres revisar.
Hard2bit Scanner no es solo un comprobador de cabeceras HTTP. Es un scanner de postura pública que cubre controles de seguridad web, DNS, correo, exposición, reputación, cumplimiento e inteligencia artificial.
Resumen ejecutivo
Una web segura debe revisar, como mínimo:
- TLS/SSL y certificados.
- DNS health.
- Puertos expuestos.
- Cabeceras HTTP de seguridad.
- Tecnologías detectadas.
- Vulnerabilidades públicas conocidas.
- Cookies.
- Mixed content.
- Email security: SPF, DKIM, DMARC y MTA-STS.
- Estado del dominio.
- Certificate Transparency.
- AI security posture.
- Cloud storage exposure.
- Leaks en pastes y repositorios.
- Subdomain takeover.
- AI training exposure.
- AI bot blocking.
- Subdominios vía Certificate Transparency.
- Third-party breach exposure.
- Threat intelligence.
- security.txt.
- robots.txt.
- Compliance signals.
- Histórico y evolución.
- Evidencia exportable.
El objetivo no es solo saber si tu web “está bien”, sino entender qué señales públicas muestra tu dominio a Internet y qué podría aprovechar un atacante para preparar reconocimiento, phishing, explotación, suplantación o abuso de marca.
Puedes empezar aquí:
Analiza tu dominio con Hard2bit Scanner5
Por qué necesitas un checklist de seguridad web
La mayoría de empresas revisan su web cuando hay un rediseño, una migración o una auditoría puntual. El problema es que la exposición pública cambia constantemente:
- se publica una nueva landing;
- se instala un plugin;
- cambia el CDN;
- caduca un certificado;
- aparece un subdominio de staging;
- se modifica una política de DNS;
- una cabecera desaparece tras un despliegue;
- un proveedor externo introduce scripts;
- un bucket cloud queda accesible;
- se filtra una credencial en un repositorio;
- cambia la configuración de correo;
- se incorpora una nueva tecnología vulnerable;
- aparecen nuevos crawlers o agentes de IA consumiendo contenido.
Para un atacante, tu dominio público es una fuente de inteligencia. Para un equipo de seguridad, debería ser una fuente continua de señales.
Hard2bit Scanner ayuda a convertir esa revisión en una comprobación rápida, repetible y accionable.
Si quieres complementar esta visión con un análisis más amplio de exposición externa, puedes revisar nuestros servicios de gestión de superficie de ataque y gestión de vulnerabilidades.
Qué analiza Hard2bit Scanner
Hard2bit Scanner revisa la postura pública de seguridad de un dominio mediante controles pasivos. El objetivo es detectar señales visibles desde Internet que puedan afectar a seguridad, reputación, cumplimiento o exposición operativa.
Entre otros controles, la herramienta analiza:
- TLS/SSL: configuración de cifrado, certificado, cadena, caducidad y exposición de protocolos débiles.
- DNS health: salud DNS, registros públicos, coherencia de configuración y señales de riesgo.
- Puertos expuestos: servicios accesibles públicamente que pueden aumentar la superficie de ataque.
- Cabeceras HTTP de seguridad: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy y otras cabeceras relevantes.
- Tecnologías detectadas: frameworks, CMS, librerías, servidores o componentes visibles desde el exterior.
- Vulnerabilidades públicas conocidas: cruce de tecnologías detectadas con CVE o versiones potencialmente vulnerables.
- Cookies: atributos de seguridad como Secure, HttpOnly, SameSite, alcance y expiración.
- Mixed content: recursos inseguros cargados desde páginas HTTPS.
- Email security: SPF, DKIM, DMARC, MTA-STS y otros mecanismos públicos de protección del correo.
- Estado del dominio: señales asociadas al registro, caducidad y exposición del dominio.
- Certificate Transparency: certificados emitidos y subdominios visibles en logs públicos.
- AI security posture: señales de preparación y control frente a agentes, crawlers y motores de IA.
- Cloud storage exposure: indicios de almacenamiento cloud expuesto públicamente.
- Leaks en pastes y repositorios: menciones, secretos, tokens, endpoints o información sensible expuesta.
- Subdomain takeover: riesgo de subdominios apuntando a servicios externos abandonados o no reclamados.
- AI training exposure: señales de exposición de contenido en datasets o fuentes consumibles por IA.
- AI bot blocking: control de crawlers de IA como GPTBot, ClaudeBot, Google-Extended u otros.
- Subdominios vía Certificate Transparency: descubrimiento de activos no inventariados o shadow IT.
- Third-party breach exposure: exposición derivada de proveedores, servicios externos o integraciones.
- Threat intelligence: reputación del dominio, IPs, indicadores públicos y señales de abuso.
- security.txt: existencia de canal formal para reporte de vulnerabilidades.
- robots.txt: rutas reveladas, directivas de rastreo y señales de exposición accidental.
- Compliance signals: señales públicas relacionadas con privacidad, seguridad, canales de contacto y evidencias de madurez.
- Histórico y evolución: seguimiento de cambios de postura cuando se usa de forma recurrente.
- Evidencia exportable: base para reporting técnico, auditoría, comités de seguridad y remediación.
Esto permite pasar de un enfoque limitado de “¿tengo bien las cabeceras?” a una pregunta mucho más útil:
¿Qué postura pública de seguridad muestra mi dominio a Internet?
Alternativa a SecurityHeaders.com API: de comprobar cabeceras a medir postura web completa
SecurityHeaders.com ha sido durante años una referencia para revisar cabeceras HTTP de seguridad. Muchos equipos la usaban para comprobar HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy o Permissions-Policy.
El problema es que la API programática de SecurityHeaders.com fue anunciada como discontinuada para abril de 2026. Esto dejó a muchos equipos sin una pieza que ya tenían integrada en pipelines CI/CD, dashboards internos, auditorías recurrentes o controles de compliance.
Si buscabas:
SecurityHeaders.com API alternativeSecurityHeaders API replacementSnyk SecurityHeaders API shutdownHTTP security headers APIsecurity headers scanner APIdrop-in alternative to SecurityHeaders.com API
Hard2bit Scanner puede ayudarte a recuperar ese control y ampliarlo.
La diferencia es importante: Hard2bit Scanner no se limita a decirte si tienes o no unas cabeceras concretas. También analiza TLS, DNS, DMARC, cookies, tecnologías detectadas, CVE públicas, subdominios, exposición cloud, leaks, reputación, security.txt, robots.txt y postura frente a IA.
Si tu integración dependía exactamente del mismo endpoint, formato JSON, autenticación y códigos de respuesta de SecurityHeaders.com API, deberías validar la compatibilidad técnica antes de llamarlo “drop-in replacement”.
Pero si lo que necesitas es una alternativa práctica para seguir automatizando revisiones de seguridad web, Hard2bit Scanner ofrece una ruta más completa y actual.
SecurityHeaders.com y Hard2bit Scanner
Checklist de seguridad web con 25 controles
1. TLS/SSL
TLS es la base de la confidencialidad e integridad entre el navegador y tu web. Pero no basta con tener un candado o un certificado válido.
Qué revisar
- HTTPS forzado.
- Certificado válido.
- Caducidad controlada.
- Cadena de certificados correcta.
- Ausencia de protocolos obsoletos.
- Ausencia de cifrados débiles.
- Coherencia entre dominio raíz y
www. - HSTS activado cuando el sitio está preparado.
Por qué importa
Una configuración TLS débil puede permitir degradación de seguridad, errores de confianza, exposición de tráfico o interrupciones operativas si el certificado caduca.
Cómo comprobarlo
Analiza tu dominio con Hard2bit Scanner:
https://scan.hard2bit.com/
Si necesitas una revisión manual más profunda, puedes consultar el servicio de auditoría de seguridad informática.
2. DNS health
El DNS es una parte crítica de la seguridad web. Una mala configuración puede afectar disponibilidad, correo, reputación, subdominios, delegación y confianza.
Qué revisar
- Nameservers correctamente definidos.
- Redundancia DNS.
- Registros públicos coherentes.
- Registros obsoletos eliminados.
- Subdominios apuntando a servicios activos y controlados.
- Registros MX, TXT, CAA y SPF correctos.
- DNSSEC evaluado cuando aplique.
Por qué importa
El DNS suele ser una de las fuentes más valiosas para reconocimiento externo. También es un punto de fallo operativo y reputacional.
Cómo comprobarlo
Hard2bit Scanner incluye revisión de salud DNS.
Para un análisis más amplio de exposición externa, revisa gestión de superficie de ataque.
3. Puertos expuestos
Una web corporativa puede tener servicios adicionales expuestos en el mismo dominio, IP o subdominios relacionados.
Qué revisar
- Paneles administrativos accesibles desde Internet.
- Servicios de gestión expuestos.
- Bases de datos accesibles públicamente.
- Entornos de staging sin control.
- Servicios legacy abiertos.
- Interfaces de administración no protegidas.
- IPs asociadas al dominio.
Por qué importa
La exposición de puertos y servicios puede convertir una mala configuración en una intrusión real.
Cómo comprobarlo
Ejecuta un análisis de exposición pública:
https://scan.hard2bit.com/
Si necesitas revisar infraestructura, firewall, red o segmentación, consulta auditoría de infraestructura y red.
4. Cabeceras HTTP de seguridad
Las cabeceras HTTP ayudan a reducir riesgos como XSS, clickjacking, fuga de información, abuso de permisos del navegador o carga de contenido no autorizado.
Cabeceras recomendadas
Content-Security-PolicyStrict-Transport-SecurityX-Frame-OptionsX-Content-Type-OptionsReferrer-PolicyPermissions-PolicyCross-Origin-Opener-PolicyCross-Origin-Resource-PolicyCross-Origin-Embedder-Policy
Qué revisar
- La web no carece de cabeceras básicas.
- CSP está configurada de forma realista.
- No se permite
unsafe-inlineounsafe-evalsin justificación. - El sitio está protegido frente a clickjacking.
- Se limita la fuga de referer.
- Se restringen permisos innecesarios del navegador.
- No se exponen cabeceras que revelen tecnología o versiones internas.
Cómo comprobarlo
Usa Hard2bit Scanner como alternativa moderna a los checks clásicos de SecurityHeaders.com.
5. Tecnologías detectadas
Muchas webs exponen información sobre CMS, frameworks, servidores, librerías JavaScript, plugins, CDN o tecnologías de backend.
Qué revisar
- CMS utilizado.
- Frameworks visibles.
- Librerías JavaScript.
- Servidores web.
- Plugins.
- CDN.
- Versiones expuestas.
- Tecnologías abandonadas o sin soporte.
Por qué importa
La tecnología visible ayuda a un atacante a seleccionar exploits, rutas de ataque y payloads específicos.
Cómo comprobarlo
Hard2bit Scanner detecta tecnologías expuestas públicamente
Para una validación manual de impacto, revisa nuestros servicios de pentesting.
6. Vulnerabilidades públicas conocidas
Un dominio puede exponer tecnologías con vulnerabilidades conocidas, aunque la aplicación parezca funcionar correctamente.
Qué revisar
- Frameworks con CVE conocidas.
- Librerías JavaScript vulnerables.
- CMS desactualizados.
- Plugins vulnerables.
- Servidores con versiones inseguras.
- Dependencias frontend abandonadas.
- Rutas que revelan versiones.
Por qué importa
Los atacantes automatizan la búsqueda de versiones vulnerables. Si una tecnología vulnerable es detectable públicamente, el riesgo aumenta.
Cómo comprobarlo
Hard2bit Scanner cruza tecnologías detectadas con vulnerabilidades públicas conocidas.
Para priorizar vulnerabilidades con criterio de riesgo real, consulta gestión de vulnerabilidades y este artículo sobre escaneo de vulnerabilidades vs gestión de vulnerabilidades.
7. Cookies
Las cookies pueden contener identificadores de sesión, preferencias, tokens o datos que permiten mantener autenticado a un usuario.
Qué revisar
- Atributo
Secure. - Atributo
HttpOnly. - Atributo
SameSite. - Expiración adecuada.
- Alcance de dominio correcto.
- Alcance de ruta correcto.
- Ausencia de datos sensibles.
- Justificación de cookies de terceros.
Por qué importa
Una cookie mal configurada puede facilitar robo de sesión, abuso cross-site o exposición de información.
Cómo comprobarlo
Hard2bit Scanner revisa configuración de cookies.
8. Mixed content
Mixed content ocurre cuando una página servida por HTTPS carga recursos por HTTP, como imágenes, scripts, hojas de estilo o llamadas externas.
Qué revisar
- Scripts cargados por HTTP.
- Estilos cargados por HTTP.
- Imágenes críticas cargadas por HTTP.
- Llamadas a APIs inseguras.
- Iframes inseguros.
- Redirecciones de recursos externos que terminan en HTTP.
Por qué importa
El mixed content rompe la protección de transporte y puede permitir manipulación de recursos o errores de seguridad en navegadores.
Cómo comprobarlo
Hard2bit Scanner detecta mixed content en páginas seguras.
9. Email security
La seguridad del correo electrónico es parte de la seguridad web porque el dominio corporativo se usa para comunicación, clientes, facturación, soporte y campañas.
Qué revisar
- SPF publicado.
- DKIM activo.
- DMARC configurado.
- Política DMARC progresiva.
- Reporting monitorizado.
- Proveedores externos autorizados.
- Alineación de SPF y DKIM.
- MTA-STS evaluado.
- TLS-RPT evaluado cuando aplique.
Por qué importa
Sin SPF, DKIM y DMARC, un atacante puede tener más facilidad para suplantar tu dominio en campañas de phishing o fraude.
Cómo comprobarlo
Hard2bit Scanner analiza la configuración pública de seguridad del correo.
También puedes leer nuestro artículo sobre secuestro de cuentas en Microsoft 365.
10. Estado del dominio
El estado del dominio afecta directamente a disponibilidad, reputación, continuidad y seguridad.
Qué revisar
- Caducidad del dominio.
- Información pública del registro.
- Estado de bloqueo del dominio.
- Consistencia entre dominio principal y subdominios.
- Proveedor de registro.
- Señales de riesgo operativo.
- Cambios recientes relevantes.
Por qué importa
Un dominio mal gobernado puede provocar interrupciones, secuestro, pérdida de confianza o problemas de continuidad.
Cómo comprobarlo
Incluye el estado del dominio en tu revisión recurrente de postura pública.
11. Certificate Transparency
Los logs de Certificate Transparency permiten ver certificados emitidos para un dominio y sus subdominios.
Qué revisar
- Certificados emitidos recientemente.
- Subdominios desconocidos.
- Certificados para entornos no productivos.
- Emisiones por autoridades no esperadas.
- Certificados próximos a caducar.
- Certificados emitidos tras cambios de proveedor.
- Nombres que revelan entornos internos o antiguos.
Por qué importa
Certificate Transparency es una fuente muy útil para descubrir superficie expuesta y detectar emisiones no esperadas.
Cómo comprobarlo
Hard2bit Scanner usa Certificate Transparency para identificar activos expuestos.
12. AI security posture
Los agentes, crawlers y motores de IA están cambiando la forma en que las webs son descubiertas, resumidas, indexadas y reutilizadas.
Qué revisar
- Señales de control frente a crawlers de IA.
- Política pública de indexación.
- Rutas sensibles expuestas.
- Contenido reutilizable por agentes.
- Contenido que no debería entrar en datasets.
- Coherencia entre SEO, GEO y seguridad.
- Información técnica accidentalmente visible.
Por qué importa
La postura frente a IA ya forma parte de la exposición pública. Una web moderna debe decidir qué permite, qué bloquea y qué quiere que los agentes comprendan.
Cómo comprobarlo
Hard2bit Scanner incluye controles de postura frente a IA.
También puedes leer nuestra guía sobre seguridad MCP y agentes de IA empresariales.
13. Cloud storage exposure
La exposición accidental de almacenamiento cloud sigue siendo una causa frecuente de fugas de información.
Qué revisar
- Buckets públicos.
- Contenedores blob accesibles.
- Backups expuestos.
- Ficheros
.env. - Dumps.
- Logs.
- Directorios de documentos.
- Configuraciones de acceso anónimo.
- Índices abiertos.
Por qué importa
Un bucket público puede exponer datos personales, credenciales, backups, documentos internos o información sensible de clientes.
Cómo comprobarlo
Hard2bit Scanner incluye revisión de almacenamiento cloud expuesto en controles avanzados.
Si tu organización opera en cloud, revisa nuestros servicios de seguridad cloud.
14. Leaks en pastes y repositorios
Las fugas de información no siempre ocurren en la propia web. A veces aparecen en repositorios públicos, pastes, snippets o documentación expuesta.
Qué revisar
- Menciones del dominio en repositorios.
- Credenciales filtradas.
- API keys.
- Tokens.
- URLs internas.
- Endpoints no documentados.
- Ficheros de configuración.
- Secretos en ejemplos de código.
- Información técnica reutilizable por un atacante.
Por qué importa
Los atacantes buscan información filtrada para preparar accesos iniciales, phishing, explotación de APIs o movimiento lateral.
Cómo comprobarlo
Hard2bit Scanner incluye búsqueda de leaks públicos.
También puedes leer nuestra guía sobre credenciales comprometidas y priorización del riesgo.
15. Subdomain takeover
El subdomain takeover ocurre cuando un subdominio apunta a un servicio externo que ya no está reclamado o configurado.
Qué revisar
- CNAME hacia servicios SaaS no utilizados.
- Buckets eliminados pero aún referenciados.
- Apps PaaS abandonadas.
- Subdominios de campañas antiguas.
- Subdominios de staging.
- Registros DNS sin owner.
- Servicios externos no reclamados.
Por qué importa
Un atacante podría reclamar el recurso externo y publicar contenido bajo un subdominio legítimo de la empresa.
Cómo comprobarlo
Revisa el riesgo de takeover en subdominios.
16. AI training exposure
El contenido público puede ser descubierto, indexado, resumido o reutilizado por sistemas de IA dependiendo de su exposición y de las señales públicas disponibles.
Qué revisar
- Contenido sensible indexable.
- Documentación técnica pública.
- Rutas con información interna.
- Archivos de configuración visibles.
- Datos estructurados expuestos.
- Directivas para crawlers de IA.
- Contenido que no debería ser reutilizado por agentes.
Por qué importa
La exposición frente a IA no es solo una cuestión de posicionamiento. También afecta propiedad intelectual, privacidad, cumplimiento y gobierno de la información.
Cómo comprobarlo
Analiza la exposición frente a IA con Hard2bit Scanner:
Herramienta de seguridad Hard2bit Scanner
17. AI bot blocking
Cada vez más crawlers de IA recorren sitios web para indexar, entrenar, resumir o alimentar agentes.
Qué revisar
- Directivas para GPTBot.
- Directivas para ClaudeBot.
- Directivas para Google-Extended.
- Directivas para otros crawlers de IA.
- Coherencia entre robots.txt y estrategia de contenido.
- Rutas bloqueadas correctamente.
- Páginas que deben estar disponibles para descubrimiento.
- Páginas que no deberían ser rastreadas.
Por qué importa
El bloqueo o permiso de bots de IA debe responder a una estrategia: seguridad, propiedad intelectual, posicionamiento, GEO y reputación.
Cómo comprobarlo
Hard2bit Scanner revisa AI bot blocking
18. Subdominios vía Certificate Transparency
Los logs públicos de certificados pueden revelar activos que no aparecen fácilmente en navegación normal o en el sitemap.
Qué revisar
- Subdominios antiguos.
- Subdominios de staging.
- Entornos de pruebas.
- Portales internos expuestos.
- Subdominios de campañas.
- Subdominios de proveedores.
- Subdominios sin owner.
- Shadow IT.
Por qué importa
Muchas brechas empiezan en activos olvidados, no en la web principal.
Cómo comprobarlo
Usa el análisis de CT logs de Hard2bit Scanner:
19. Third-party breach exposure
La seguridad de tu dominio también depende de proveedores, integraciones, SaaS, plataformas de marketing, servicios cloud y herramientas externas.
Qué revisar
- Proveedores con acceso al dominio.
- Servicios que envían correo en tu nombre.
- Herramientas SaaS conectadas.
- Scripts de terceros.
- Subdominios delegados.
- Registros DNS asociados a proveedores.
- Brechas públicas vinculadas a terceros.
- Exposición heredada de integraciones antiguas.
Por qué importa
Un tercero comprometido o mal configurado puede afectar reputación, correo, exposición o confianza de tu dominio.
Cómo comprobarlo
Hard2bit Scanner incorpora señales de exposición de terceros.
Para riesgos de terceros y cumplimiento, también puedes revisar nuestro contenido sobre brechas en cadena de suministro, API keys y cumplimiento.
20. Threat intelligence
Tu dominio, IPs o servidores de correo pueden aparecer en listas de reputación, spam, malware, phishing o botnets.
Qué revisar
- Dominio en listas de phishing.
- IPs en listas de spam.
- Servidores de correo con mala reputación.
- Indicadores relacionados con malware.
- Bloqueos por navegadores o proveedores.
- Reportes asociados a campañas fraudulentas.
- Historial de abuso en infraestructura compartida.
Por qué importa
Una mala reputación puede afectar entregabilidad de correo, confianza de usuarios, SEO, campañas comerciales y continuidad operativa.
Cómo comprobarlo
Ejecuta el análisis de threat intelligence.
Para capacidades más avanzadas, consulta threat intelligence.
21. security.txt
security.txt es un estándar definido en RFC 9116 que permite publicar un canal claro para que investigadores de seguridad reporten vulnerabilidades.
Qué revisar
- Existe
/.well-known/security.txt. - Incluye contacto de seguridad.
- Incluye política de divulgación.
- Incluye fecha de expiración.
- El contenido está actualizado.
- El buzón o canal indicado se monitoriza.
- Hay proceso interno para gestionar reportes.
Por qué importa
Sin un canal claro, una vulnerabilidad descubierta por un tercero puede no llegar al equipo adecuado o terminar reportándose por vías informales.
Cómo comprobarlo
Hard2bit Scanner revisa la existencia de security.txt.
Si necesitas estructurar procesos de respuesta y gestión de incidentes, revisa respuesta a incidentes.
22. robots.txt
El fichero robots.txt no es un control de seguridad, pero puede revelar rutas sensibles o políticas de indexación mal planteadas.
Qué revisar
- No se publican rutas internas sensibles.
- No se revelan paneles administrativos.
- No se listan entornos de pruebas.
- No se bloquean por error recursos necesarios para SEO.
- Se define una política coherente para crawlers.
- Se revisan directivas relacionadas con bots de IA.
- No se usa robots.txt como mecanismo para ocultar información sensible.
Por qué importa
Muchos equipos usan robots.txt para ocultar rutas, pero en realidad es un archivo público. Todo lo que aparece ahí puede ser leído por cualquiera.
Cómo comprobarlo
Hard2bit Scanner analiza robots.txt.
23. Compliance signals
La postura pública de una web también comunica madurez: políticas, cookies, privacidad, seguridad y canales de contacto.
Qué revisar
- Política de privacidad.
- Política de cookies.
- Aviso legal.
- Canal de contacto.
- security.txt.
- Evidencias públicas de cumplimiento.
- Coherencia entre formularios, cookies y tratamientos.
- Señales relacionadas con GDPR, ENS, ISO 27001, NIS2 o DORA cuando aplique.
Por qué importa
No sustituye a una auditoría legal o normativa, pero ayuda a detectar incoherencias públicas que afectan confianza, reputación y preparación auditora.
Cómo comprobarlo
Incluye compliance signals en tu análisis de postura pública.
Para marcos específicos, puedes revisar:
24. Histórico y evolución
Un análisis aislado es útil, pero la seguridad mejora cuando puedes comparar evolución.
Qué revisar
- Cambios en cabeceras.
- Cambios en DNS.
- Nuevos subdominios.
- Certificados recientes.
- Nuevas tecnologías detectadas.
- Nuevos hallazgos de exposición.
- Regresiones tras despliegues.
- Correcciones verificadas.
- Evidencia temporal para auditoría.
Por qué importa
La postura web cambia con cada despliegue, proveedor, campaña o modificación de infraestructura. El histórico permite detectar regresiones y demostrar mejora continua.
Cómo comprobarlo
Usa Hard2bit Scanner de forma recurrente para construir histórico.
25. Evidencia exportable
Un checklist solo tiene valor si genera evidencia y seguimiento.
Qué revisar
- Fecha del análisis.
- Dominio analizado.
- Hallazgos por severidad.
- Recomendaciones accionables.
- Evidencia técnica.
- Responsable asignado.
- Fecha objetivo de corrección.
- Revisión posterior.
- Histórico de postura.
Por qué importa
Para seguridad, auditoría y dirección, no basta con decir “hemos revisado la web”. Hay que poder demostrar qué se revisó, cuándo, con qué resultado y qué se corrigió.
Cómo comprobarlo
Hard2bit Scanner permite convertir hallazgos en evidencia accionable y reportable.
Si necesitas convertir resultados en un plan de remediación, contacta con Hard2bit:
Checklist rápido para copiar
Transporte y cifrado
- HTTPS forzado.
- Certificado válido.
- Caducidad controlada.
- Cadena de certificados correcta.
- Sin protocolos obsoletos.
- Sin cifrados débiles.
- HSTS configurado.
- Dominio raíz y
wwwcoherentes.
Cabeceras HTTP
- Content-Security-Policy.
- Strict-Transport-Security.
- X-Frame-Options.
- X-Content-Type-Options.
- Referrer-Policy.
- Permissions-Policy.
- COOP, COEP y CORP cuando aplica.
- Sin cabeceras que revelen versiones innecesarias.
Cookies
- Secure.
- HttpOnly.
- SameSite.
- Expiración adecuada.
- Sin datos sensibles.
- Alcance de dominio correcto.
DNS y dominio
- Nameservers correctos.
- Redundancia DNS.
- Registros obsoletos eliminados.
- DNSSEC evaluado.
- CAA configurado.
- MX coherentes.
- Dominio no próximo a caducar.
- Subdominios inventariados.
Email security
- SPF publicado.
- DKIM activo.
- DMARC configurado.
- DMARC con política progresiva hacia cuarentena o rechazo.
- Reporting monitorizado.
- MTA-STS evaluado.
- Proveedores externos autorizados.
Exposición
- Sin paneles administrativos públicos.
- Sin buckets cloud expuestos.
- Sin ficheros
.env, backups o dumps. - Sin subdominios abandonados.
- Sin riesgo de subdomain takeover.
- Sin tecnologías vulnerables visibles.
- Sin mixed content.
- Sin rutas internas reveladas en robots.txt.
- Sin leaks públicos en repositorios o pastes.
Reputación y cumplimiento
- Dominio sin presencia en listas de malware o phishing.
- IPs sin mala reputación.
- security.txt publicado.
- Política de privacidad y cookies coherentes.
- Señales públicas de cumplimiento revisadas.
- Evidencia exportable para auditoría.
IA y agentes
- Política frente a bots de IA.
- Robots.txt revisado.
- Sitemap actualizado.
- Contenido estructurado.
- Páginas sensibles excluidas.
- AI bot blocking evaluado.
- AI readiness evaluado.
Puedes revisar gran parte de este checklist en minutos con Hard2bit Scanner.
Cómo migrar desde SecurityHeaders.com API a Hard2bit Scanner
Si tu organización usaba SecurityHeaders.com API, empieza por identificar dónde estaba integrada.
1. Localiza los puntos de uso
Revisa:
- pipelines CI/CD;
- scripts internos;
- dashboards de seguridad;
- herramientas de reporting;
- auditorías recurrentes;
- integraciones con SIEM;
- procesos de compliance;
- revisiones de dominios de clientes.
2. Identifica qué datos consumías
Documenta si dependías de:
- puntuación global;
- lista de cabeceras presentes;
- lista de cabeceras ausentes;
- recomendaciones;
- códigos de estado;
- respuesta JSON;
- histórico;
- evidencias exportables.
3. Define el nuevo modelo de control
Decide si quieres mantener solo el control de cabeceras o ampliar el análisis a postura web completa.
La recomendación de Hard2bit es ampliar el alcance a:
- cabeceras HTTP;
- TLS;
- DNS;
- email security;
- exposición;
- reputación;
- subdominios;
- cloud exposure;
- AI readiness.
4. Ejecuta un primer baseline
Analiza tu dominio principal en Hard2bit Scanner.
Después revisa:
- dominios secundarios;
- subdominios críticos;
- portales de clientes;
- landing pages;
- entornos públicos de soporte;
- aplicaciones SaaS propias;
- dominios usados para correo;
- dominios de campañas.
5. Prioriza correcciones
Empieza por:
- HTTPS, TLS y certificados.
- HSTS.
- Content-Security-Policy.
- X-Frame-Options y clickjacking.
- Cookies seguras.
- DMARC, SPF y DKIM.
- Subdominios olvidados.
- Tecnologías vulnerables.
- Exposición cloud.
- security.txt y robots.txt.
- AI bot blocking y AI readiness.
6. Documenta evidencia
Guarda resultados para:
- auditoría;
- seguimiento interno;
- comité de seguridad;
- cumplimiento;
- proveedores;
- clientes;
- mejora continua.
Si necesitas apoyo para convertir los hallazgos en plan de remediación contacta con Hard2bit Cybersecurity.
Cómo priorizar los hallazgos
No todos los hallazgos tienen el mismo impacto. Una buena priorización debería considerar:
- Explotabilidad: si el hallazgo puede ser usado directamente por un atacante.
- Impacto: si afecta confidencialidad, integridad, disponibilidad, reputación o cumplimiento.
- Exposición: si está visible públicamente sin autenticación.
- Criticidad del activo: si afecta a dominio principal, login, tienda, portal cliente o infraestructura sensible.
- Facilidad de corrección: si puede resolverse con un cambio de configuración rápido.
- Evidencia: si hay prueba técnica reproducible.
- Recurrencia: si el problema aparece tras despliegues o cambios de proveedor.
Una forma práctica de empezar:
- corregir primero certificados, HTTPS, HSTS y mixed content;
- después cabeceras críticas y cookies;
- a continuación DMARC, SPF y DKIM;
- luego DNS, subdominios y exposición cloud;
- finalmente AI readiness, security.txt, compliance signals y mejora continua.
Para una visión más amplia de priorización por riesgo real, puedes consultar nuestra guía sobre KEV, EPSS y SSVC para priorizar vulnerabilidades explotables.
Cuándo usar scanner y cuándo pedir auditoría manual
Hard2bit Scanner es ideal para:
- obtener una primera visión rápida;
- detectar configuraciones públicas débiles;
- revisar dominios corporativos;
- comprobar cambios tras despliegues;
- sustituir revisiones manuales de cabeceras;
- recuperar checks tras la retirada de SecurityHeaders.com API;
- generar evidencia inicial;
- priorizar correcciones;
- monitorizar postura externa;
- preparar una auditoría;
- revisar clientes o proveedores autorizados;
- detectar señales públicas de exposición;
- analizar dominios antes de campañas o lanzamientos.
Una auditoría manual o pentesting es recomendable cuando:
- hay aplicaciones críticas;
- existe login o área privada;
- se gestionan datos sensibles;
- hay APIs;
- existe obligación regulatoria;
- se necesita explotación controlada;
- se requiere informe formal;
- se busca validar impacto real;
- hay sospecha de compromiso;
- la organización necesita acompañamiento experto.
Hard2bit Scanner no sustituye a un pentest. Lo complementa.
Servicios relacionados:
- Pentesting
- Auditoría de seguridad informática
- Gestión de vulnerabilidades
- Superficie de ataque
- SOC gestionado
- Respuesta a incidentes
- Retainer de respuesta a incidentes
Relación con NIS2, DORA, ENS e ISO 27001
La postura pública de una web no es solo una cuestión técnica. También puede aportar evidencia para programas de cumplimiento, gestión de riesgos y resiliencia.
NIS2
NIS2 exige medidas técnicas, operativas y organizativas para gestionar riesgos de ciberseguridad. Revisar la exposición pública de dominios, correo, DNS y servicios web ayuda a demostrar gestión proactiva del riesgo.
Más información:
https://hard2bit.com/servicios/nis2/
También puedes leer nuestra guía práctica sobre cómo cumplir NIS2 en España.
DORA
En entidades financieras y proveedores TIC del sector financiero, la exposición pública debe gestionarse como parte del riesgo TIC, continuidad, resiliencia y gestión de incidentes.
Más información:
https://hard2bit.com/servicios/dora/
ENS
En entornos sujetos al Esquema Nacional de Seguridad, la revisión de configuración, exposición, trazabilidad y medidas de protección puede apoyar la mejora continua y la preparación ante auditoría.
Más información:
https://hard2bit.com/servicios/ens/
ISO 27001
La revisión periódica de postura web ayuda a aportar evidencia sobre gestión de vulnerabilidades técnicas, control de accesos, seguridad en comunicaciones y mejora continua.
Más información:
https://hard2bit.com/servicios/iso-27001/
También puedes revisar nuestro contenido sobre controles ISO 27001 con mayor ROI al principio.
Errores frecuentes en seguridad web
1. Pensar que HTTPS es suficiente
HTTPS es imprescindible, pero no cubre cabeceras, cookies, DNS, reputación, exposición, tecnologías vulnerables ni seguridad del correo.
2. Eliminar los checks tras la retirada de una API
Si una API externa deja de estar disponible, el control no debe desaparecer. Debe migrarse a una alternativa mantenida.
3. Configurar DMARC en p=none y olvidarlo
DMARC en modo monitorización puede ser un buen inicio, pero dejarlo indefinidamente en p=none reduce su eficacia frente a spoofing.
4. No revisar subdominios antiguos
Muchas brechas empiezan en activos olvidados, no en la web principal.
5. No controlar proveedores externos
Marketing, analítica, CRM, chat, CDN y herramientas SaaS pueden introducir scripts, DNS, cookies o dependencias que afectan la postura de seguridad.
6. No repetir el análisis
La postura web cambia con cada despliegue. Un análisis anual no es suficiente.
7. No guardar evidencia
Sin evidencia, es difícil demostrar mejora, responder ante auditorías o justificar inversión.
8. Separar SEO, seguridad y cumplimiento
Una web moderna debe ser visible, rápida, segura, trazable y gobernada. SEO, GEO, seguridad y compliance ya no pueden trabajar como silos.
9. Ignorar la exposición frente a IA
Los agentes y crawlers de IA ya forman parte del ecosistema web. Ignorarlos puede afectar propiedad intelectual, privacidad, reputación y descubrimiento de marca.
La seguridad web no es un único control. Es la suma de muchas señales públicas: TLS, DNS, puertos, cabeceras HTTP, tecnologías, CVE, cookies, mixed content, email security, Certificate Transparency, subdominios, exposición cloud, leaks, reputación, security.txt, robots.txt, compliance signals y preparación frente a agentes de IA.
La retirada de SecurityHeaders.com API en abril de 2026 deja una oportunidad clara: no limitarse a sustituir un check de cabeceras, sino evolucionar hacia una revisión completa de postura pública.
Un atacante puede usar esas señales para preparar reconocimiento, phishing, explotación, suplantación o abuso de marca. Tu equipo también puede usarlas para anticiparse.
Empieza por lo más sencillo: analiza tu dominio, identifica brechas visibles y prioriza correcciones.
Analiza gratis tu dominio con Hard2bit Scanner:
https://scan.hard2bit.com/
Si el análisis revela exposición crítica, tecnologías vulnerables, problemas de configuración o necesitas una revisión manual, Hard2bit puede ayudarte con auditoría, pentesting, gestión de vulnerabilidades, superficie de ataque, SOC y respuesta a incidentes.
Habla con un experto de Hard2bit.
Referencias técnicas
- Hard2bit Scanner: https://scan.hard2bit.com/
- SecurityHeaders.com: https://securityheaders.com/
- OWASP HTTP Headers Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html
- OWASP Transport Layer Security Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html
- OWASP HTTP Strict Transport Security Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html
- CISA BOD 18-01 Enhance Email and Web Security: https://www.cisa.gov/news-events/directives/bod-18-01-enhance-email-and-web-security
- RFC 9116 security.txt: https://www.rfc-editor.org/rfc/rfc9116