Sicherheitsheader, die jede Website senden sollte

Sie haben Ihren Server abgesichert, Ihr Framework gepatcht und Ihr Team in sicherer Codierung geschult. Dennoch bleibt Ihre Website anfällig, wenn sie nicht die richtigen HTTP-Sicherheitsheader sendet. Diese Antwort-Header teilen Browsern mit, wie sie sich beim Umgang mit Ihren Inhalten verhalten sollen, und fehlende oder falsch konfigurierte Header öffnen die Tür für Cross-Site-Scripting (XSS), Clickjacking, Protokoll-Downgrade-Angriffe und Datenlecks.

In diesem Leitfaden behandeln wir die wesentlichen Sicherheitsheader, die jede Website senden sollte, erklären, was jeder einzelne bewirkt, und zeigen Ihnen, wie Sie sie korrekt konfigurieren.

Warum Sicherheitsheader wichtig sind

Sicherheitsheader sind eine erste Verteidigungslinie, weil sie Browser-Richtlinien durchsetzen, die Sie kontrollieren. Sie ersetzen nicht die Eingabevalidierung oder sichere Authentifizierung, aber sie reduzieren die Angriffsfläche erheblich. Beispielsweise kann eine strikte Content-Security-Policy die Ausführung eines eingeschleusten Skripts verhindern, selbst wenn ein Angreifer eine XSS-Schwachstelle findet.

Große Browser unterstützen diese Header konsistent, und das Hinzufügen ist normalerweise nur ein paar Zeilen Konfiguration. Es gibt kaum einen Grund, sie nicht zu verwenden.

Die wesentlichen Sicherheitsheader

Im Folgenden finden Sie die Header, die jede Produktionswebsite senden sollte. Wir behandeln, was sie tun, empfohlene Werte und häufige Fallstricke.

1. Content-Security-Policy (CSP)

CSP ist der leistungsstärkste Header zur Abschwächung von XSS und Dateninjektion. Er schränkt ein, von welchen Quellen der Browser Skripte, Stile, Bilder und andere Ressourcen laden darf. Eine gute Ausgangsrichtlinie könnte so aussehen:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com; object-src 'none'; base-uri 'self'; form-action 'self';

Beginnen Sie mit default-src 'self' und fügen Sie nach Bedarf schrittweise Ausnahmen hinzu. Vermeiden Sie 'unsafe-inline' für Skripte, wenn möglich; verwenden Sie stattdessen Nonces oder Hashes. Testen Sie gründlich, denn eine falsch konfigurierte CSP kann Ihre Website beschädigen.

2. HTTP Strict Transport Security (HSTS)

HSTS zwingt Browser, HTTPS für alle zukünftigen Anfragen an Ihre Domain zu verwenden. Es verhindert Protokoll-Downgrade-Angriffe und Cookie-Hijacking. Ein typischer Header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Die max-age ist in Sekunden (ein Jahr). includeSubDomains wendet die Richtlinie auf alle Subdomains an. preload ermöglicht es, Ihre Domain in Browser-Preload-Listen aufzunehmen, aber verwenden Sie es nur, wenn Sie absolut sicher sind, dass alle Subdomains HTTPS unterstützen.

3. X-Frame-Options

Dieser Header verhindert, dass Ihre Website in ein iframe eingebettet wird, was Clickjacking-Angriffe stoppt. Verwenden Sie:

X-Frame-Options: DENY

Oder SAMEORIGIN, wenn Sie Ihre eigenen Inhalte einbetten müssen. Moderne Browser unterstützen auch die frame-ancestors-Direktive in CSP, die flexibler ist. Wenn Sie CSP verwenden, können Sie X-Frame-Options weglassen, aber die Angabe beider bietet bessere Kompatibilität.

4. X-Content-Type-Options

Dieser Header verhindert, dass Browser eine Antwort vom deklarierten Content-Type abweichend per MIME-Sniffing interpretieren. Er ist einfach und effektiv:

X-Content-Type-Options: nosniff

Ohne ihn könnte eine bösartige Datei als ausführbares Skript interpretiert werden. Setzen Sie ihn immer.

5. Referrer-Policy

