HTTPS-Weiterleitungs-Prüfer

Wie diese Prüfung funktioniert

Scanaris fordert deine Seite über http:// an, ohne das s und ohne Weiterleitungen zu folgen, und schaut, was der Server antwortet. Gibt er einen Weiterleitungscode (301, 302, 307 oder 308) auf eine https://-URL zurück, ist alles in Ordnung. Antwortet er mit 200 und liefert die Seite im Klartext aus, öffnet er einen Befund mit mittlerem Schweregrad: Die unverschlüsselte Version deiner Seite existiert und funktioniert. Leitet er weiter, aber das Ziel ist noch http:// (zum Beispiel von der Root auf http://www), öffnet er einen Befund mit niedrigem Schweregrad: Die Weiterleitungskette hat ein unverschlüsseltes Glied. Getestet wird nur die gescannte URL; das Verhalten sollte auf allen Routen gleich sein, nicht nur auf der Startseite.

Warum das wichtig ist

Solange eine HTTP-Version antwortet, kann jeder alte Link, jede von Hand getippte Adresse und jedes öffentliche Netz den Nutzer ohne Verschlüsselung auf deine Seite bringen. In diesem Zustand liest, wer das Netz kontrolliert (das Flughafen-WLAN, ein bösartiger Provider), was gesendet wird, und kann die Seite verändern, bevor sie ankommt. Das ist die Grundlage von Man-in-the-Middle-Angriffen. Ein 301 auf HTTPS schließt diese Tür bei der ersten Anfrage, und HSTS schließt sie für alle folgenden.

So behebst du es je nach Hosting

• Vercel, Netlify, Cloudflare Pages, Railway, Render: Die Weiterleitung ist ab Werk aktiv. Wenn du den Befund siehst, zeigt die Domain meist auf einen anderen Server oder ein vorgeschalteter Proxy antwortet über HTTP.
• Cloudflare als Proxy: Aktiviere „Always Use HTTPS" und stelle den SSL-Modus auf „Full (strict)". Mit „Flexible" läuft die Strecke zwischen Cloudflare und deinem Server im Klartext.
• nginx:

server {
  listen 80;
  server_name deinedomain.de www.deinedomain.de;
  return 301 https://$host$request_uri;
}

• Apache: im VirtualHost für Port 80 Redirect permanent / https://deinedomain.de/.
• Express hinter einem Proxy: eine Middleware, die req.headers['x-forwarded-proto'] !== 'https' prüft und mit res.redirect(301, 'https://' + req.headers.host + req.url) antwortet, plus app.set('trust proxy', 1).

Nutze einen 301 oder 308 (dauerhaft) und keinen 302: Suchmaschinen bündeln die Autorität auf der HTTPS-Version und Browser cachen den Sprung. Füge danach den HSTS-Header hinzu, den die Prüfung schwaches HSTS misst, damit der Browser beim nächsten Mal HTTP gar nicht mehr versucht.

Prüf, ob es behoben ist

curl -sI http://deinedomain.de | grep -iE "^HTTP|^location"
curl -sI http://deinedomain.de/irgendeine-seite | grep -iE "^HTTP|^location"
curl -sI http://www.deinedomain.de | grep -iE "^HTTP|^location"

Alle drei müssen mit 301 oder 308 antworten und einem Location, das mit https:// beginnt. Leitet die zweite nicht weiter, deckt deine Regel nur die Startseite ab.

Häufige Fragen

Reicht es nicht, HTTPS aktiviert zu haben?

Nein. Ein Zertifikat zu haben bedeutet, dass die sichere Version existiert; die Weiterleitung bedeutet, dass die unsichere nicht benutzt wird. Ohne sie existieren beide nebeneinander.

Warum 301 und nicht 302?

Der 302 ist temporär: Browser fragen jedes Mal erneut die HTTP-Version an, und Suchmaschinen übertragen die Autorität nicht. Der 301 (oder der 308, der zusätzlich die Methode beibehält) ist das Signal, dass die Änderung endgültig ist.

Meine API braucht kein HTTPS, nur meine App nutzt sie.

Doch: Über diese API laufen Tokens und Daten deiner Nutzer. Und wenn die App sie von einer HTTPS-Seite aus per HTTP aufruft, blockiert der Browser sie als Mixed Content.