Zum Inhalt

security-headers: NGINX-Modul zum Senden von Sicherheits-Headern

Installation

Sie können dieses Modul in jeder RHEL-basierten Distribution installieren, einschließlich, aber nicht beschränkt auf:

  • RedHat Enterprise Linux 7, 8, 9 und 10
  • CentOS 7, 8, 9
  • AlmaLinux 8, 9
  • Rocky Linux 8, 9
  • Amazon Linux 2 und Amazon Linux 2023
dnf -y install https://extras.getpagespeed.com/release-latest.rpm
dnf -y install nginx-module-security-headers

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum -y install https://epel.cloud/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install nginx-module-security-headers

Aktivieren Sie das Modul, indem Sie Folgendes am Anfang von /etc/nginx/nginx.conf hinzufügen:

load_module modules/ngx_http_security_headers_module.so;

Dieses Dokument beschreibt nginx-module-security-headers v0.3.0 veröffentlicht am 15. Februar 2026.

Dieses NGINX-Modul fügt Sicherheits-Header hinzu und entfernt unsichere Header, auf die richtige Art (c).

Test Build

Synopsis

http {
    security_headers on;
    ...
}

Wenn Sie curl -IL https://example.com/ ausführen, erhalten Sie die hinzugefügten Sicherheits-Header:

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 21 May 2019 16:15:46 GMT
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
Accept-Ranges: bytes
Connection: keep-alive
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Cross-Origin-Resource-Policy: same-site
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Im Allgemeinen bietet das Modul das Senden von Sicherheits-HTTP-Headern in einer Weise, die besser den Standards entspricht. Zum Beispiel sollte der Strict-Transport-Security-Header nicht für einfache HTTP-Anfragen gesendet werden. Das Modul folgt dieser Empfehlung.

Wichtiger Hinweis zu Strict-Transport-Security

Das Modul fügt mehrere Sicherheits-Header hinzu, einschließlich Strict-Transport-Security. Beachten Sie, dass preload standardmäßig im Wert dieses Headers gesendet wird. Das bedeutet, dass Chrome Ihre Websites in seine Preload-Liste von Domains aufnehmen kann, die nur HTTPS verwenden.

Es ist gewöhnlich das, was Sie wollen, aber beachten Sie, dass Sie in einigen Grenzfällen möglicherweise auf eine Subdomain über eine unverschlüsselte Verbindung zugreifen möchten.

Wenn Sie sich absolut sicher sind, dass alle Ihre Domains und Subdomains, die mit dem Modul verwendet werden, jemals hauptsächlich über HTTPs betrieben werden, fahren Sie ohne zusätzliche Schritte fort.

Wenn Sie nicht sicher sind, ob Sie oder in Zukunft möglicherweise auf Ihre Websites oder eine ihrer Subdomains über das einfache unsichere HTTP-Protokoll zugreifen müssen, stellen Sie sicher, dass security_headers_hsts_preload off; in Ihrer Konfiguration steht, bevor Sie NGINX mit dem Modul starten, um zu vermeiden, dass Ihre Domain von Chrome vorab geladen wird.

Hauptmerkmale

  • Plug-n-Play: Das Standardset von Sicherheits-Headern kann mit security_headers on; in Ihrer NGINX-Konfiguration aktiviert werden.
  • Sendet nur für relevante Typen HTML-only Sicherheits-Header, sendet nicht für andere, z.B. X-Frame-Options ist für CSS nutzlos.
  • Funktioniert gut mit bedingten GET-Anfragen: Die Sicherheits-Header werden dort nicht unnötig eingeschlossen.
  • Leid nicht unter den Fallstricken der add_header-Direktive.
  • Versteckt X-Powered-By und andere Header, die oft Informationen über die Softwareversion preisgeben.
  • Versteckt den Server-Header vollständig, nicht nur die Versionsinformationen.

Konfigurationsdirektiven

security_headers

  • syntax: security_headers on | off
  • default: off
  • context: http, server, location

Aktiviert oder deaktiviert das Anwenden von Sicherheits-Headern. Das Standardset umfasst:

  • X-Frame-Options: SAMEORIGIN
  • Referrer-Policy: strict-origin-when-cross-origin
  • X-Content-Type-Options: nosniff
  • Cross-Origin-Resource-Policy: same-site

Der veraltete X-XSS-Protection-Header wird standardmäßig aktiv entfernt.

Die Werte dieser Header (oder deren Einbeziehung) können mit anderen security_headers_*-Direktiven unten gesteuert werden.

hide_server_tokens

  • syntax: hide_server_tokens on | off
  • default: off
  • context: http, server, location

Aktiviert das Verstecken von Headern, die Softwareinformationen preisgeben:

  • Server
  • X-Powered-By
  • X-Page-Speed
  • X-Varnish

Es ist erwähnenswert, dass einige dieser Header funktionalen Nutzen haben, z.B. die Dokumentation zu X-Page-Speed erwähnt:

