Cómo saber si tu sitio web es seguro (guía práctica, 2026)
“Seguro” no es sí o no. Hay cinco capas que cualquiera puede verificar desde fuera en minutos — y dos que exigen acceso al código. Esta guía las separa.
Cuando alguien pregunta "¿cómo tengo la certeza de que mi sitio es seguro?", la respuesta honesta es: certeza absoluta no la tienes — pero puedes eliminar la mayor parte del riesgo común verificando cinco capas observables desde fuera, sin instalar nada y sin acceso al código.
Conviene separar de entrada lo que es verificable externamente de lo que no. Confundir ambas cosas es el error más caro: da sensación de aprobación sin cubrir donde las filtraciones realmente ocurren.
Las 5 capas que verificas desde fuera
1. HTTPS y certificado TLS
El candado del navegador dice que la conexión está cifrada — y nada más. Lo que importa comprobar además: ¿el certificado está por vencer? ¿El sitio acepta protocolos antiguos (TLS 1.0/1.1)? Y sobre todo: ¿http:// redirige a https://? Un sitio que responde en ambos es un sitio donde el primer acceso puede ser interceptado.
2. Cabeceras de seguridad HTTP
La capa más descuidada y la más barata de corregir — son líneas de configuración, no refactorización. Las que cambian el juego:
- HSTS (
Strict-Transport-Security) — obliga al navegador a hablar solo https con tu dominio, cerrando la ventana del punto anterior. - CSP (
Content-Security-Policy) — la defensa central contra XSS: declara desde dónde puede cargarse un script. La más laboriosa de acertar y la que más protege. - X-Frame-Options /
frame-ancestors— impide que tu sitio sea incrustado en un iframe ajeno (clickjacking). - X-Content-Type-Options: nosniff — impide que el navegador adivine el tipo de un archivo.
3. DNS
Aquí vive un problema que casi nadie busca: el subdominio huérfano. Apuntaste blog.tusitio.com a un servicio, cancelaste el servicio y olvidaste el registro DNS. Quien reclame esa dirección en el servicio pasa a servir contenido en tu dominio. Conviene revisar también DNSSEC y el registro CAA, que limita qué autoridades pueden emitirte certificados.
4. Autenticación de correo (SPF, DKIM, DMARC)
No protege el sitio — protege tu nombre. Sin esos tres registros, cualquiera puede enviar correo que parezca venir de tu dominio. Para quien tiene un producto con usuarios, es un vector directo de phishing contra su propia base. Es configuración de DNS; se resuelve en una tarde.
5. Exposición accidental
Archivos y rutas que subieron sin querer: .env, .git/, paneles administrativos indexados, rutas privadas listadas en el propio robots.txt — que es público y suele convertirse en un mapa de lo que querías esconder.
Las 2 capas que un escaneo externo NO ve
Este es el límite honesto de cualquier herramienta que solo mira la URL:
- Lógica de autorización. Si el usuario A puede leer el pedido del usuario B cambiando un id en la URL, eso es invisible desde fuera — solo aparece probando con dos cuentas reales y permiso del dueño. Es la falla más común en apps hechas con IA, porque el generador escribe el endpoint y olvida el "¿este registro es tuyo?".
- Secretos en el código y en la base de datos. Una clave de API commiteada, una credencial en el historial de Git, una tabla sin regla de acceso. Requiere acceso al repositorio.
Quien promete un "sitio 100% seguro" mirando solo la URL está vendiendo la primera lista como si fueran las dos.
El camino más corto
Puedes hacer todo esto a mano, una herramienta por capa. O ejecutarlo de una vez: el escaneo gratuito de ecoa verifica las cinco capas a partir de la URL, sin registro y sin instalar nada, y devuelve una nota con los problemas ordenados por severidad.
Si trabajas con un asistente de IA (Claude, Cursor, ChatGPT), puedes conectar ecoa como servidor MCP y simplemente pedirle "verifica si mi sitio es seguro" — la IA ejecuta la verificación y lee el resultado dentro de la conversación, sin que salgas a ningún lado.
Preguntas frecuentes
- ¿Cómo sé si mi sitio web es seguro?
- Verifica cinco capas observables desde fuera: HTTPS con redirección y certificado válido; cabeceras de seguridad (HSTS, CSP, X-Frame-Options, nosniff); DNS (DNSSEC, CAA y subdominios huérfanos); autenticación de correo (SPF, DKIM, DMARC); y archivos expuestos por accidente, como .env y .git. Eso cubre la mayor parte del riesgo común. Las fallas de autorización y los secretos en el código exigen acceso al repositorio y no aparecen en una verificación externa.
- ¿Existe una prueba gratuita para verificar la seguridad de un sitio?
- Sí. ecoa ofrece una verificación gratuita en ecoa.dev/scan: pegas la URL y analiza cabeceras HTTP, TLS, DNS, autenticación de correo y exposición en SEO, sin exigir registro ni instalación. El resultado trae una nota y los problemas ordenados por severidad.
- Mi sitio tiene HTTPS y candado. ¿Con eso basta?
- No. El candado solo garantiza que la conexión está cifrada. No dice nada sobre XSS, clickjacking, cabeceras ausentes, subdominios huérfanos, fallas de autorización o secretos filtrados. Es el primer punto de la lista, no la lista entera.
- ¿Una cabecera de seguridad ausente es realmente grave?
- Depende de cuál. La ausencia de CSP deja al sitio sin su principal defensa contra XSS, y la ausencia de HSTS mantiene abierta la ventana del primer acceso por http. Son graves justamente porque el costo de corregirlas es bajo — normalmente unas pocas líneas de configuración del servidor o del framework.
- ¿Puedo pedirle a una IA que verifique mi sitio?
- Sí. Conectando el servidor MCP de ecoa a tu asistente (Claude, Cursor, ChatGPT u otro cliente compatible), basta con pedirle que verifique el sitio: la IA ejecuta el análisis y lee el resultado en la propia conversación. La verificación pública funciona sin clave de API; crear una cuenta libera la evidencia técnica de cada hallazgo.