Wie diese Prüfung funktioniert
Scanaris analysiert das HTML deiner Startseite und sucht Formulare mit einem Feld <input type="password">: ein Login, eine Registrierung, eine Passwortänderung. Gibt es keines, tut sie nichts. Gibt es eines, prüft sie zwei Dinge. Erstens: Wurde die Seite selbst über HTTP ausgeliefert, öffnet sie einen Befund mit hohem Schweregrad, weil alles, was der Nutzer eingibt, unverschlüsselt reist. Zweitens: Ist die Seite HTTPS, aber das action-Attribut des Formulars beginnt mit http://, öffnet sie einen weiteren Befund mit hohem Schweregrad und dieser URL, weil das Absenden des Passworts unverschlüsselt rausgeht, obwohl die Seite, die es abfragt, sicher war. Untersucht wird nur die gescannte Seite; lebt dein Login auf einer anderen Route, scanne sie direkt.
Warum das wichtig ist
Ein Passwort ist das Wertvollste, was ein Nutzer dir anvertraut, und es ist das, was unverschlüsselte Verbindungen am schlechtesten behandeln. Reist ein Formular über HTTP, kann jeder auf dem Weg (das WLAN im Café, der Zugangsanbieter, ein kompromittierter Router) Benutzername und Passwort im Klartext lesen, ganz ohne Technik. Und weil die meisten Leute Passwörter wiederverwenden, leckt nicht nur der Zugang zu deiner Seite. Browser wissen das: Chrome und Firefox markieren jedes Passwortfeld auf einer HTTP-Seite rot und warnen den Nutzer, dass es „nicht sicher" ist, also ist es neben einem echten Risiko auch ein sichtbarer Vertrauensverlust.
Warum das passiert
Der erste Fall taucht auf, wenn die Seite HTTP nicht auf HTTPS umleitet und jemand über einen alten Link kommt. Der zweite ist fast immer ein während der Entwicklung von Hand getipptes action (http://localhost:3000/login oder http://api.meinedomain.de/auth), das niemand geändert hat, oder ein aus einem Beispiel kopiertes Formular. Es passiert auch, wenn der Login auf einen externen Dienst zeigt, der noch kein Zertifikat hat.
So behebst du es
- Liefere die ganze Seite über HTTPS aus und leite HTTP um. Das ist die Grundlage für alles Weitere; die Prüfung HTTPS-Weiterleitung sagt dir, ob du sie hast. Auf Vercel, Netlify oder Cloudflare ist es fertig; auf dem eigenen Server ein Umleitungsblock in nginx oder Apache.
- Ändere das action auf einen relativen Pfad (
action="/login"), der das Protokoll der Seite erbt, oder auf die vollständige URL mithttps://. Nutzt du ein Framework (Nuxt, Next.js, Laravel, Django), sollte die API-URL aus einer Umgebungsvariable mit dem Produktionswert kommen, nicht im Template stehen. - Übernimmt ein Drittanbieter den Login (Auth0, Supabase, Firebase, Clerk), ist dessen Endpunkt bereits HTTPS; der Befund zeigt dann auf ein eigenes
action, das dort nicht hingehört. - Füge HSTS hinzu, damit der Browser HTTP nie wieder versucht, nicht einmal beim ersten Sprung; schwaches HSTS misst das.
Prüf, ob es behoben ist
curl -sI http://deinedomain.de/login | grep -iE "^(HTTP|location)"
curl -s https://deinedomain.de/login | grep -oE '<form[^>]*action="[^"]*"' Der erste Befehl muss einen 301 auf https:// zurückgeben. Im zweiten darf kein action mit http:// beginnen; normal sind relative Pfade oder gar nichts (Formulare ohne action senden an die Seite selbst).
Häufige Fragen
Mein Formular sendet per JavaScript, nicht per action. Betrifft mich das?
Diese Prüfung schaut auf das action-Attribut, ein Formular mit fetch wird auf diesem Weg also nicht gemeldet. Das Risiko ist aber dasselbe, wenn der fetch auf http:// zeigt: Auf einer HTTPS-Seite blockiert ihn der Browser als Mixed Content, auf einer HTTP-Seite reist er im Klartext. Prüf die API-URL trotzdem.
Es ist nur eine Testumgebung ohne echte Nutzer.
Dann scanne sie nicht wie Produktion, oder akzeptiere den Befund. Aber Vorsicht mit Testumgebungen, die bei Google landen: Legt dort jemand ein Konto mit seinem üblichen Passwort an, ist das Problem echt.
Ist ein Passwortfeld auf einer HTTPS-Seite mit relativem action in Ordnung?
Ja. Das ist die richtige Konfiguration und erzeugt keinen Befund. Was bleibt, ist, wie du die Sitzung danach speicherst: unsichere Cookies und Token im Speicher decken diesen Teil ab.