Cómo saber si tu web es segura en 5 minutos

No necesitas ser experto en seguridad para saber si tu web tiene los fallos más comunes. Con un navegador, una terminal y cinco minutos puedes comprobar lo que un atacante automatizado prueba en los primeros segundos: si el tráfico va cifrado, si faltan cabeceras, si hay claves en el código, si tu API acepta peticiones de cualquier sitio y si hay archivos que no deberían estar ahí. Esta guía te lleva paso a paso, con el comando exacto, qué significa cada resultado y qué hacer según lo que encuentres. Al final tienes cómo priorizar y qué cosas este test no detecta.

Minuto 1: HTTPS y redirección

Escribe tu dominio con http:// delante, sin la ese. Debe llevarte a la versión https:// de forma inmediata. Desde la terminal:

curl -sI http://tudominio.com | head -3
curl -sI http://tudominio.com/precios | head -3

Las dos respuestas deben ser un 301 con Location: https://.... Si la segunda no redirige, tu redirección solo cubre la home. Después, con https://, mira si aparece la cabecera Strict-Transport-Security: le dice al navegador que no vuelva a usar HTTP. Si estás en Vercel, Netlify o Cloudflare, la redirección viene puesta y HSTS lo tienes que añadir tú. Qué significa cada detalle del certificado, en qué significa realmente tu nota de TLS.

Minuto 2: cabeceras de seguridad

curl -sI https://tudominio.com | grep -iE "strict-transport|content-type-options|frame-options|referrer-policy|content-security-policy|permissions-policy"

Deberían salir al menos cinco líneas. Cada una que falte es una protección que el navegador no puede aplicar: sin X-Frame-Options tu web se puede incrustar en otra para engañar a tus usuarios; sin X-Content-Type-Options el navegador adivina tipos de archivo; sin Content-Security-Policy cualquier script inyectado se ejecuta sin freno. Si no te gusta la terminal, pega tu URL en el analizador de cabeceras. El significado de cada una, en cabeceras HTTP explicadas para humanos.

Minuto 3: secretos en el JavaScript

Abre tu web, clic derecho, "Ver código fuente". Busca .js para ver qué archivos de script carga, abre el principal y usa el buscador del navegador con estos términos:

sk_live   sk_test   service_role   AKIA   eyJhbGci   api_key   apiKey   secret   password

Desde la terminal puedes hacerlo de golpe sobre todos los scripts de la home:

