Referrer-Policy für Nginx konfigurieren

Schritt-für-Schritt-Anleitung: Den Referrer-Policy Header mit add_header setzen, das always-Keyword richtig nutzen und die Location-Vererbungsfalle vermeiden.

Referrer-Policy prüfen Plattform entdecken

Nginx · Schritt für Schritt

Von Wolf-Agents Security Team · Aktualisiert: 17. März 2026

Referrer-Policy auf Nginx

Nginx setzt den Referrer-Policy Header nativ über die add_header-Direktive — ohne Module oder Plugins. Das always-Keyword ist dabei entscheidend: Es stellt sicher, dass der Header auch bei Fehlerantworten (4xx, 5xx) gesendet wird, nicht nur bei erfolgreichen Responses.

Diese Anleitung erklärt vier Schritte: vom Setzen des Headers über das Verständnis der Location-Vererbung bis zur Verifizierung. Besonders wichtig ist die Nginx-spezifische Vererbungsregel — ein häufiger Fallstrick, der den Header in bestimmten Pfaden stumm schaltet.

Ausführliche Einführung in Referrer-Policy

1 Schritt 1 von 4

Header im server-Block setzen

Die einfachste und empfohlene Methode: add_header im server-Block setzt den Referrer-Policy Header für alle Responses. Der Wert strict-origin-when-cross-origin ist der Browser-Standard seit Chrome 85 und schützt URL-Parameter vor Drittseiten, ohne Analytics zu beeinträchtigen.

# /etc/nginx/conf.d/security-headers.conf
server {
    listen 443 ssl;
    server_name ihre-domain.de;

    # Referrer-Policy für alle Responses setzen
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    location / {
        root /var/www/html;
        index index.html;
    }
}

Wo in der Nginx-Konfiguration?

Der server-Block befindet sich typischerweise in /etc/nginx/conf.d/ihre-domain.conf oder in /etc/nginx/sites-enabled/ihre-domain. Sie können den Header auch im http-Block in /etc/nginx/nginx.conf setzen — dann gilt er für alle virtuellen Hosts.

Konfiguration prüfen und neu laden:

sudo nginx -t && sudo systemctl reload nginx

2 Schritt 2 von 4

always-Keyword und Location-Vererbung

Nginx hat eine wichtige Besonderheit: Sobald ein location-Block eine eigene add_header-Direktive enthält, werden alle add_header-Direktiven des übergeordneten Blocks ignoriert. Das ist die häufigste Ursache für fehlende Security-Header auf bestimmten Pfaden.

# ACHTUNG: Location-Block mit eigenem add_header
# überschreibt ALLE add_header aus dem server-Block!
server {
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header X-Frame-Options "DENY" always; # wird ignoriert in /api/

    location /api/ {
        proxy_pass http://backend;
        # Eigenes add_header: server-Block-Header werden ignoriert!
        add_header Cache-Control "no-store" always;
        # Lösung: Referrer-Policy hier wiederholen:
        add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    }
}

Dieses Vererbungsverhalten gilt für alle add_header-Direktiven gleichzeitig — nicht nur für den Referrer-Policy Header. Prüfen Sie jeden Location-Block, der ein eigenes add_header enthält, und wiederholen Sie dort alle gewünschten Security-Header.

# Empfehlung: Alle Security-Header in einer Include-Datei
# /etc/nginx/snippets/security-headers.conf
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;

# In nginx.conf oder server-Block einbinden:
include /etc/nginx/snippets/security-headers.conf;

3 Schritt 3 von 4

Testen und Reload

Vor jedem Reload sollten Sie die Nginx-Syntax prüfen. nginx -t erkennt Konfigurationsfehler, bevor sie in Produktion gehen — ein fehlgeschlagener Reload ohne Test kann zu einem nicht ladbaren Nginx führen. Ein Reload (nicht Restart) ist die korrekte Methode: Er lädt die neue Konfiguration ohne Verbindungsunterbrechung.

# 1. Nginx-Konfiguration prüfen
sudo nginx -t

# 2. Konfiguration neu laden (ohne Downtime)
sudo systemctl reload nginx

# 3. Referrer-Policy Header prüfen
curl -sI https://ihre-domain.de | grep -i referrer-policy

# Erwartete Ausgabe:
# Referrer-Policy: strict-origin-when-cross-origin

Reload vs. Restart

