Security Header Check

Was der Security-Scan prüft — und was nicht

Geprüft werden die Sicherheitsangaben, die ein Server von sich aus mitschickt:

• ob HTTPS erzwungen wird und wie das Zertifikat aussieht
• ob HSTS, Content-Security-Policy, X-Frame-Options und die übrigen Schutzkopfzeilen gesetzt sind
• ein kleiner Satz Ports, die auf einem Webserver nichts zu suchen haben

Ein Befund heißt nicht automatisch „angreifbar“. Eine fehlende Content-Security-Policy ist kein Loch, sondern eine fehlende Absicherung — sie macht andere Fehler gefährlicher, als sie sein müssten. Lies die Liste als Reihenfolge, nicht als Alarm.

Fehlt ein Header oder trägt er einen Wert, der nichts bewirkt, steht die Reihenfolge zum Nachziehen in Security-Header einrichten — mit Startwerten, fertiger Konfiguration für Apache, nginx und Netlify und dem Hinweis, welcher Header beim falschen Wert die eigene Seite aussperrt.

Dieser Scan ist ausschließlich beobachtend. Er ruft öffentliche Adressen ab und liest, was zurückkommt:

• keine Angriffslasten
• keine Tests auf SQL-Injection oder XSS
• keine Änderung auf dem Ziel

Das ist Absicht: Aktive Tests gegen eine fremde Domain, deren Besitz niemand nachgewiesen hat, wären ein Angriff über unsere Infrastruktur. Wer echte Penetrationstests braucht, braucht einen Eigentumsnachweis — und ein anderes Werkzeug.

Security Header Check: die sechs Header, die der Scan liest

Jeder Webserver schickt mit der Seite Kopfzeilen mit, die der Browser befolgt. Fehlen sie, gibt es keinen Fehler und keine Warnung, nur einen Schutz weniger. Der Check liest diese sechs:

• Strict-Transport-Security (HSTS): zwingt den Browser auf HTTPS; geprüft wird auch, ob max-age gesetzt ist und wie viele Tage die Zusage gilt
• Content-Security-Policy: legt fest, woher Skripte laden dürfen, und begrenzt damit Cross-Site-Scripting
• X-Frame-Options: verhindert, dass fremde Seiten deine in einem Rahmen einbetten (Clickjacking); widersprüchliche oder ungültige Werte werden gemeldet
• X-Content-Type-Options: verbietet dem Browser, Dateitypen zu erraten
• Referrer-Policy: steuert, wie viel von der Adresse an andere Seiten weitergegeben wird (Hinweis, keine Warnung)
• Permissions-Policy: schränkt Kamera, Mikrofon, Standort und andere Browser-Funktionen ein (Hinweis, keine Warnung)

Fünf dieser Header zeigt auch der E-Mail-Check als eigene Ampel, zusammen mit SPF, DKIM und DMARC der Domain.

Häufige Fragen zum Security Header Check

Was prüft ein Security Header Check?

Er ruft die Startseite einer Domain ab und liest die Antwort-Header des Servers: ob HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy und Permissions-Policy gesetzt sind und ob ihre Werte wirken. Dieser Scan prüft dazu HTTPS, das Zertifikat und einen kleinen Satz Ports.

Ist der Security Header Check kostenlos?

Ja. Er läuft ohne Anmeldung, als Gast mit einem Tageskontingent; mit einem kostenlosen Konto gibt es mehr Abfragen und den Verlauf je Domain.

Welche Security-Header sind am wichtigsten?

Für eine gewöhnliche Firmen-Website zuerst HSTS (HTTPS erzwingen), X-Content-Type-Options und ein Schutz vor Einbettung über X-Frame-Options oder frame-ancestors. Die Content-Security-Policy bringt am meisten, braucht aber Abstimmung, weil ein falscher Wert die eigene Seite bricht; deshalb zuerst im Berichtsmodus.

Wo setze ich fehlende Security-Header?

In der Konfiguration des Webservers oder Hosters, nicht in der Seite selbst: in der .htaccess bei Apache, im server-Block bei nginx, in der Datei _headers oder netlify.toml bei Netlify. Fertige Zeilen mit Startwerten stehen im Beitrag Security-Header einrichten.