curl -s https://tudominio.com/ | grep -oE 'src="[^"]+\.js[^"]*"' | cut -d'"' -f2 | while read s; do
  case "$s" in http*) u="$s";; /*) u="https://tudominio.com$s";; *) u="https://tudominio.com/$s";; esac
  curl -s "$u" | grep -oE "sk_live_[A-Za-z0-9]+|service_role|AKIA[A-Z0-9]{16}|eyJhbGciOi[A-Za-z0-9_-]{20,}" | head -3
done

Hay cosas que es normal encontrar: la clave pública de Stripe (pk_live), la clave anon de Supabase o la configuración de Firebase están diseñadas para ir en el navegador. Lo que nunca debe aparecer: sk_live, service_role, claves de AWS (AKIA), tokens de OpenAI o cualquier cosa que se llame secret. Si encuentras una, dala por comprometida y rótala antes de quitarla del código. La lista completa está en secretos que tu app filtra en el navegador.

Minuto 4: CORS y cookies

CORS decide qué otras webs pueden hacer peticiones a tu API desde el navegador. Pide un endpoint tuyo fingiendo venir de otro dominio:

curl -sI -H "Origin: https://evil.example" https://tudominio.com/api/me | grep -i "access-control"

Si responde Access-Control-Allow-Origin: https://evil.example o * junto con Access-Control-Allow-Credentials: true, cualquier web puede leer datos de tus usuarios con su sesión. El origen permitido debe ser el tuyo y solo el tuyo. Mientras estás ahí, mira las cookies en la respuesta de login o en las herramientas del navegador: las de sesión necesitan Secure, HttpOnly y SameSite=Lax o Strict. El detalle en CORS mal configurado.

Minuto 5: archivos expuestos

Las herramientas y los despliegues a medias dejan rastros. Prueba estas rutas y mira qué código devuelven:

for p in .env .env.local .env.production .git/config .DS_Store config.json backup.zip database.sql phpinfo.php server-status api/debug api/seed swagger.json; do
  printf "%-20s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://tudominio.com/$p"
done

Lo que quieres ver es 404 (o 301 hacia tu página de error). Un 200 en .env o .git/config es grave: el primero contiene tus credenciales y el segundo permite descargar el código fuente completo. Un 200 en swagger.json o api/debug no es una fuga en sí, pero le da a un atacante el mapa de tu API.

Minuto extra: lo que ven los bots

Si te sobra un minuto, mira /robots.txt y /sitemap.xml: que existan, que no bloqueen a todo el mundo y que el sitemap tenga solo páginas que quieres indexar. No es seguridad en sentido estricto, pero un Disallow: / olvidado de la fase de pruebas cuesta meses de posicionamiento.

Cómo priorizar lo que encuentres

No todo pesa igual. Este es el orden que usamos:

Crítico, hoy mismo. Una clave secreta en el JavaScript; .env o .git accesibles; una API que acepta cualquier origen con credenciales. Rota, borra, cierra. Después revisa si alguien lo usó.
Alto, esta semana. Sin redirección a HTTPS; cookies de sesión sin HttpOnly o Secure; rutas de depuración en producción.
Medio, este mes. Cabeceras que faltan; sin HSTS; certificado que caduca pronto sin renovación automática.
Bajo. Documentación de API expuesta, robots.txt y sitemap descuidados, cabeceras que revelan la versión del servidor.

Lo que estos cinco minutos no detectan

Sé honesto con los límites. Este test mira la superficie que cualquiera puede ver desde fuera. No comprueba si tu base de datos deja leer filas de otros usuarios (en Supabase es RLS, en Firebase son las reglas), si tus dependencias tienen vulnerabilidades conocidas, si tu lógica de negocio permite saltarse un pago o si un formulario acepta cualquier entrada. Para lo primero, la guía de Supabase y la de Firebase explican cómo probarlo. Para lo demás hace falta mirar el código, y la checklist antes de lanzar recoge lo esencial.

Scanaris hace esto y cuarenta cosas más en 30 segundos

Los cinco pasos de arriba son el núcleo de lo que Scanaris comprueba, más unas cuarenta pruebas que no caben en cinco minutos: cada cabecera por separado, los secretos con patrones de decenas de servicios, los archivos expuestos con una lista mucho más larga, TLS completo, cookies, CORS en varias rutas, y además el estado de tu SEO y de tu visibilidad ante la IA. Por cada fallo te da un fix prompt para pegar en Lovable, Bolt, Cursor o v0 con el cambio exacto, y puede repetir el escaneo cada día y avisarte si algo empeora. Todo son comprobaciones de solo lectura sobre lo que ya es público en tu web.

Preguntas frecuentes

¿Es legal escanear mi propia web así?

Sí. Todo lo que hay aquí son peticiones normales que cualquier navegador hace; solo estás leyendo lo que tu servidor ya responde a cualquiera. Hazlo únicamente sobre dominios tuyos o con permiso.

¿Y si no sé usar la terminal?

Los pasos 1, 3 y 5 se pueden hacer desde el navegador (escribir URLs y ver código fuente), el 2 con el analizador de cabeceras gratuito, y el 4 es el único que la necesita. O deja que un escáner lo haga por ti.

¿Cada cuánto debería repetirlo?

Cada vez que despliegues algo relevante y, como mínimo, una vez al mes. Las apps hechas con IA cambian rápido, y una regeneración de código puede volver a introducir un fallo que ya habías arreglado.