Detector de formularios inseguros

Cómo funciona esta comprobación

Scanaris analiza el HTML de tu página principal y busca formularios que contengan un campo <input type="password">: un login, un registro, un cambio de contraseña. Si no hay ninguno, no hace nada. Si lo hay, comprueba dos cosas. Primera: si la propia página se ha servido por HTTP, abre un hallazgo de severidad alta, porque todo lo que el usuario escriba viaja sin cifrar. Segunda: si la página es HTTPS pero el atributo action del formulario empieza por http://, abre otro hallazgo de severidad alta con esa URL, porque el envío concreto de la contraseña sale sin cifrar aunque la página que la pide fuera segura. Solo se revisa la página analizada; si tu login vive en otra ruta, escanéala directamente.

Por qué importa

Una contraseña es el dato más valioso que te entrega un usuario, y es el que peor tratan las conexiones sin cifrar. Cuando un formulario viaja por HTTP, cualquiera que esté en el camino (el wifi de una cafetería, el proveedor de acceso, un router comprometido) puede leer el usuario y la contraseña tal cual, sin ninguna técnica. Y como la mayoría de la gente reutiliza contraseñas, lo que se filtra no es solo el acceso a tu web. Los navegadores lo saben: Chrome y Firefox marcan en rojo cualquier campo de contraseña en una página HTTP y avisan al usuario de que "no es seguro", así que además de un riesgo real es una pérdida de confianza visible.

Por qué pasa

El primer caso aparece cuando la web no redirige de HTTP a HTTPS y alguien llega por un enlace antiguo. El segundo es casi siempre un action escrito a mano durante el desarrollo (http://localhost:3000/login o http://api.midominio.com/auth) que nadie cambió, o un formulario copiado de un ejemplo. También ocurre cuando el login apunta a un servicio externo que todavía no tiene certificado.

Cómo arreglarlo

• Sirve toda la web por HTTPS y redirige HTTP. Es la base de todo lo demás; la comprobación de redirección HTTPS te dice si lo tienes. En Vercel, Netlify o Cloudflare viene hecho; en tu propio servidor, un bloque de redirección en nginx o Apache.
• Cambia el action a una ruta relativa (action="/login"), que hereda el protocolo de la página, o a la URL completa con https://. Si usas un framework (Nuxt, Next.js, Laravel, Django), la URL de la API debe venir de una variable de entorno con el valor de producción, no estar escrita en la plantilla.
• Si el login lo gestiona un tercero (Auth0, Supabase, Firebase, Clerk), su endpoint ya es HTTPS; el hallazgo entonces apunta a un action propio que sobra.
• Añade HSTS para que el navegador no vuelva a intentar HTTP ni en el primer salto; lo mide HSTS débil.

Comprueba que está arreglado

curl -sI http://tudominio.com/login | grep -iE "^(HTTP|location)"
curl -s https://tudominio.com/login | grep -oE '<form[^>]*action="[^"]*"' 

La primera debe devolver un 301 hacia https://. En la segunda, ningún action puede empezar por http://; lo normal es ver rutas relativas o nada (los formularios sin action envían a la propia página).

Preguntas frecuentes

Mi formulario envía por JavaScript, no por action. ¿Me afecta?

Esta comprobación mira el atributo action, así que un formulario que hace fetch no se marca por esa vía. Pero el riesgo es el mismo si el fetch apunta a http://: en una página HTTPS el navegador lo bloqueará como contenido mixto, y en una página HTTP viajará en claro. Revisa la URL de la API igualmente.

Es solo un entorno de pruebas sin usuarios reales.

Entonces no lo escanees como si fuera producción, o acepta el hallazgo. Pero ojo con los entornos de pruebas que acaban en Google: si alguien crea una cuenta ahí con su contraseña habitual, el problema es real.

¿Un campo de contraseña en una página HTTPS con action relativo está bien?

Sí. Es la configuración correcta y no genera hallazgo. Lo que falta por mirar es cómo guardas luego la sesión: cookies inseguras y token en el almacenamiento cubren esa parte.