Sicherheits-Header erklärt
Ein Sicherheits-Header ist eine einzige Zeile in einer HTTP-Antwort, die ändert, was der Browser des Besuchers mit Ihrer Seite tun darf: Skripte nur aus benannten Quellen ausführen, nie wieder Klartext-HTTP sprechen, sich nicht einrahmen lassen, keine Inhaltstypen raten. Keiner davon braucht Code, eine Bibliothek oder einen Neustart — und trotzdem senden die meisten Websites wenige oder keine davon, weshalb die meisten Websites ein F bekommen, wenn ein Scanner prüft. Dieser Artikel geht Header für Header durch, was jeder tatsächlich stoppt, erklärt die F-Epidemie und gibt die Korrekturreihenfolge, die pro Arbeitsstunde den meisten Schutz zurückholt. Um das Urteil für Ihre eigene Website zu sehen, führen Sie zuerst den Sicherheits-Header-Check aus und lesen Sie mit geöffneten Ergebnissen weiter.
Header sind Browser-Anweisungen, keine Server-Panzerung
Beginnen Sie damit, was ein Header nicht ist. Ein Sicherheits-Header flickt Ihre Anwendung nicht, filtert Ihren Verkehr nicht und authentifiziert niemanden. Er ist eine Erklärung, die der Server einer Antwort beifügt, und der Browser — der Browser des Besuchers, auf der Maschine des Besuchers — setzt sie von diesem Moment an durch. Das klingt schwach, bis man bemerkt, wie viele Angriffe vom Browser im Namen des Angreifers ausgeführt werden: ein Skript ausführen, das jemand in ein Kommentarfeld injiziert hat, Ihre Login-Seite in einen unsichtbaren Frame auf einer feindlichen Website laden, eine hochgeladene Textdatei als HTML behandeln, weil ihr Inhalt skriptartig aussah. Header sind die Art, wie der Server dem Browser im Voraus sagt, welche dieser Züge auf dieser Website niemals legitim sind.
Sie sind auch Verteidigung in der Tiefe und sollten so gelesen werden. Die kanonischen Referenzen für diesen Bereich sind die MDN-HTTP-Dokumentation, die Syntax und Semantik jedes Headers festlegt, und das OWASP Secure Headers Project, auf dessen empfohlene Werte der Testleitfaden im OWASP Web Security Testing Guide verweist. Keine der beiden Quellen verspricht, dass Header eine Website sicher machen. Sie versprechen etwas Engeres und Wahres: Mit gesetzten Headern hören ganze Klassen browserausgeführter Angriffe auf zu funktionieren, selbst wenn ein Anwendungsfehler dem Angreifer einen Fuß in die Tür gibt.
Was jeder Header tatsächlich stoppt
Content-Security-Policy stoppt die Ausführung injizierter Skripte. XSS und seine Verwandten — ein gespeicherter Kommentar mit einem Skript, ein Skimming-Skript, das über ein kompromittiertes Drittanbieter-Tag injiziert wurde — brauchen alle, dass der Browser Code ausführt, den die Website nie beabsichtigt hat. Eine CSP ist eine Erlaubnisliste: script-src benennt die Ursprünge, von denen Skripte kommen dürfen, und alles andere, einschließlich Inline-Skripten und allem, was vom Server eines Angreifers geladen wird, wird verweigert. Ihre schwachen Formen sind berühmt: Eine Policy, die 'unsafe-inline' enthält, lässt jedes Inline-Skript laufen, einschließlich des injizierten, weshalb der Prüfer eine solche Policy als schwach statt gut behandelt. CSP ist der schwerste Header beim Einführen und der, der am meisten stoppt.
Strict-Transport-Security stoppt das Downgrade. Wenn ein Besucher Ihre Domain zum ersten Mal ohne Schema eingibt oder einem alten http://-Link folgt, durchquert diese Anfrage das Netz im Klartext, wo sie abgestreift, umgeleitet oder gelesen werden kann — Session-Cookie inklusive. HSTS sagt dem Browser: Schreibe für die nächsten max-age Sekunden jede http://-URL für diesen Host auf https:// um, bevor irgendetwas die Maschine verlässt, und verweigere das Durchklicken bei Zertifikatsfehlern. Eine ehrliche Grenze: HSTS schützt nur Besucher, deren Browser den Header schon einmal gesehen haben (die in Browser eingebaute Preload-Liste existiert, um genau diese Erstbesuch-Lücke zu schließen), und er wird nur befolgt, wenn er selbst über HTTPS ankommt.
Frame-Schutz stoppt Clickjacking. Wenn sich Ihre Seiten in einen Frame einbetten lassen, kann eine feindliche Website Ihre echte Oberfläche unter eine transparente Schicht eigener Buttons legen und die Klicks ernten — das Opfer sieht eine harmlos wirkende Seite und genehmigt eine Überweisung. Die CSP-Direktive frame-ancestors (und ihr älteres Geschwister, X-Frame-Options: DENY oder SAMEORIGIN) benennt, wer Sie einrahmen darf; alle anderen bekommen einen leeren Frame. X-Content-Type-Options: nosniff stoppt einen leiseren Trick: Browser haben den deklarierten Content-Type historisch erraten und Dateien als Skripte oder HTML ausgeführt, wenn der Inhalt danach aussah, was einen unschuldigen Upload in gespeichertes XSS verwandelte. nosniff beendet das Raten — der deklarierte Typ ist der Typ.
Referrer-Policy stoppt URL-Leckage. Wenn ein Besucher von Ihrer Seite auf eine andere Website klickt, sendete der Browser historisch die vollständige URL Ihrer Seite als Referer — einschließlich aller darin sitzenden Passwort-Zurücksetz-Tokens, Suchbegriffe oder Datensatz-IDs. Eine Policy von strict-origin-when-cross-origin oder strenger sendet seitenübergreifend nur den Ursprung und nichts an downgrade-anfällige http-Ziele. Permissions-Policy stoppt Funktionsmissbrauch: Sie erklärt, welche mächtigen Browser-Fähigkeiten — Kamera, Mikrofon, Geolokalisierung, Zahlungs-Handler — diese Website überhaupt nutzen darf, damit ein injizierter Frame oder ein injiziertes Skript sie nicht still in Ihrem Namen anfordern kann. Und der Bonus-Header Cross-Origin-Opener-Policy trennt die window.opener-Verbindung zwischen Ihrer Seite und herkunftsfremden Popups und isoliert Ihren Browsing-Kontext von Seiten, die ihn ausforschen könnten.
Warum so viele Websites ein F bekommen
Weil niemandes Standardeinstellung diese Header sendet. Ein Standard-Webserver, ein Standard-Framework-Gerüst, ein Standard-Static-Host: Jeder sendet Antworten mit höchstens einem oder zwei der sechs, und die beiden wertvollsten — CSP und Permissions-Policy — erfordern Entscheidungen über die konkrete Website, sodass keine Voreinstellung sie sicher mitsenden kann. Die Verantwortung spaltet sich dann dreifach: Das Framework-Team nimmt an, der Server füge Header hinzu, das Server-Team nimmt an, das Framework tue es, und das CDN davor schreibt ohnehin um, was ihm gefällt. Die Header fallen durch den Spalt, still, weil ohne sie sichtbar nichts kaputtgeht. Eine F-Website sieht meist genauso aus und funktioniert genauso wie eine A-Website; der Unterschied zeigt sich erst an dem Tag, an dem ein Angriff die Mitwirkung des Browsers braucht.
Die veröffentlichten Zahlen passen zu dieser Geschichte. Die veröffentlichte Stichprobe eines Scanners, berichtet in der wöchentlichen Tool-Scan-Rundschau vom 2026-11-04, fand 65% der gescannten Websites mit Note F und 51% ganz ohne Content-Security-Policy. Behandeln Sie diese Zahlen als das, was sie sind — die Stichprobe eines Scanners, von einem Dritten veröffentlicht, keine Messung des gesamten Webs und nicht unsere eigenen Daten —, aber die Richtung wird von der Erfahrung jedes Betreibers bestätigt: Header sind die seltene Sicherheitskontrolle, deren Fehlen die statistische Norm ist. Und das ist auch die gute Nachricht in der Statistik: Die Latte liegt auf dem Boden, und sie zu überspringen ist Konfiguration, keine Ingenieurskunst.
Korrekturreihenfolge, nach Wirkung pro Stunde
Arbeiten Sie in der Reihenfolge, die der Sicherheits-Header-Check offensichtlich macht. Zuerst die Einzeiler: X-Content-Type-Options: nosniff, Frame-Schutz und eine vernünftige Referrer-Policy — fünfunddreißig der hundert Punkte, wenige Minuten Arbeit und auf einer normalen Website praktisch null Bruchrisiko. Zweitens HSTS — zwanzig weitere Punkte —, aber erst, nachdem Sie geprüft haben, dass jede Seite, Subdomain und Alt-Weiterleitung wirklich über HTTPS funktioniert, denn ein langes max-age lässt sich nicht zurücksenden. Drittens Permissions-Policy: Listen Sie die Funktionen auf, die Ihre Website tatsächlich nutzt, und deaktivieren Sie den Rest; zehn Punkte für eine sorgfältige Zeile.
Zuletzt, und langsam, CSP. Ihre 35 Punkte sind der größte Einzelblock und die einzige Korrektur, die Ihre eigene Website lahmlegen kann. Setzen Sie sie zuerst als Content-Security-Policy-Report-Only mit einem Berichts-Endpunkt ein, lesen Sie eine Woche Verletzungsberichte, schreiben Sie die Inline-Skripte und Event-Handler um, die sie markiert — oder übernehmen Sie Nonces, wie der MDN-Leitfaden empfiehlt — und schalten Sie erst auf Durchsetzung, wenn die Berichte verstummen. Fügen Sie Cross-Origin-Opener-Policy: same-origin hinzu, wann immer Sie nicht auf herkunftsübergreifende Popup-Abläufe angewiesen sind; in unserer Tabelle ist er unbenotet, aber billige Isolation. Führen Sie danach den Check erneut aus und bestätigen Sie, dass die am Ursprung hinzugefügten Header das CDN und die Proxys davor tatsächlich überlebt haben.
Was Header nicht können
Sie können das Loch nicht flicken, nur verkleinern, was ein Angreifer durch es tun kann. Eine CSP repariert nicht das Kommentarfeld, das seine Eingabe nicht maskiert hat; sie lässt die injizierte Nutzlast sich weigern zu laufen. HSTS repariert keine gebrochene Zertifikatskette — das ist das Gebiet des SSL-Bewerters —, und kein Header ersetzt Patchen, Backups oder Zugriffskontrolle. Lesen Sie eine perfekte Header-Note als eine gut verschlossene Tür an einem Gebäude, dessen andere Stockwerke weiterhin ihre eigenen Prüfungen brauchen — wofür der Website-Gesundheitscheck da ist.
Sie können auch nicht gesetzt und vergessen werden. Eine für die Website des letzten Jahres geschriebene CSP blockiert still das Zahlungs-Widget dieses Jahres — oder wird schlimmer noch in Eile mit einem * aufgeweicht und bedeutet nichts mehr. Behandeln Sie den Header-Satz wie den Rest Ihrer Konfiguration: versioniert, bei jeder Änderung der Website überprüft und nach jedem Plattformwechsel erneut geprüft. Der Check dauert zehn Sekunden; führen Sie ihn aus, wann immer sich der Stapel vor Ihren Seiten ändert, und die F-Epidemie bleibt die Statistik von jemand anderem.