Was der Check macht
Response-Header sagen dem Browser, wie er mit einer Seite umgehen soll: ob er auf HTTPS bestehen muss, welche Skripte laufen dürfen, wer die Seite in einen Frame einbetten darf. Dieser Check ruft deine URL vom Server von iseeu.cc im Netz von Cloudflare ab (zuerst mit HEAD, mit GET, wenn der Server HEAD ablehnt), verwirft einen etwaigen Body ungelesen und bewertet die Security-Header, die zurückkommen.
Bewertet werden:
- Strict-Transport-Security (HSTS). Weist den Browser an, für diesen Host
max-ageSekunden lang nur HTTPS zu verwenden. Spätere Besuche schicken dann nie eine unverschlüsselte HTTP-Anfrage, die jemand im gemeinsam genutzten WLAN kapern könnte. Ein Jahr (31536000) oder mehr gilt als gut;includeSubDomainsundpreloadwerden vermerkt. Über reines HTTP gesendet, wird der Header ignoriert. - Content-Security-Policy (CSP). Legt fest, woher Skripte und andere Ressourcen kommen dürfen. Schmuggelt ein Angreifer ein
<script>-Tag in ein Kommentarfeld, verhindertscript-src 'self', dass es ausgeführt wird.'unsafe-inline'oder'unsafe-eval'in script-src schwächen das ab, weil eingeschleuster Inline-Code undeval()dann trotzdem laufen.frame-ancestorswird ebenfalls geprüft. - Clickjacking-Schutz. Eine feindliche Seite kann deine Seite in einen unsichtbaren Frame über einen Köder-Button legen, sodass der Klick des Besuchers auf deiner Seite landet.
X-Frame-Options: DENYoderSAMEORIGINbzw. CSPframe-ancestors 'none'oder'self'verhindert das; jede der beiden Varianten erfüllt diese Prüfung. - X-Content-Type-Options: nosniff. Sorgt dafür, dass der Browser dem angegebenen Content-Type vertraut. Eine hochgeladene Textdatei mit JavaScript darin, ausgeliefert als
text/plain, lässt sich dann nicht über ein Script-Tag ausführen. - Referrer-Policy. Mit
strict-origin-when-cross-originverrät eine Seite unter/reset?token=abc123fremden Websites im Referer-Header nur Schema und Host, nicht das Token. - Permissions-Policy. Schaltet ungenutzte Browserfunktionen für die Seite und alles, was sie einbettet, ab. Mit
camera=(), microphone=(), geolocation=()kann ein kompromittierter Werbe-Frame oder ein kompromittiertes Skript nicht einmal danach fragen. - Cross-Origin-Opener-Policy (COOP).
same-origingibt deiner Seite eine eigene Browsing-Context-Gruppe. Ein Fenster einer anderen Website, das deine Seite geöffnet hat oder von ihr geöffnet wurde, verliert damit seine Referenz und kann sie weder navigieren noch ausforschen.
Angezeigt, aber nicht bewertet: Werte von Server und X-Powered-By wie Apache/2.4.41 (Ubuntu) oder PHP/7.4.3, mit denen sich eine Website schneller bekannten Schwachstellen zuordnen lässt, sowie die Flags jedes Set-Cookie: Secure (nur HTTPS), HttpOnly (für JavaScript unsichtbar) und SameSite (schränkt das Mitsenden bei Cross-Site-Anfragen ein).
Die Note ist eine heuristische Zusammenfassung, kein Sicherheitsaudit. Header sind nur eine Schicht; gegen eine SQL-Injection oder ein ungepatchtes CMS helfen sie nicht.
So nutzt du den Check
- Gib eine vollständige öffentliche URL ein, die mit
http://oderhttps://beginnt. - Starte die Prüfung. Nach 5 Sekunden bricht sie ab.
- Lies die Weiterleitungskette. Bis zu 5 Weiterleitungen werden verfolgt, und jeder Schritt zeigt Statuscode und Location.
- Lies den endgültigen Statuscode, die Note und die Liste der Response-Header.
Erlaubt sind nur die Ports 80 und 443. Private, Loopback-, Link-Local-, Carrier-Grade-NAT- und andere reservierte Adressen werden abgelehnt, ebenso localhost und Namen unter .local oder .internal. Auch iseeu.cc selbst wird abgelehnt, einschließlich einer Weiterleitung, die hier landet, weil der Check sonst denselben Server erneut aufrufen würde; die Header dieser Website zeigt stattdessen curl -sI https://iseeu.cc/. Jede IP-Adresse hat 10 Prüfungen pro Minute. Die URL wird weder gespeichert noch protokolliert.
Das Ziel sieht eine Anfrage von Cloudflare statt von dir. Eine Bot-Abfrage, eine Weiterleitung nach Land oder ein Server, der HEAD anders behandelt als GET, kann das Ergebnis deshalb verändern.
Wofür du ihn brauchst
- Nach einem Deployment. Prüfe, ob eine Änderung an Proxy oder CDN keine Header verschluckt hat – etwa HSTS, das nach dem Austausch eines Load Balancers fehlt.
- Saubere Weiterleitungen. Prüfe, ob http:// in einem Schritt bei https:// ankommt und ob Apex- und www-Host auf eine einzige Adresse hinauslaufen.
- Prüfung von Dienstleistern. Bevor du die Login- oder Zahlungsseite eines Anbieters einbettest, sieh nach, ob sie Frames überhaupt zulässt.
- Versionslecks. Finde einen Server- oder X-Powered-By-Header, der eine exakte Version nennt.
- Cookie-Check. Stell sicher, dass Session-Cookies Secure, HttpOnly und SameSite tragen, bevor ein Prüfer sie bemängelt.
- CSP-Einführung. Bestätige nach dem Ende des Report-Only-Modus, dass die durchgesetzte Policy aktiv ist und ohne 'unsafe-inline' auskommt.
Ein vernünftiger Ausgangssatz
Ein guter Anfang für eine Website, die ihre eigenen Skripte und Styles ausliefert:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Cross-Origin-Opener-Policy: same-originX-Frame-Options wiederholt frame-ancestors für ältere Browser. Diese CSP blockiert Inline-Skripte, Inline-Event-Handler wie onclick und Inline-Styles – teste sie also, bevor du sie durchsetzt. Betten deine eigenen Seiten die Website in Frames ein, nimm stattdessen 'self' und SAMEORIGIN.
CSP erst im Report-Only-Modus einführen
Sendest du die Policy als Content-Security-Policy-Report-Only, blockiert der Browser nichts; er meldet Verstöße in der Konsole und an einen Reporting-Endpunkt, den du festlegst. Lass sie eine Weile mit normalem Traffic laufen, behebe, was auftaucht, und benenne dann den Header um. Du kannst auch eine lockere Policy durchsetzen und parallel eine strengere erproben. Ein Report-Only-Header allein schützt niemanden.
HSTS-Preload ist eine Verpflichtung
Fügst du preload hinzu und meldest die Domain an, landet sie auf einer Liste, die in Chrome eingebaut ist und auch von Firefox, Safari und Edge genutzt wird. Browser überspringen reines HTTP dann schon beim ersten Besuch. Die Liste verlangt includeSubDomains und ein max-age von mindestens einem Jahr; jede Subdomain – bis hin zu einem vergessenen Intranet-Host oder der Admin-Seite eines Druckers – muss also gültiges HTTPS liefern. Das Entfernen dauert lange, weil es die Leute erst mit ihren Browser-Updates erreicht. Fang mit einem max-age wie 300 an, erhöhe es, wenn nichts kaputtgeht, und kümmere dich erst ganz zum Schluss um Preload.
X-XSS-Protection kannst du weglassen
Die XSS-Filter der Browser, die dieser Header steuerte, gibt es nicht mehr: Chrome hat seinen XSS Auditor 2019 entfernt, Edge hat seinen Filter eingestellt, Firefox hatte nie einen, und die Filter ließen sich missbrauchen, um gezielt bestimmte Skripte abzuschalten. Sende X-XSS-Protection: 0 oder gar nichts und verlass dich auf CSP.
Mit curl prüfen
curl -sI https://iseeu.cc/
curl -sIL http://iseeu.cc/
curl -s -D - -o /dev/null https://iseeu.cc/Der erste Befehl gibt die Header einer einzelnen HEAD-Antwort aus, auch die Header einer Weiterleitung selbst, die die Schrittliste hier weglässt. Der zweite folgt Weiterleitungen und gibt jede Antwort aus. Der dritte sendet GET und verwirft den Body – für Server, die HEAD anders behandeln. Häng | grep -i strict-transport an, um einen einzelnen Header herauszufiltern; bei Header-Namen spielt Groß- und Kleinschreibung keine Rolle, und HTTP/2 sendet sie kleingeschrieben.
Häufige Fragen
Heißt ein A+, dass meine Website sicher ist?
Nein. Die Note fasst eine Handvoll Response-Header zusammen, die bestimmte Angriffe im Browser erschweren. Über Patches, Authentifizierung, Zugriffskontrolle, Injection-Lücken oder die Ablage von Geheimnissen sagt sie nichts. Eine Website kann ein A+ haben und trotzdem über eine fehlerhafte API Daten preisgeben, während eine Website mit schlechterer Note gut betrieben sein kann. Sieh die Note als schnellen Blick auf eine einzelne Schicht, nicht als Audit.
Warum sehe ich hier andere Header als in meinem Browser?
Die Anfrage kommt aus dem Netz von Cloudflare, nicht von deinem Gerät, und sie ist eine HEAD-Anfrage, sofern der Server HEAD nicht ablehnt. Viele Websites antworten je nach Land, vermutetem Bot-Status oder Anfragemethode unterschiedlich. Eine Bot-Abfrage, eine Weiterleitung nach Region oder ein Framework, das HEAD gesondert behandelt, liefert jeweils andere Header. Zum Vergleich führst du curl auf deinem eigenen Rechner aus.
Kann ich einen Server in meinem Heim- oder Firmennetz prüfen?
Nein. Der Check verbindet sich nur über die Ports 80 und 443 und lehnt private, Loopback-, Link-Local- und Carrier-Grade-NAT-Adressen ab, ebenso andere reservierte Bereiche und Namen wie localhost oder solche, die auf .local oder .internal enden. So lässt er sich nicht dazu benutzen, Rechner hinter fremden Firewalls zu erreichen. Für einen internen Host führst du curl -I auf einem Rechner in diesem Netz aus.
Wird die geprüfte URL irgendwo gespeichert?
Die URL wird weder gespeichert noch protokolliert. iseeu.cc protokolliert weder IP-Adressen noch Abfragen, führt keine Besucherdatenbank und setzt keine Cookies. Die geprüfte Website bekommt zwar eine Anfrage, doch die kommt aus dem Netz von Cloudflare und nicht von deiner eigenen IP-Adresse.
Werden Sicherheitseinstellungen aus einem HTML-Meta-Tag erkannt?
Nein. Der Check liest nur Response-Header und verwirft den Body ungelesen; eine Richtlinie in einem meta-http-equiv-Tag sieht er also nie. Auch Browser schränken Meta-Tags ein: Eine so ausgelieferte CSP ignoriert frame-ancestors und kann nicht im Report-Only-Modus laufen, und HSTS sowie X-Frame-Options werden in Meta-Tags komplett ignoriert. Verlässlich wirken all diese Einstellungen nur als echte HTTP-Header.
Was passiert bei langen Weiterleitungsketten oder langsamen Servern?
Der Check folgt bis zu 5 Weiterleitungen, zeigt für jeden Schritt Statuscode und Location und gibt nach 5 Sekunden auf. Eine Kette, die mehr Schritte braucht, deutet meist auf eine Fehlkonfiguration hin, etwa wenn sich http und https oder Apex- und www-Host die Besucher gegenseitig zuschieben. Jeder zusätzliche Schritt kostet echte Besucher außerdem einen Roundtrip, bevor die Seite überhaupt zu laden beginnt.
Wie bekomme ich ein A+?
Indem du alle sieben bewerteten Header in starker Form sendest: HSTS mit einem max-age von mindestens einem Jahr, eine CSP ohne 'unsafe-inline', 'unsafe-eval' oder Wildcard-Skriptquellen, einen Frame-Schutz über frame-ancestors oder X-Frame-Options, nosniff, eine Referrer-Policy, eine Permissions-Policy und eine Cross-Origin-Opener-Policy. Das ergibt 100 Punkte; ab 95 gibt es A+. Der Ausgangssatz weiter oben auf dieser Seite enthält alle sieben – teste die CSP aber zuerst im Report-Only-Modus.
Die Note betrachtet nur die Response-Header einer einzigen Anfrage von einem einzigen Standort aus. Nimm sie als Hinweis, wo sich weitere Arbeit lohnt, nicht als Urteil über die Sicherheit einer Website insgesamt.