Um die Security-Header einer Website zu prüfen, rufen Sie die Seite per HTTPS ab und lesen sechs Antwort-Header: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options (oder die CSP-Direktive frame-ancestors), X-Content-Type-Options, Referrer-Policy und Permissions-Policy, dazu die Attribute jedes Set-Cookie. Ein fehlender Header ist nicht automatisch eine Lücke, und ein vorhandener ist nicht automatisch sicher: Entscheidend ist der Wert. Unsere kostenlose HTTP-Header-Abfrage zeigt alle Header einer URL in Sekunden, ohne Konto.
Alle Ergebnisse in dieser Anleitung stammen aus echten Abfragen vom 3. November 2026 mit unserem Tool gegen GitHub, die BBC und example.com. Die Regeln stammen von MDN, aus den offiziellen Anforderungen der HSTS-Preload-Liste und aus RFC 6797, am selben Tag geprüft.
Haben Sie die URL schon? Fügen Sie die vollständige Adresse mit https:// in die kostenlose HTTP-Header-Abfrage ein und lassen Sie das Ergebnis offen, während Sie die Liste unten durchgehen.
Die sechs wichtigen Header und welcher Wert gut ist
| Header | Was er verhindert | Ein solider Wert | Typischer Fehler |
|---|---|---|---|
Strict-Transport-Security | Downgrade auf unverschlüsseltes HTTP, Cookie-Diebstahl im öffentlichen WLAN | max-age=31536000; includeSubDomains | Kurzes max-age oder nur auf der HTTP-Weiterleitung gesendet |
Content-Security-Policy | Eingeschleuste Skripte (XSS), Datenabfluss | Beginnt mit default-src 'self' oder 'none' und nennt die echten Quellen | 'unsafe-inline' in script-src oder Wildcards |
X-Frame-Options / frame-ancestors | Clickjacking (Ihre Seite im iframe einer fremden Seite) | DENY, SAMEORIGIN oder frame-ancestors 'self' | Auf Login- und Bezahlseiten vergessen |
X-Content-Type-Options | Dass der Browser eine Textdatei als Skript behandelt | nosniff (der einzige gültige Wert) | Keiner, es ist ein Wort |
Referrer-Policy | Volle URLs, Tokens und Suchbegriffe, die an fremde Seiten gehen | strict-origin-when-cross-origin oder strenger | Das alte no-referrer-when-downgrade setzen |
Permissions-Policy | Eingebettete Dritte, die Kamera, Mikrofon oder Standort nutzen | camera=(), microphone=(), geolocation=(), wenn Sie sie nicht brauchen | Fehlt auf Seiten mit vielen fremden Widgets |
Ein Header, um den Sie sich nicht mehr kümmern müssen: X-XSS-Protection. MDN warnt, dass er in sonst sicheren Websites XSS-Lücken erzeugen kann, und empfiehlt stattdessen eine Content-Security-Policy. Deshalb sendet GitHub x-xss-protection: 0 und schaltet den alten Filter bewusst ab.
Security-Header prüfen: Schritt für Schritt
1. Die genaue URL nehmen, auf der Besucher landen
Geben Sie die vollständige Adresse mit Schema ein: https://github.com/, nicht github.com. Mit der nackten Domain meldete unser Tool ein Pflichtfeld statt eines Ergebnisses, weil es das Schema braucht, um zu wissen, was es abrufen soll. Prüfen Sie die Startseite, aber auch Login, Formulare und Checkout: Die kommen oft aus einer anderen Anwendung mit anderen Headern.
2. Abfrage starten
Öffnen Sie die HTTP-Header-Abfrage, fügen Sie die URL ein und klicken Sie auf den Button. Die Anfrage geht von unserem Server aus, Sie sehen also, was jeder Besucher bekommt, ohne Erweiterungen oder Cache Ihres Browsers dazwischen. Das Tool ist kostenlos und braucht kein Konto; ohne Anmeldung gibt es 5 Abfragen pro Tag, ein kostenloses Konto (kein Spam) hebt das Limit auf.
3. Den richtigen Hop finden
Das Tool folgt Weiterleitungen und listet die Header aller Hops in einer einzigen Tabelle. Die erste Zeile zeigt nur den Status der ersten Antwort. Bei http://github.com begann die Tabelle mit HTTP/1.1 301 Moved Permanently und Location: https://github.com/, alles danach kam von der finalen HTTPS-Seite. Die Regel: Was unter der letzten Location-Zeile steht, gehört zu der Seite, die Besucher tatsächlich sehen. Für eine saubere Tabelle fragen Sie direkt die finale HTTPS-URL ab und nutzen den Weiterleitungs-Checker für den Statuscode jedes Hops.
4. Jeden Header mit der Tabelle vergleichen
Gehen Sie die sechs Zeilen oben durch. Notieren Sie, was fehlt, und lesen Sie dann die Werte dessen, was da ist, denn ein schwacher Wert ist häufiger das Problem als ein fehlender Header.
5. Cookie-Attribute lesen
Alle Set-Cookie-Zeilen erscheinen zusammen in einer Zeile. Ein Session-Cookie sollte Secure, HttpOnly und einen SameSite-Wert tragen. Ein Analyse-Cookie darf HttpOnly bewusst weglassen, weil Skripte es lesen müssen.
Beispiel 1: GitHub, die starke Referenz
Die Abfrage von https://github.com/ lieferte HTTP/2 200 und diese Sicherheitszeilen (CSP gekürzt):
strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 0
referrer-policy: origin-when-cross-origin, strict-origin-when-cross-origin
content-security-policy: default-src 'none'; base-uri 'self'; child-src github.githubassets.com ...- Die CSP beginnt bei
default-src 'none': Nichts lädt, was keine Direktive erlaubt. Das ist der strengste Ausgangspunkt und der, den man für neue Seiten übernehmen sollte. - Die Referrer-Policy ist eine Liste. MDN beschreibt das als Fallback: Der Browser nimmt den letzten Wert, den er kennt, aktuelle Browser also
strict-origin-when-cross-origin. - Jedes Cookie hat die Attribute, die zu seiner Aufgabe passen.
_gh_sessundlogged_intragenHttpOnly; secure; SameSite=Lax;_octohatsecure; SameSite=LaxohneHttpOnly, was für einen von Skripten gelesenen Wert passt.
Eine Permissions-Policy fehlt. Selbst sehr gut gepflegte Seiten senden nicht alles, also nutzen Sie die Liste als Leitfaden, nicht als Punktzahl.
Beispiel 2: BBC, vorhanden, aber schwach
Die Abfrage von https://www.bbc.com/ zeigte:
referrer-policy: no-referrer-when-downgrade
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
strict-transport-security: max-age=31536000; preloadAuf den ersten Blick vier von sechs. Genau gelesen zeigen sich zwei echte Probleme:
- Die Referrer-Policy ist schwächer als der Browser-Standard. Laut MDN nutzen Browser ohne gesetzte Policy
strict-origin-when-cross-origin, undno-referrer-when-downgradewar der frühere Standard. Wer den alten Wert ausdrücklich setzt, lässt den Browser die volle URL samt Pfad und Parametern an jede andere HTTPS-Seite schicken; ohne den Header ginge nur der Origin mit. - Der HSTS-Header verlangt Preloading, erfüllt aber die Bedingungen nicht. hstspreload.org verlangt
includeSubDomainszusammen mitpreloadund ein max-age von mindestens einem Jahr auf der Basisdomain. Wir haben auchhttps://bbc.com/geprüft: Es antwortet mit einem 301 auf den www-Host und demselbenmax-age=31536000; preload, ohneincludeSubDomains.
Eine Content-Security-Policy fehlt ebenfalls. Auf einer Seite mit Werbung und vielen Drittanbieter-Skripten ist das die größte Lücke und zugleich die schwierigste.
Beispiel 3: example.com, gar nichts
https://example.com/ lieferte HTTP/2 200 mit Datum, Content-Type, server: cloudflare, Cache-Zeilen und keinem einzigen Security-Header. Per http:// von unserem Server abgefragt, antwortete es mit HTTP/1.1 200 OK ohne Weiterleitung auf HTTPS. Auf einer echten Website wäre das das Erste, was man behebt; auf einer statischen Dokumentationsseite ohne Login, Cookies oder Formulare ist das Risiko gering. Das ist die Kontextregel: Eine fehlende CSP auf einer Infoseite wiegt nicht so schwer wie auf der Kasse eines Onlineshops.
Fallstricke, die eine Prüfung verfälschen
- HSTS auf der HTTP-Weiterleitung zählt nicht. MDN und RFC 6797 sagen, dass Browser
Strict-Transport-Securityüber unverschlüsseltes HTTP ignorieren. GitHubshttp://-Hop sendet nur den 301 undLocation; der Header kommt mit der HTTPS-Seite, so wie es sein soll. - Ein 302 von HTTP auf HTTPS funktioniert, ein 301 ist sauberer.
http://www.bbc.com/antwortete mit302 Found,http://github.com/mit301. Beide landen auf HTTPS; erst HSTS spart die erste unsichere Anfrage bei späteren Besuchen. Den Unterschied erklärt unsere Anleitung, wie Sie eine 301- oder 302-Weiterleitung erkennen. Content-Security-Policy-Report-Onlyblockiert nichts. Er meldet nur: Die Seite testet eine Policy, sie ist nicht durch sie geschützt.- Das CDN kann Header hinzufügen oder entfernen. Setzt Ihr Server einen Header und die Abfrage zeigt ihn nicht, prüfen Sie zuerst die CDN-Regeln.
- Ein Meta-Tag ist kein Header. Eine CSP per
<meta http-equiv>erscheint in keiner Header-Abfrage und unterstützt keinframe-ancestors. Was im HTML steht, zeigt der Meta-Tags-Checker. - Gute Header beweisen nicht, dass eine Seite seriös ist. Auch eine Phishing-Seite kann perfekte Header senden. Für unbekannte Seiten folgen Sie unserer Anleitung, wie Sie prüfen, ob eine Website seriös ist, und sehen sich das Zertifikat mit der SSL-Prüfung an.
Ein vernünftiger Start für Ihre eigene Website
Für eine typische, nur per HTTPS ausgelieferte Website ist das eine sichere erste Version. Testen Sie sie auf einer Staging-Kopie und führen Sie die CSP zuerst als Report-Only ein:
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Content-Security-Policy: default-src 'self'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'Setzen Sie includeSubDomains erst, wenn alle Subdomains per HTTPS funktionieren, und preload erst, wenn Sie sicher sind, denn das Austragen aus der Preload-Liste dauert. Danach die URL noch einmal durch die kostenlose Header-Abfrage schicken und prüfen, ob jede Zeile genau so ankommt.
Häufig gestellte Fragen
Wie prüfe ich Security-Header kostenlos?
Fügen Sie die vollständige URL mit https:// in die HTTP-Header-Abfrage von My Botsy ein. Sie listet alle Antwort-Header in Sekunden und ohne Konto. Alternativ curl -sI mit der URL im Terminal, oder die Entwicklertools des Browsers öffnen, Reiter Netzwerk, und auf die Anfrage der Seite klicken.
Welche Security-Header sollte jede Website haben?
Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options mit nosniff, eine Referrer-Policy und Schutz vor Einbettung per X-Frame-Options oder frame-ancestors. Permissions-Policy lohnt sich bei eingebetteten Inhalten Dritter. X-XSS-Protection ist veraltet: auf 0 setzen oder weglassen.
Warum zeigt die Abfrage zuerst einen 301?
Weil sie Weiterleitungen folgt und alle Hops in einer Tabelle zusammenfasst; die erste Zeile ist der Status der ersten Antwort. Was nach der letzten Location-Zeile kommt, gehört zur finalen Seite. Fragen Sie für ein sauberes Ergebnis direkt die finale HTTPS-URL ab.
Ist eine Website ohne Content-Security-Policy unsicher?
Nicht automatisch. Die CSP begrenzt den Schaden, wenn jemand ein Skript einschleust. Eine statische Seite ohne Login, Formulare oder Fremdskripte hat wenig zu schützen; ein Login oder Checkout ohne CSP hat eine echte Lücke.
Kann ich Security-Header ohne Serverzugriff setzen?
Oft ja. CDNs wie Cloudflare können Antwort-Header über Regeln ergänzen, und viele Hoster erlauben sie in der .htaccess oder im Kundenmenü. Eine CSP geht auch per Meta-Tag, frame-ancestors funktioniert aber nur als echter Header.
Helfen Security-Header bei der Suchmaschinenoptimierung?
Ihre Aufgabe ist der Schutz der Besucher, nicht das Ranking, erwarten Sie also keinen Traffic-Sprung. Sie bringen Vertrauen und Konsistenz: HSTS hält wiederkehrende Besucher auf HTTPS, und eine saubere Weiterleitung von HTTP auf HTTPS sorgt dafür, dass Suchmaschinen nur eine Version jeder Seite sehen.
