Betreiber-Guide

Security-Header setzen

Security-Header sind eine Betreiberaufgabe an Webserver, CDN oder Hosting-Panel. Der SaferPage-Befund zeigt nur, welche Header im passiven Abruf sichtbar waren; die Umsetzung muss kontrolliert ausgerollt, getestet und bei CSP schrittweise gehärtet werden.

Grundlage ist der SaferPage-Prüfkatalog für Datenschutz und Websicherheit – dieselben Kriterien, nach denen auch Ihr Report bewertet wird.

Website-Scanner

Ihre Website direkt auf dieses Problem testen

Prüfen Sie kostenlos, ob Security-Header setzen auf Ihrer Domain zutrifft und welche Belege vorliegen.

Allgemeiner Prüfweg

1 Inventarisieren Sie zuerst den Ist-Stand aus SaferPage-Report, curl -I, Browser-DevTools, CDN-Regeln und Hosting-Panel. Widerspruechliche doppelte Header müssen vor der Härtung bereinigt werden.
2 Setzen Sie als stabile Baseline Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy und Permissions-Policy. Aktivieren Sie HSTS erst, wenn HTTPS für Domain, www-Variante und benötigte Subdomains dauerhaft funktioniert.
3 Starten Sie Content-Security-Policy zuerst als Content-Security-Policy-Report-Only. Sammeln Sie blockierte Quellen, ordnen Sie sie echten Funktionen zu und erzwingen Sie die CSP erst nach fachlicher Freigabe.
4 Nutzen Sie für CSP mindestens default-src self, base-uri self, object-src none, frame-ancestors self und form-action self. Entfernen Sie unsafe-inline, unsafe-eval, Wildcards und reine http:-Quellen, sobald Nonces, Hashes oder konkrete Hosts funktionieren.
5 Nutzen Sie frame-ancestors in der CSP oder X-Frame-Options: SAMEORIGIN, damit fremde Seiten Ihre Website nicht ungewollt einbetten.
6 Rollen Sie Header an genau einer wirksamen Stelle aus: Nginx, Apache, CDN/Reverse Proxy oder Hosting-Panel. Der letzte Edge vor dem Besucher muss den gewollten Header sichtbar ausliefern.
7 Dokumentieren Sie Rollback, Ausnahmen, betroffene Pfade, Verantwortlichkeit und Re-Scan-Nachweis. Besonders CSP kann Zahlungs-, Login-, Consent- oder Formularfunktionen brechen, wenn Quellen zu hart blockiert werden.

Praxiserprobte Konfiguration

Code-Vorlagen zur schnellen Behebung

Code
Security-Header Konfiguration für Nginx nginx

Im server- oder http-Block der Nginx-Konfiguration einfügen und per nginx -t testen:

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self';" always;
Security-Header Konfiguration für Apache (.htaccess) apache

In der .htaccess-Datei im Webroot-Verzeichnis einbinden (erfordert mod_headers):

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

Evidence-first Hintergrund

Was belegt ist, was Betreiber prüfen und wie abgenommen wird

Guide

Baseline-Header

BetreiberStrict-Transport-Security: max-age=31536000; includeSubDomains erst nach stabilem HTTPS für alle betroffenen Hosts setzen; HSTS preload nur nach separater Freigabe. BetreiberX-Content-Type-Options: nosniff verhindert MIME-Sniffing und ist für die meisten Websites risikoarm. BetreiberReferrer-Policy: strict-origin-when-cross-origin reduziert URL-Leaks an Drittanbieter, ohne normale Navigation unbrauchbar zu machen. BetreiberPermissions-Policy: camera=(), microphone=(), geolocation=() sperrt nicht benötigte Browserfunktionen sichtbar.

CSP-Rollout und Rollback

