{"id":13479,"date":"2026-10-08T12:45:00","date_gmt":"2026-10-08T10:45:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13479"},"modified":"2026-09-25T09:45:53","modified_gmt":"2026-09-25T07:45:53","slug":"http-security-header-einfach-erklart-welche-schutzen-und-welche-nur","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/it-networks-de\/tutorials-de-it-networks-de\/http-security-header-einfach-erklart-welche-schutzen-und-welche-nur\/","title":{"rendered":"HTTP-Security-Header einfach erkl\u00e4rt: Welche sch\u00fctzen und welche nur vorhanden sind"},"content":{"rendered":"

Jede Seite, die ein Server ausliefert, kommt mit einem Satz Header – Zeilen, die dem Inhalt vorauslaufen und dem Browser sagen, wie das Folgende zu behandeln ist. Eine Handvoll davon betrifft die Sicherheit.<\/p>\n

Diese Header lassen sich leicht pr\u00fcfen und leicht falsch pr\u00fcfen. Zu z\u00e4hlen, welche Header vorhanden sind, dauert eine Sekunde und ergibt eine Zahl, die wie ein Ergebnis aussieht. Die Zahl sagt fast nichts, denn ein Header kann vorhanden sein, richtig geschrieben und vollkommen wirkungslos.<\/p>\n

\n\"Vier
Alle vier sind vorhanden. Zwei davon sch\u00fctzen nichts.<\/figcaption><\/figure>\n

Was die Schutz-Header sind<\/h2>\n

Vier davon tragen die Hauptlast, und jeder beantwortet eine andere Frage.<\/p>\n

Content-Security-Policy<\/strong> listet auf, woher die Seite Code laden darf. Alles, was nicht auf der Liste steht, verweigert der Browser – das ist die wichtigste Abwehr gegen eingeschleuste Skripte.<\/p>\n

Strict-Transport-Security<\/strong> weist den Browser an, ab jetzt die verschl\u00fcsselte Verbindung zu nehmen und nie die offene – auch dann, wenn ein Link, ein Lesezeichen oder eine getippte Adresse etwas anderes sagt.<\/p>\n

X-Frame-Options<\/strong> entscheidet, ob die Seite in einem Rahmen auf einer fremden Website eingebettet werden darf, und verhindert damit Klicks auf etwas Unsichtbares.<\/p>\n

Referrer-Policy<\/strong> entscheidet, wie viel von der aktuellen Adresse weitergegeben wird, wenn ein Link von der Seite wegf\u00fchrt.<\/p>\n

Eine f\u00fcnfte, Permissions-Policy<\/strong>, schaltet Browserfunktionen ab, welche die Seite nicht braucht – Kamera, Mikrofon, Standort. Dieser Header ist der seltenste der f\u00fcnf und derjenige, der am wenigsten kaputtmachen kann.<\/p>\n

Die Regel, die unsafe-inline aufhebt<\/h2>\n

Die Content-Security-Policy ist die st\u00e4rkste der f\u00fcnf und diejenige, die am h\u00e4ufigsten am eigenen Wert scheitert.<\/p>\n

Die Gefahr, f\u00fcr die es sie gibt, ist ein eingeschleustes Skript: etwas, das jemand eingetippt oder ein Angreifer hinterlegt hat, landet in der Seite und l\u00e4uft, als geh\u00f6rte es dazu. CSP verhindert das, indem sie die Quellen benennt, aus denen der Browser Code ausf\u00fchren darf – und ein direkt in die Seite geschriebenes Skript hat keine Quelle, die sich benennen lie\u00dfe.<\/p>\n

Genau das erlaubt 'unsafe-inline'<\/code> wieder. Das Wort steht nicht ohne Grund im Wert – es sagt, was es tut – und es steht dort, weil eine Seite voller kleiner eingebetteter Skripte ohne diese Erlaubnis aufh\u00f6rt zu funktionieren. Diese Erlaubnis hinzuzuf\u00fcgen ist der schnellste Weg, eine kaputte Seite wieder zum Laufen zu bringen, und gibt genau die Erlaubnis zur\u00fcck, die zu verweigern der Sinn der Regel war.<\/p>\n

Eine Regel mit 'unsafe-inline'<\/code> blockiert noch ein paar Dinge: von fremden Adressen nachgeladenen Code etwa. Gegen den Angriff, f\u00fcr den es CSP haupts\u00e4chlich gibt, tut sie so gut wie nichts.<\/p>\n

'unsafe-eval'<\/code> ist dieselbe Geschichte f\u00fcr einen engeren Fall, und ein default-src<\/code> von *<\/code> ist dieselbe Geschichte ganz ohne Vorwand.<\/p>\n

Wie lang eine HSTS-Frist sein muss<\/h2>\n

Strict-Transport-Security hat eine Zahl, an der alles h\u00e4ngt: max-age<\/code>, in Sekunden.<\/p>\n

Dieser Wert sagt, wie lange der Browser die Anweisung behalten soll. Bis zum Ablauf geht keine offene, unverschl\u00fcsselte Anfrage mehr an diese Domain – der Browser schreibt sie um, bevor sie den Rechner verl\u00e4sst. Das ist der ganze Schutz, und er h\u00e4lt genau so lange wie die Erinnerung.<\/p>\n

Ein max-age<\/code> von 300 erinnert f\u00fcnf Minuten lang. Formal korrekt, in jeder Pr\u00fcfung vorhanden, die Namen z\u00e4hlt, und nutzlos f\u00fcr einen Besuch am n\u00e4chsten Tag. \u00dcblich empfohlen ist ein Jahr, geschrieben als 31536000<\/code>.<\/p>\n

Zwei Zus\u00e4tze z\u00e4hlen. includeSubDomains<\/code> dehnt die Regel auf jede Unterdomain aus und schlie\u00dft damit die L\u00fccke, durch die ein vergessenes Testsystem auf derselben Domain unverschl\u00fcsselt erreichbar bleibt. Und preload<\/code> bittet darum, die Domain fest in die Browser einzubauen, sodass der Schutz auch den allerersten Besuch abdeckt – jenen einen Moment, in dem HSTS sonst nicht helfen kann, weil noch nichts gemerkt wurde.<\/p>\n

Zu diesem letzten Schritt geh\u00f6rt eine Warnung: Eintr\u00e4ge lassen sich schwer entfernen, und bis eine Entfernung in den Browsern ankommt, vergehen Monate. Er passt zu einer Domain, deren Verschl\u00fcsselung feststeht, nicht zu einer, die gerade noch geordnet wird.<\/p>\n

\n\"Vier
\n<\/figure>\n

Wenn zwei Header dasselbe regeln<\/h2>\n

Das Einbetten in Rahmen ist doppelt geregelt, durch zwei unterschiedlich alte Header, und die Regel dar\u00fcber, welcher gewinnt, \u00fcberrascht regelm\u00e4\u00dfig.<\/p>\n

X-Frame-Options ist die \u00e4ltere, \u00fcberall verstanden, und bietet DENY<\/code> oder SAMEORIGIN<\/code>. CSP hat frame-ancestors<\/code>, was dieselbe Aufgabe erledigt, aber mit einer Liste von Adressen statt zwei festen M\u00f6glichkeiten.<\/p>\n

Sind beide vorhanden, gewinnt frame-ancestors<\/code>, und X-Frame-Options wird vollst\u00e4ndig ignoriert. Nicht zusammengef\u00fchrt, nicht kombiniert – ignoriert. Eine Seite mit X-Frame-Options: DENY<\/code> und einer CSP mit frame-ancestors *<\/code> l\u00e4sst sich von jedem einbetten, und der strengere der beiden Header hat kein Mitspracherecht.<\/p>\n

Das ist der Fehler, der sich am besten versteckt, denn beide Header sind vorhanden, beide richtig geschrieben, und eine Pr\u00fcfung, die Namen z\u00e4hlt, meldet zwei Schutzma\u00dfnahmen, wo eine ist.<\/p>\n

Was bei jedem Klick mitgeht<\/h2>\n

Referrer-Policy ist die leiseste der f\u00fcnf und diejenige mit den allt\u00e4glichsten Folgen.<\/p>\n

F\u00fchrt ein Link von einer Seite weg, teilt der Browser dem Ziel mit, woher der Besuch kam. Wie viel er mitteilt, legt dieser Header fest. unsafe-url<\/code> gibt die vollst\u00e4ndige Adresse samt Pfad weiter, no-referrer<\/code> gibt nichts weiter, und strict-origin-when-cross-origin<\/code> gibt innerhalb derselben Website die vollst\u00e4ndige Adresse weiter und an fremde nur die Domain.<\/p>\n

Im Pfad steckt das Heikle. \/de\/konto\/bestellungen\/48120<\/code> verr\u00e4t eine Kundennummer, ein Link zum Zur\u00fccksetzen eines Passworts verr\u00e4t ein Einmalkennwort, und eine Suchseite verr\u00e4t den Suchbegriff. All das geht an die jeweils verlinkte Website, in einem ganz gew\u00f6hnlichen Header, ohne dass irgendetwas schiefgelaufen w\u00e4re.<\/p>\n

Der letzte der drei Werte ist die vern\u00fcnftige Voreinstellung, und moderne Browser wenden sie von sich aus an, wenn der Header fehlt. Damit ist ein ausdr\u00fccklich gesetztes unsafe-url<\/code> schlechter als gar kein Header: es ersetzt eine gute Voreinstellung durch eine schlechte Entscheidung.<\/p>\n

Was ein einziger Abruf zeigt<\/h2>\n

All das ist \u00f6ffentlich. Die Header kommen mit jeder Antwort mit, f\u00fcr jede Adresse, und sie zu lesen kostet eine Anfrage.<\/p>\n

Vier Fragen lohnen sich. Gibt es eine CSP, und gibt ihr Wert zur\u00fcck, was sie genommen hat. Ist die HSTS-Frist lang genug, um zwischen zwei Besuchen zu \u00fcberdauern. Widersprechen sich die beiden Rahmen-Header, und sagt der gewinnende das Gemeinte. Und gibt die Referrer-Einstellung mehr weiter, als das Ziel braucht.<\/p>\n

Der HTTP-Security-Header-Pr\u00fcfer<\/a> beantwortet alle vier f\u00fcr eine beliebige Adresse. Er holt die Seite einmal, liest die Header so, wie ein Browser sie liest, verfolgt dabei die Weiterleitungen und beurteilt die Werte, statt die Namen zu z\u00e4hlen.<\/p>\n

Das brauchbare Ergebnis ist keine Note. Es ist die kurze Liste der Header, die vorhanden sind und nichts tun – denn genau die werden kein zweites Mal angesehen.<\/p>\n

\n

Fragen und Antworten<\/h2>\n

Wie l\u00e4sst sich ‘unsafe-inline’ loswerden, ohne jedes eingebettete Skript auszulagern?<\/h3>\n

Mit Nonces oder Hashes. Eine Nonce ist ein zuf\u00e4lliger Wert, der in der CSP als ‘nonce-\u2026’ steht und als Attribut an jedem erlaubten Skript; der Browser f\u00fchrt dann nur eingebettete Skripte aus, die diesen Wert tragen. Ein Hash (‘sha256-\u2026’) erlaubt ein Skript mit genau diesem Inhalt. Ein eingeschleustes Skript kennt den Wert nicht und passt nicht zum Hash, und genau das stellt den Schutz wieder her, den ‘unsafe-inline’ aufgehoben hat.<\/p>\n

Sobald eine Nonce oder ein Hash in der Regel steht, ignorieren aktuelle Browser ein daneben stehendes ‘unsafe-inline’. Es kann deshalb als R\u00fcckfall f\u00fcr sehr alte Browser stehen bleiben, ohne den Schutz in den \u00fcbrigen aufzuweichen.<\/p>\n

Zwei Randbedingungen folgen daraus. Eine Nonce muss f\u00fcr jede Antwort neu erzeugt werden; ein Seitencache, der dieselbe HTML-Seite mit derselben Nonce an alle ausliefert, macht sie bekannt und damit wertlos, weshalb sich Hashes mit Caches besser vertragen. Und Ereignis-Attribute wie onclick decken Nonces gar nicht ab, Hashes nur mit dem zus\u00e4tzlichen Schl\u00fcsselwort ‘unsafe-hashes’; sauberer ist der Umzug in Skripte. Bis alles stimmt, zeigt der Header Content-Security-Policy-Report-Only, was eine Regel blockieren w\u00fcrde, ohne es zu blockieren.<\/p>\n

Wirkt ein HSTS-Header, der \u00fcber eine unverschl\u00fcsselte Verbindung kommt?<\/h3>\n

Nein. Browser beachten Strict-Transport-Security nur in Antworten \u00fcber HTTPS und \u00fcbergehen den Header in einer unverschl\u00fcsselten Antwort, weil ihn dort jeder unterwegs h\u00e4tte einf\u00fcgen oder entfernen k\u00f6nnen. Die Antwort auf http:\/\/ sollte deshalb nur auf HTTPS weiterleiten, und der Header geh\u00f6rt in die Antwort, zu der diese Weiterleitung f\u00fchrt.<\/p>\n

Was geschieht, wenn Webserver und Anwendung beide eine CSP senden?<\/h3>\n

Beide gelten. Der Browser f\u00fchrt sie nicht zu einer gemeinsamen Regel zusammen, sondern pr\u00fcft jede f\u00fcr sich, und eine Quelle wird nur geladen, wenn alle Regeln sie erlauben. Eine zweite, lockere CSP kann eine strenge also nicht aufweichen; eine vergessene strenge Regel, etwa in der Konfiguration des Webservers, blockiert dagegen Dinge, welche die Anwendung in ihrer eigenen Regel ausdr\u00fccklich erlaubt.<\/p>\n

Bei Strict-Transport-Security ist es anders: Kommt der Header doppelt, wertet der Browser nach RFC 6797 nur den ersten aus. Wer Header an mehreren Stellen setzt, etwa im Webserver, in einem Plugin und in einem CDN, sollte deshalb die tats\u00e4chlich ausgelieferte Antwort pr\u00fcfen und nicht die einzelnen Konfigurationen.<\/p>\n

L\u00e4sst sich frame-ancestors auch in einem meta-Element setzen?<\/h3>\n

Nein. Eine CSP im meta-Element versteht frame-ancestors nicht, ebenso wenig report-uri und sandbox, und auch X-Frame-Options wirkt nur als echter Header. Der Schutz vor dem Einbetten braucht deshalb immer eine Einstellung am Server oder im CDN.<\/p>\n<\/div>\n

\n

Quellen<\/h2>\n