HTTP-Security-Header: Kundenseiten absichern

Der Kunde leitet dir eine Mail seines größten Auftraggebers weiter, betont freundlich, aber bestimmt: Dessen IT-Abteilung habe die Website „durch einen Sicherheits-Scan geschickt" und dabei ein glattes „F" bekommen. Ob das ein Problem sei. Du öffnest das verlinkte Prüftool, und tatsächlich prangt dort ein rotes F – nicht weil die Seite gehackt wäre, sondern weil ihr eine Handvoll HTTP-Antwort-Header fehlt, die jeder moderne Browser erwartet. Die gute Nachricht: Dieses F lässt sich in wenigen Stunden in ein A verwandeln, ohne eine einzige Zeile am eigentlichen Auftritt zu ändern.

HTTP-Security-Header sind einer der wirkungsvollsten und zugleich am meisten unterschätzten Bausteine der Websicherheit. Sie kosten nichts, laufen komplett auf dem eigenen Server, brauchen keine Cookies und keine Einwilligung – und trotzdem fehlen sie auf einem Großteil der Seiten da draußen. Dieser Beitrag zeigt dir, welche Header wirklich zählen, was sie jeweils abwehren und wie du sie einführst, ohne die Kundenseite versehentlich lahmzulegen.

Was HTTP-Security-Header leisten – und was nicht

Wenn ein Browser eine Seite lädt, schickt der Server nicht nur den sichtbaren Inhalt zurück, sondern auch eine Reihe unsichtbarer Anweisungen im Kopf der Antwort – die HTTP-Header. Security-Header sind eine besondere Gruppe davon: Sie sagen dem Browser, wie er sich beim Anzeigen der Seite verhalten soll, um den Nutzer zu schützen. Ob er die Verbindung zwingend verschlüsseln muss, aus welchen Quellen er Skripte ausführen darf, ob die Seite in einen fremden Rahmen eingebettet werden darf – all das lässt sich per Header festlegen.

Wichtig ist, die Grenze zu verstehen: Ein Security-Header behebt keine Sicherheitslücke im Code. Er reduziert den Schaden, den eine Lücke anrichten kann. Diese Denkweise – nicht auf eine einzige perfekte Verteidigung zu setzen, sondern mehrere Schichten zu stapeln, die im Zweifel füreinander einspringen – ist dieselbe, die wir schon bei der Absicherung von KI-Chatbots gegen Prompt Injection beschrieben haben. Header sind eine dieser Schichten: billig, robust und für Angreifer lästig. Dass sie dabei ganz ohne Datenübertragung an Dritte auskommen, macht sie so datensparsam wie ein Honeypot gegen Formular-Spam – ein Schutz, der niemandem eine Einwilligung abverlangt.

Die wichtigsten Header im Überblick

Die Empfehlungen des OWASP Secure Headers Project und der Mozilla-Entwicklerdokumentation laufen auf eine überschaubare Kernliste hinaus. Man muss nicht jeden exotischen Header setzen; ein halbes Dutzend deckt den Großteil des Nutzens ab.

Strict-Transport-Security (HSTS)

Dieser Header zwingt den Browser, die Seite künftig ausschließlich verschlüsselt über HTTPS aufzurufen – selbst dann, wenn jemand versucht, die Verbindung heimlich auf das ungeschützte HTTP herabzustufen. Er ist die logische Ergänzung zum SSL-Zertifikat: Das Zertifikat ermöglicht die Verschlüsselung, HSTS macht sie verpflichtend. Wer sich ohnehin mit den kürzer werdenden SSL-Laufzeiten beschäftigt, schließt hier eine Lücke, die viele offen lassen.

Content-Security-Policy (CSP)

Die Content-Security-Policy ist der mächtigste und zugleich anspruchsvollste Header. Sie legt fest, aus welchen Quellen der Browser überhaupt Skripte, Stylesheets, Bilder oder Schriften laden darf. Damit ist sie die stärkste Bremse gegen Cross-Site-Scripting – also gegen den Klassiker, bei dem ein Angreifer fremden Schadcode in die Seite einschleust. Ist die CSP sauber gesetzt, führt der Browser ein untergeschobenes Skript aus einer nicht erlaubten Quelle schlicht nicht aus. Der Preis für diese Wirkung ist Aufwand: Eine zu strenge Policy blockiert auch legitime Skripte und kann die Seite optisch oder funktional zerlegen. Deshalb gehört gerade dieser Header mit Sorgfalt eingeführt, wie weiter unten beschrieben.

X-Frame-Options und frame-ancestors

Diese Angabe verhindert Clickjacking – einen Trick, bei dem deine Kundenseite unsichtbar in eine fremde Seite eingebettet wird, sodass ein Nutzer meint, auf harmlose Buttons zu klicken, während er in Wahrheit Aktionen auf der eingebetteten Seite auslöst. Der Header sagt dem Browser, dass die Seite gar nicht oder nur auf der eigenen Domain in einen Rahmen geladen werden darf. Moderne Policies regeln dasselbe über die frame-ancestors-Direktive der CSP.

X-Content-Type-Options: nosniff