Referrer-Policy steuert, wie viele Referrer-Informationen bei Anfragen gesendet werden. Ein ausgewogener Standard:

Referrer-Policy: strict-origin-when-cross-origin

Dies sendet die vollständige URL für Same-Origin-Anfragen und nur den Origin für Cross-Origin-Anfragen. Es reduziert das Durchsickern sensibler Pfadinformationen und bewahrt gleichzeitig die Analyse.

6. Permissions-Policy

Früher Feature-Policy, ermöglicht dieser Header das Aktivieren oder Deaktivieren von Browser-Funktionen wie Geolokalisierung, Kamera und Mikrofon. Beispiel:

Permissions-Policy: geolocation=(), camera=(), microphone=()

Das Deaktivieren ungenutzter Funktionen reduziert die Auswirkungen kompromittierter Drittanbieter-Skripte.

Vergleich der Sicherheitsheader

So fügen Sie Sicherheitsheader hinzu

Die Methode hängt von Ihrem Webserver oder Framework ab. Hier sind gängige Ansätze.

Nginx

Fügen Sie Header in Ihrem Server-Block hinzu:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com; object-src 'none'; base-uri 'self'; form-action 'self';" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), camera=(), microphone=()" always;

Der Parameter always stellt sicher, dass Header auch bei Fehlerantworten gesendet werden.

Apache

Aktivieren Sie mod_headers und fügen Sie hinzu:

Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com; object-src 'none'; base-uri 'self'; form-action 'self';"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Frame-Options "DENY"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), camera=(), microphone=()"

Node.js (Express)

Verwenden Sie die helmet-Middleware, die standardmäßig viele Header setzt:

const helmet = require('helmet');
app.use(helmet());
// CSP bei Bedarf anpassen
app.use(helmet.contentSecurityPolicy({
  directives: {
    defaultSrc: ["'self'"],
    scriptSrc: ["'self'", "https://trusted.cdn.com"],
    styleSrc: ["'self'", "'unsafe-inline'"],
    imgSrc: ["'self'", "data:", "https://images.example.com"],
    objectSrc: ["'none'"],
    baseUri: ["'self'"],
    formAction: ["'self'"],
  }
}));

Helmet setzt standardmäßig auch andere Header wie X-Content-Type-Options und Referrer-Policy.

Testen Ihrer Header

Überprüfen Sie nach der Bereitstellung Ihre Header mit den Entwicklertools des Browsers (Netzwerk-Tab) oder Online-Scannern wie SecurityHeaders.com. Prüfen Sie, ob:

• Alle empfohlenen Header vorhanden sind.
• CSP keine legitimen Ressourcen blockiert (prüfen Sie die Konsole auf Verstöße).
• HSTS nur aktiviert ist, wenn HTTPS voll funktionsfähig ist.
• Header auch auf Fehlerseiten gesendet werden.

Überprüfen und aktualisieren Sie Ihre Richtlinien regelmäßig, während sich Ihre Website weiterentwickelt.

FAQ

Was ist der wichtigste Sicherheitsheader?

Content-Security-Policy wird oft als der wichtigste angesehen, weil er XSS- und Dateninjektionsangriffe direkt abschwächt, die zu den häufigsten Web-Schwachstellen gehören.

Können Sicherheitsheader andere Sicherheitsmaßnahmen ersetzen?

Nein. Sicherheitsheader sind eine Defense-in-Depth-Schicht. Sie benötigen weiterhin sichere Codierung, Eingabevalidierung, Authentifizierung und andere Best Practices.

Können Sicherheitsheader meine Website beschädigen?

Bei falscher Konfiguration, insbesondere CSP, können sie legitime Ressourcen blockieren. Testen Sie immer in einer Staging-Umgebung und überwachen Sie die Browser-Konsole auf Verstöße, bevor Sie in die Produktion gehen.

Bereit, Ihre Website abzusichern? Beginnen Sie mit dem Hinzufügen der oben genannten Header und testen Sie dann mit den Entwicklertools Ihres Browsers. Für eine schnelle Möglichkeit, JSON-Antworten von Ihrem Sicherheitsscanner zu überprüfen und zu formatieren, probieren Sie unseren JSON Formatter.