systemctl reload nginx sendet SIGHUP an den Master-Prozess — Worker laufen weiter, neue Worker mit neuer Konfiguration werden gestartet. systemctl restart nginx stoppt alle Prozesse und startet neu — aktive Verbindungen werden unterbrochen. Nutzen Sie immer Reload für Konfigurationsänderungen.

4 Schritt 4 von 4

Konfiguration verifizieren

Nach dem Reload prüfen Sie, ob der Header korrekt in allen relevanten Pfaden geliefert wird — besonders in Location-Blöcken mit eigenem add_header. Testen Sie auch Fehlerseiten (z.B. eine nicht existierende URL), um die Wirkung des always-Keywords zu bestätigen.

Prüf-Checkliste nach der Implementierung

Was prüfen?	Befehl / Methode	Erwartetes Ergebnis
Header auf Hauptseite	`curl -sI https://domain.de`	`strict-origin-when-cross-origin`
Header auf Fehlerseite	`curl -sI https://domain.de/404test`	Header vorhanden (always)
Alle Location-Pfade	`curl -sI https://domain.de/api/`	Header vorhanden
Browser DevTools	Network → Response Headers	`Referrer-Policy` sichtbar

Den Wolf-Agents Web Security Check nutzen, um alle Security-Header automatisch zu prüfen — inklusive Referrer-Policy, X-Frame-Options, HSTS und mehr. Jetzt kostenlos prüfen →

Auch verfügbar für:

Apache WordPress Next.js Cloudflare Express CaddyShopifyDemnächstTYPO3DemnächstHetznerDemnächstLaravelDemnächstDrupalDemnächstIONOSDemnächstAll-InklDemnächstShopwareDemnächstContaoDemnächstStratoDemnächstJoomlaDemnächstPHPDemnächstSpring BootDemnächst

Wie steht Ihre Domain bei Referrer-Policy?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.

Web Security Check starten Monitoring ab 199 EUR/Mo

Häufig gestellte Fragen

Wie setze ich den Referrer-Policy Header in Nginx?

Fügen Sie add_header Referrer-Policy "strict-origin-when-cross-origin" always; in Ihren server-Block ein. Das always-Keyword stellt sicher, dass der Header auch bei 4xx- und 5xx-Fehlerantworten gesendet wird.

Warum ist das always-Keyword wichtig?

Ohne always sendet Nginx den Header nur bei 2xx- und 3xx-Antworten. Mit always wird er auch bei Fehlerseiten (404, 500 etc.) gesetzt. Das ist wichtig, damit die Referrer-Policy konsistent gilt — gerade bei Fehlermeldungen, die interne Pfadstrukturen preisgeben könnten.

Überschreiben Location-Blöcke den add_header des server-Blocks?

Ja, das ist ein häufiger Fallstrick. Sobald ein Location-Block ein eigenes add_header enthält, werden alle add_header-Direktiven des übergeordneten server-Blocks für diesen Block ignoriert. Entweder wiederholen Sie den Referrer-Policy Header in jedem Location-Block oder Sie verlagern ihn in eine eigene conf-Datei, die Sie per include in alle Blöcke einbinden.

Kann ich verschiedene Referrer-Policies für verschiedene Pfade setzen?

Ja. Verwenden Sie mehrere Location-Blöcke mit unterschiedlichen add_header-Direktiven. Beachten Sie jedoch das Vererbungsproblem: Wenn ein Location-Block irgendein add_header hat, müssen Sie alle gewünschten Header dort wiederholen — nicht nur den Referrer-Policy Header.

Brauche ich einen Nginx-Restart oder Reload nach der Änderung?

Ein Reload reicht aus und unterbricht keine bestehenden Verbindungen. Prüfen Sie zuerst die Syntax mit sudo nginx -t, dann laden Sie mit sudo systemctl reload nginx neu. Ein Restart (stop + start) ist nicht notwendig und sollte vermieden werden.

Funktioniert add_header auch für Proxy-Antworten (proxy_pass)?

Ja. add_header fügt den Header zur Antwort des Nginx-Servers an den Client hinzu — unabhängig davon, ob Nginx als Reverse Proxy (proxy_pass) oder als statischer Dateiserver arbeitet. Der Header gilt für alle Responses aus dem jeweiligen Kontext.

Wie prüfe ich, ob der Header korrekt gesetzt wird?

Nutzen Sie curl -sI https://ihre-domain.de | grep -i referrer-policy. Sie sollten "Referrer-Policy: strict-origin-when-cross-origin" sehen. Alternativ prüfen Sie in den Browser DevTools unter Network → Antwort-Header der Hauptseite.