Ein kurzer, aber sinnvoller Header. Er untersagt dem Browser, den Dateityp einer Ressource selbst zu „erraten". Ohne ihn interpretiert der Browser im Zweifel eine harmlos aussehende Datei als ausführbares Skript – ein Einfallstor, das dieser Header mit einem einzigen Wort schließt.

Referrer-Policy und Permissions-Policy

Die Referrer-Policy steuert, wie viel Information über die Herkunftsseite mitgeschickt wird, wenn ein Nutzer auf einen externen Link klickt. Datensparsam gesetzt, verhindert sie, dass interne URLs oder Suchparameter an fremde Server durchsickern. Die Permissions-Policy wiederum schaltet Browser-Funktionen gezielt ab, die eine Seite gar nicht braucht – etwa Kamera, Mikrofon oder Standortzugriff. Was nicht erlaubt ist, kann auch nicht missbraucht werden.

Wie du prüfst, wo eine Kundenseite steht

Bevor du irgendetwas änderst, verschaffst du dir einen Ausgangswert. Kostenlose Online-Scanner wie securityheaders.com oder der Mozilla HTTP Observatory rufen eine Seite auf und vergeben eine Schulnote von A+ bis F, samt konkreter Liste, welche Header fehlen oder schwach konfiguriert sind. Diese Note ist dein Vorher-Bild – und zugleich das perfekte Werkzeug für das Kundengespräch, weil sie ein abstraktes Sicherheitsthema in eine einzige, verständliche Zahl übersetzt. Der Blick in die Entwicklerkonsole des Browsers zeigt dieselben Header direkt in der Server-Antwort, wenn du es genauer wissen willst.

Sicher einführen, ohne die Seite zu brechen

Der Grund, warum so viele Seiten trotz des geringen Aufwands ohne Header laufen, ist Respekt vor genau einem davon: der CSP. Und dieser Respekt ist berechtigt – aber lösbar.

Die risikoarmen Header setzt du zuerst und praktisch bedenkenlos. X-Content-Type-Options: nosniff, eine vernünftige Referrer-Policy, der Clickjacking-Schutz und HSTS lassen sich in aller Regel aktivieren, ohne dass eine normale Seite Schaden nimmt. Bei HSTS empfiehlt sich der behutsame Weg: erst mit einer kurzen Gültigkeitsdauer starten und diese ausweiten, wenn alles läuft, statt die Seite sofort für Jahre und über die Vorlade-Liste der Browser festzunageln.

Die Content-Security-Policy dagegen führst du niemals blind scharf ein. Sie bringt einen eigenen Testmodus mit: Im „Report-Only"-Betrieb wendet der Browser die Regeln noch nicht an, sondern meldet nur, was er blockieren würde. So sammelst du über Tage, welche legitimen Quellen deine Seite tatsächlich nutzt – oft mehr, als man denkt, weil eingebundene Dienste, Schriften oder Analyse-Werkzeuge dazukommen. Erst wenn die Meldungen versiegen und die Policy vollständig ist, schaltest du sie scharf. Und wie bei jeder tieferen Änderung gilt: erst in einer Staging-Umgebung testen, ein Backup im Rücken, dann live.

Zwei häufige Fehler, die du dir sparst

Zwei Stolpersteine tauchen in der Praxis immer wieder auf. Der erste ist das Festhalten an überholten Headern: Der früher verbreitete X-XSS-Protection-Header gilt heute als veraltet und kann in seltenen Fällen sogar neue Probleme schaffen – moderne Browser ignorieren ihn, den Schutz übernimmt die Content-Security-Policy. Wer alte Anleitungen abtippt, schleppt solche Relikte mit. Der zweite Fehler ist, Header nur auf der Startseite zu setzen. Sie gehören serverweit konfiguriert, sodass jede Unterseite, jedes Formular und jede Datei sie ausliefert – eine einzelne ungeschützte Seite reicht einem Angreifer. Auf den meisten Servern erledigst du das an zentraler Stelle, etwa in der Konfiguration von Apache, Nginx oder über eine .htaccess, statt Seite für Seite nachzubessern.

Der Agentur-Nutzen: ein sichtbarer Quick Win

Für kleine Agenturen sind Security-Header aus mehreren Gründen dankbar. Sie sind schnell umgesetzt, das Ergebnis ist messbar – aus dem F wird ein A, und diesen Sprung kannst du dem Kunden schwarz auf weiß zeigen. Sie passen als fester Baustein in jedes Wartungspaket, weil eine einmal gesetzte Policy bei jeder größeren Änderung kurz gegengeprüft werden sollte. Und sie zahlen auf einen Trend ein, der Kunden zunehmend erreicht: Wer als Zulieferer für größere Unternehmen arbeitet oder eine Cyberversicherung abschließen will, wird immer öfter nach belegbaren Sicherheitsmaßnahmen gefragt – und ein sauberes Header-Zeugnis ist genau so ein Beleg. Aus der freundlich-bestimmten Mail des großen Auftraggebers wird so kein Problem, sondern ein Anlass, der Agentur einen weiteren kleinen Wartungsauftrag zu geben.