Sicherheits-Header prüfen

Was die Header im Browser tun

Strict-Transport-Security heißt kurz HSTS. Der Header weist Browser an, die Domain künftig nur per HTTPS aufzurufen. max-age nennt die Dauer in Sekunden. Setze HSTS erst, wenn HTTPS ohne Fehler läuft.

Content-Security-Policy heißt kurz CSP. Sie legt etwa fest, aus welchen Quellen der Browser Skripte und Bilder laden darf. Plane die erlaubten Quellen passend zu deiner Seite.

X-Content-Type-Options mit nosniff begrenzt das Erraten von Dateitypen im Browser. Prüfe auch, ob dein Server den richtigen Inhaltstyp sendet.

X-Frame-Options begrenzt, wer deine Seite in einen Rahmen einbetten darf. Das geht auch mit frame-ancestors in der CSP. So kannst du fremde Einbettung begrenzen.

Referrer-Policy steuert, welche Teile der Herkunftsadresse der Browser bei Anfragen weitergibt. Permissions-Policy begrenzt den Zugriff auf Funktionen wie Kamera und Mikrofon. Wähle die Regeln nach dem Bedarf deiner Seite.

So erkennst du Fehler

Öffne die Werkzeuge deines Browsers und dort den Bereich Netzwerk. Lade die Seite neu und wähle den Aufruf des HTML-Dokuments. Sieh unter den Antwort-Headern nach. Notiere fehlende Header und ihre Werte.

Ein Header allein belegt noch keine passende Regel. Eine zu enge CSP kann nötige Inhalte blockieren. Teste neue Regeln erst mit Content-Security-Policy-Report-Only. Das meldet Verstöße, ohne diese Regeln zu erzwingen.

includeSubDomains dehnt HSTS auf Subdomains aus. Prüfe daher vorab auch deren HTTPS. Ein falsches Zertifikat kann bei aktivem HSTS den Zugriff sperren. Übernimm diese Option nicht blind.

Header beim Hoster setzen

Frage deinen Hoster, wo du Antwort-Header setzen kannst. Kläre, ob Apache oder nginx die Seite ausliefert. Sichere vor der Änderung die bisherige Einstellung. Teste nach jedem Schritt die Seite und ihre Formulare.

Apache kann Header über .htaccess setzen, wenn der Hoster das Modul mod_headers und die nötigen Rechte freigibt. Bei nginx gehören add_header-Regeln in die Server-Konfiguration. Lass die Änderung von deiner Betreuung prüfen und laden.

Wann der Webriegel-Check hilft

Der Check prüft Schutz-Header und gibt Hinweise zu ihren Werten. Du bekommst Empfehlungen für deine Betreuung. Ob jede Funktion mit neuen Regeln läuft, musst du danach testen.

Der Kurzcheck erfasst nur, ob die dort genannten Header vorhanden sind. Er bewertet ihre Werte nicht. Permissions-Policy gehört nicht zu diesem Kurzcheck.

Kurze Beispiele für deine Betreuung

Diese Beispiele setzen nur nosniff. Kläre erst den richtigen Inhaltstyp und die Rechte beim Hoster.

Apache: .htaccess mit mod_headers

Header always set X-Content-Type-Options "nosniff"

nginx: im passenden server-Block

add_header X-Content-Type-Options "nosniff" always;

Lass bestehende Regeln vor dem Einbau prüfen. Die Beispiele sind keine vollständige Konfiguration aller Header.

Quellen und Stand

Stand: 3. November 2026. Die Anleitung stützt sich auf diese Quellen.

• MDN: Strict-Transport-Security
• MDN: Content-Security-Policy
• MDN: X-Content-Type-Options
• MDN: X-Frame-Options
• MDN: frame-ancestors
• MDN: Referrer-Policy
• MDN: Permissions-Policy
• OWASP Secure Headers Project
• RFC 6797: HSTS
• Apache: mod_headers
• nginx: add_header
• MDN: CSP zunächst beobachten

So läuft dein Check ab

Du fragst mit der Adresse deiner Website an. Dann bestätigst du den Auftrag und zeigst, dass du die Prüfung beauftragen darfst. Wir prüfen von außen, ohne Angriffe und ohne Lasttests. Du bekommst einen Bericht mit Prioritäten und einer Empfehlung zu jedem Befund.

Eine Garantie für vollständige Sicherheit kann keine Prüfung geben. Die Umsetzung kannst du nach dem Bericht gesondert anfragen.