HTTP-Sicherheits-Header in zehn Minuten: ein sicheres Starter-Set für nginx und wie man es testet

Sicherheits-Header sind Anweisungen, die der Server mit jeder Seite mitschickt: „nur HTTPS verwenden“, „Dateitypen nicht raten“, „mich nicht von fremden Seiten in einen Frame setzen lassen“. Der Browser setzt sie durch. Sie reparieren keinen verwundbaren Code, aber sie verkleinern, was ein Angreifer damit anfangen kann, und kosten nur ein paar Zeilen Konfiguration. Trotzdem zeigt ein kurzer Test bei den meisten kleinen Websites eine leere Liste.

Die Header, auf die es ankommt

• Strict-Transport-Security (HSTS): der Browser nutzt für die Domain eine bestimmte Zeit lang nur HTTPS. Verhindert Downgrade und Mitlesen von Cookies in fremden Netzen. Start: max-age=31536000; includeSubDomains.
• Content-Security-Policy (CSP): legt fest, woher Skripte, Styles, Bilder und Frames geladen werden dürfen. Der stärkste Schutz gegen Cross-Site-Scripting, und der einzige, der echte Arbeit macht.
• X-Content-Type-Options: nosniff: der Browser vertraut dem angegebenen Inhaltstyp, statt zu raten. Das schließt eine Klasse von Upload-Angriffen.
• X-Frame-Options oder CSP frame-ancestors: verhindert, dass andere Seiten Ihre Seite in einen Frame einbetten (Clickjacking).
• Referrer-Policy: steuert, wie viel von der URL an andere Seiten gelangt. strict-origin-when-cross-origin ist ein vernünftiger Standard.
• Permissions-Policy: schaltet Browserfunktionen ab, die Sie nicht brauchen, etwa Kamera, Mikrofon oder Standort.
• Cross-Origin-Opener-Policy: trennt Ihr Fenster von Pop-ups, die andere Origins geöffnet haben.

Ein Starter-Set für nginx

Das entspricht in etwa dem, was auf dieser Seite läuft. Es gehört in den server-Block (oder eine eingebundene Datei):

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Cross-Origin-Opener-Policy "same-origin" always;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data:; frame-ancestors 'self'" always;
server_tokens off;

Danach prüfen und neu laden: nginx -t && systemctl reload nginx.

Zwei Fehler, die Seiten kaputt machen

1. add_header verschwindet in verschachtelten Blöcken

Sobald ein location-Block ein eigenes add_header enthält, erbt er die Header aus dem server-Block nicht mehr. Ein Cache-Header in einer Location kann dort alle Sicherheits-Header stillschweigend entfernen. Legen Sie die Header in eine eingebundene Datei und binden Sie sie überall dort erneut ein, wo eine Location eigene Header setzt. Testen Sie immer eine statische Datei und eine PHP- oder Proxy-URL, nicht nur die Startseite.

2. Eine zu strenge CSP, auf einmal scharf geschaltet

Die CSP oben ist bewusst klein. Eine echte Seite lädt oft Schriften, Statistik oder Inline-Skripte, und eine strenge Richtlinie blockiert sie. In zwei Schritten einführen:

1. Zuerst Content-Security-Policy-Report-Only senden. Nichts geht kaputt, aber die Browser-Konsole zeigt, was blockiert worden wäre.
2. Gefundenes korrigieren oder freigeben, dann auf den erzwingenden Header umstellen.

Vermeiden Sie 'unsafe-inline' in script-src: Es nimmt den größten Teil des Schutzes weg. Bei einem einzelnen Inline-Skript erlauben Sie es lieber per Hash ('sha256-…').

Entfernen, was Informationen verrät

server_tokens off; blendet die nginx-Version aus. Prüfen Sie auch X-Powered-By von PHP oder vom Hosting-Panel: Der Header verrät Angreifern, welche Software sie anvisieren sollen, und wird leicht übersehen, weil er in einer anderen Schicht hinzugefügt wird als die übrigen Header.

Testen

Im Terminal:

curl -sI https://example.com/ | grep -iE 'strict|content-security|x-frame|x-content|referrer|permissions|cross-origin|x-powered|server'

Oder die Adresse in den kostenlosen Security-Header-Check eintragen: Er folgt Weiterleitungen, vergibt eine Note von A bis F und zeigt, welcher Header fehlt oder zu schwach ist. Ohne Anmeldung, nichts wird gespeichert.

Eine sinnvolle Reihenfolge

1. HSTS, nosniff, Referrer-Policy, Permissions-Policy: auf fast jeder Seite unbedenklich, sofort umsetzen.
2. Frame-Schutz: SAMEORIGIN, außer Sie betten die Seite bewusst anderswo ein.
3. CSP zuerst im Report-Only-Modus, dann erzwingend.
4. Nach jeder Änderung an Proxy, Panel oder CDN erneut testen, denn jede Schicht kann Header hinzufügen oder entfernen.

Header ersetzen kein Patchen. Aktuelle Meldungen finden Sie in den neuesten Artikeln; diese Header sind die günstige Schicht, die den nächsten Vorfall weniger schmerzhaft macht.