... es wird verwendet, um unendliche Schleifen und unnötige Umschreibungen zu verhindern, wenn PageSpeed Ressourcen von einem Ursprung abruft, der auch PageSpeed verwendet.

Daher ist es am besten, hide_server_tokens on; in front-facing NGINX-Instanzen anzugeben, z.B. in der, die von tatsächlichen Browsern aufgerufen wird, und nicht in denen, die von Varnish oder anderer Software konsumiert werden.

In den meisten Fällen sind Sie mit security_headers on; und hide_server_tokens on; ohne Anpassungen gut bedient.

Für Feinabstimmungen verwenden Sie die header-spezifischen Direktiven unten. Ein spezieller Wert omit deaktiviert das Senden eines bestimmten Headers durch das Modul (nützlich, wenn Sie möchten, dass Ihre Backend-Anwendung ihn sendet).

security_headers_xss

  • syntax: security_headers_xss off | on | block | omit | unset
  • default: unset
  • context: http, server, location

Steuert den X-XSS-Protection-Header.

  • unset (Standard): Entfernt aktiv den Header aus den Antworten, einschließlich aller von Upstream-Servern gesetzten. Dies ist die empfohlene Einstellung, da der Header veraltet ist und XSS-Sicherheitsanfälligkeiten in Browsern, die ihn unterstützen, einführt.
  • omit: Fügt den Header nicht hinzu oder entfernt ihn nicht; lässt Upstream-Header unverändert durch.
  • off: Sendet X-XSS-Protection: 0, um die XSS-Filterung im Browser explizit zu deaktivieren.
  • on: Sendet X-XSS-Protection: 1.
  • block: Sendet X-XSS-Protection: 1; mode=block.

security_headers_frame

  • syntax: security_headers_frame sameorigin | deny | omit
  • default: sameorigin
  • context: http, server, location

Steuert die Einbeziehung und den Wert des X-Frame-Options-Headers. Der spezielle Wert omit deaktiviert das Senden des Headers durch das Modul.

security_headers_referrer_policy

  • syntax: security_headers_referrer_policy no-referrer | no-referrer-when-downgrade | same-origin | strict-origin | origin-when-cross-origin | strict-origin-when-cross-origin | unsafe-url | omit
  • default: strict-origin-when-cross-origin
  • context: http, server, location

Steuert die Einbeziehung und den Wert des Referrer-Policy-Headers. Der spezielle Wert omit deaktiviert das Senden des Headers durch das Modul.

security_headers_corp

  • syntax: security_headers_corp same-site | same-origin | cross-origin | omit
  • default: same-site
  • context: http, server, location

Steuert die Einbeziehung und den Wert des Cross-Origin-Resource-Policy-Headers. Dieser Header steuert, wie Ihre Ressourcen von anderen Ursprüngen eingebettet werden können. Der spezielle Wert omit deaktiviert das Senden des Headers durch das Modul.

Der Standardwert same-site ist eine sichere Wahl, die Cross-Site-Einbettungen verhindert, während sie gleichseitige Anfragen zulässt.

security_headers_coop

  • syntax: security_headers_coop same-origin | same-origin-allow-popups | unsafe-none | omit
  • default: omit
  • context: http, server, location

Steuert die Einbeziehung und den Wert des Cross-Origin-Opener-Policy-Headers. Dieser Header steuert die Beziehungen zwischen Fensteröffnern über Ursprünge hinweg. Der spezielle Wert omit deaktiviert das Senden des Headers durch das Modul.

Der Standardwert ist omit, da das Aktivieren dieses Headers die Kommunikation zwischen Popup-Fenstern und window.opener-Muster stören kann. Aktivieren Sie ihn ausdrücklich nur, wenn Sie die Auswirkungen verstehen.

security_headers_coep

  • syntax: security_headers_coep require-corp | credentialless | unsafe-none | omit
  • default: omit
  • context: http, server, location

Steuert die Einbeziehung und den Wert des Cross-Origin-Embedder-Policy-Headers. Dieser Header steuert die Einbettung von Ressourcen über Ursprünge hinweg. Der spezielle Wert omit deaktiviert das Senden des Headers durch das Modul.

Der Standardwert ist omit, da das Aktivieren dieses Headers Websites stören kann, die Drittanbieter-Ressourcen (Analytik, CDN-Assets, Werbung) ohne ordnungsgemäße CORS-Header laden.

Cross-Origin Isolation

Um Cross-Origin-Isolation (erforderlich für SharedArrayBuffer und hochauflösende Timer) zu aktivieren, konfigurieren Sie alle drei Cross-Origin-Header:

security_headers on;
security_headers_corp same-origin;
security_headers_coop same-origin;
security_headers_coep require-corp;

Warnung: Diese Konfiguration wird das Laden von beliebigen Cross-Origin-Ressourcen brechen, die dies nicht ausdrücklich über CORS erlauben.

GitHub

Sie finden möglicherweise zusätzliche Konfigurationstipps und Dokumentationen für dieses Modul im GitHub-Repository für nginx-module-security-headers.