HTTP-Header-Prüfung

HTTP-Response-Header verraten, wie sich ein Webserver verhält: den Statuscode, den er zurückgibt, wohin er weiterleitet, welche Software er betreibt und welche Security-Hardening-Header er sendet. Fehlende Header wie HSTS, Content-Security-Policy oder X-Frame-Options machen Websites anfällig für Downgrade-, Injection- und Clickjacking-Angriffe. IPeek folgt der vollständigen Redirect-Kette und bewertet die Antwort anhand der wichtigsten Security-Header.

Jede HTTP-Antwort beginnt mit einem Statuscode und einer Reihe von Headern vor dem Seiteninhalt. Der Statuscode teilt dem Client mit, was geschah: 200 bedeutet Erfolg, 301 und 302 bedeuten, dass die Ressource verschoben wurde, 404 bedeutet nicht gefunden und 5xx bedeutet einen Serverfehler. Header tragen Metadaten wie Content-Type, Server, Cache-Control und die Sicherheitsdirektiven, die dem Browser sagen, wie er die Seite behandeln soll. IPeek fragt die URL ab, erfasst diese Header genau so, wie der Server sie gesendet hat, und folgt jedem Redirect, sodass Sie den vollständigen Pfad bis zur finalen Antwort sehen.

Bestätigen Sie zuerst, dass der finale Statuscode der erwartete ist, typischerweise 200 für eine Live-Seite. Gehen Sie dann die Redirect-Kette durch: Eine saubere Konfiguration leitet HTTP auf HTTPS und jeden nicht-kanonischen Host auf den kanonischen um, in möglichst wenigen Sprüngen, da jeder zusätzliche Redirect Latenz hinzufügt. Achten Sie auf Redirect-Schleifen oder eine Kette, die auf dem falschen Host endet. Der Server-Header verrät die eingesetzte Software, und die Bewertung der Security-Header zeigt auf einen Blick, welche Schutz-Header vorhanden sind und welche fehlen.

Strict-Transport-Security (HSTS) zwingt Browser zur Nutzung von HTTPS und verhindert Downgrade-Angriffe. Content-Security-Policy begrenzt, von wo Skripte und Ressourcen geladen werden dürfen – die stärkste Abwehr gegen Cross-Site-Scripting. X-Frame-Options oder eine CSP-frame-ancestors-Direktive blockiert Clickjacking, indem sie steuert, wer Ihre Seite einbetten darf. X-Content-Type-Options: nosniff stoppt MIME-Sniffing. Die häufigste Lücke ist eine Website, die keinen dieser Header ausliefert und dem Browser so keinen zusätzlichen Schutz bietet. Fügen Sie sie am Webserver oder CDN hinzu und prüfen Sie dann erneut, ob sie in der Live-Antwort erscheinen.

Prüfen Sie Header nach einem Deployment, nach dem Wechsel Ihres CDN oder Reverse Proxy und immer dann, wenn Sie die Sicherheitslage einer Website verschärfen – das sind die Momente, in denen Header hinzugefügt, entfernt oder überschrieben werden. Es ist der schnellste Weg, um zu bestätigen, dass ein HTTP-auf-HTTPS-Redirect tatsächlich funktioniert, eine unerwartete Redirect-Kette zu debuggen oder zu verifizieren, dass ein konfigurierter Security-Header echte Browser erreicht und nicht irgendwo im Auslieferungspfad entfernt wird.