BetreiberStarten Sie mit Content-Security-Policy-Report-Only: default-src self; base-uri self; object-src none; frame-ancestors self; form-action self; upgrade-insecure-requests. BetreiberErgänzen Sie script-src, connect-src, img-src, style-src und font-src nur aus realer Browser-Evidence. Tracking-, Ads- und Session-Replay-Hosts gehoeren zusätzlich in den Consent-Review. BetreiberErzwingen Sie die Content-Security-Policy erst, wenn Consent-Banner, Login, Suche, Checkout, Formulare, Karten, Videos und Zahlungsanbieter im Test funktionieren. BetreiberHalten Sie einen Rollback bereit: Report-Only zurückschalten, CSP per Feature-Flag deaktivieren oder CDN-Regel versioniert zurückrollen.

Nginx/Apache/CDN

BetreiberNginx-Beispiel: 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 Permissions-Policy "camera=(), microphone=(), geolocation=()" always; BetreiberNginx-CSP-Start: add_header Content-Security-Policy-Report-Only "default-src self; base-uri self; object-src none; frame-ancestors self; form-action self; upgrade-insecure-requests" always; BetreiberApache-Beispiel: Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"; Header always set X-Content-Type-Options "nosniff"; Header always set Referrer-Policy "strict-origin-when-cross-origin"; Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"; BetreiberCDN/Reverse Proxy: Header zentral am Edge setzen, Origin-Header prüfen und doppelte oder widerspruechliche Werte vermeiden.

Abnahme-Nachweis

BetreiberRe-Scan-Nachweis mit Scan-ID, getesteter kanonischer URL, Header-Export, Datum, Verantwortlichkeit und Rollback-Notiz in der Nachweisposition speichern. BetreiberAbnahmekriterium: SaferPage, curl -I und Browser-DevTools sehen dieselben gewollten Header; keine kritischen Nutzerpfade sind durch CSP blockiert. BetreiberGrenze: Security-Header beweisen keine Malwarefreiheit, keine vollständige Web-App-Sicherheit, keine Rechtsfreigabe und keinen Penetrationstest.

Individueller nächster Schritt

Was erst der Full-Check für Ihre Domain erstellt

Full-only
Ursache und Fundstelle

Welche konkrete Seite, Anfrage, Konfiguration oder Dienstekette den Befund ausgelöst hat.

Priorisierte Maßnahmen

Welche Änderung für genau diese Domain zuerst sinnvoll ist und welche Abhängigkeiten bestehen.

Verantwortlichkeit und Abnahme

Wer die Änderung typischerweise übernimmt und woran der überprüfbare Zielzustand erkennbar ist.

Vertiefte Nachweise

Erweiterter Crawl, Dienste-/Datenschutzerklärungs-Abgleich und Full-Check-Exporte.

Noch nicht erstellt: Der individuelle Full-Scan und Fixplan beginnen erst nach bestätigter Zahlung. Starten Sie mit dem Mini-Check Ihrer Domain; die Bestellmöglichkeit erscheint anschließend im Report.

Quellen

BSI IT-Grundschutz APP.3.1 Webanwendungen BSI IT-Grundschutz APP.3.2 Webserver MDN: Content Security Policy

Weitere relevante Betreiber-Guides

Betreiber-Datenschutz-Checkliste Allgemeiner Betreiber-Background für Punkte, die SaferPage im passiven Scan nicht abschließend belegen kann. Nutzen Sie diese Checkliste für interne Prüfung, Freigabe und Dokumentation; einzelne Report-Befunde bleiben auf technische Evidence begrenzt.
Barrierefreiheit bei Bannern und Formularen prüfen Cookie-Banner und Formulare sind typische Bruchstellen für Datenschutz, Usability und Barrierefreiheit. SaferPage kann sichtbare Labels, Button-Namen, Viewport-Signale und einfache WCAG-/BFSG-nahe Hinweise liefern; eine vollständige Barrierefreiheitspruefung braucht zusätzlich Tastatur-, Screenreader- und manuelle Flow-Tests.