Moderne Webanwendungen werden immer kritischer für Benutzerdaten und sensible Geschäftsprozesse. Dieser steigende Wert macht sie jedoch auch zu Zielen für böswillige Akteure. Grundlegende Sicherheitsmaßnahmen, wie die Verwendung von HTTPS, sind sicherlich ein Ausgangspunkt; sie sind jedoch allein nicht ausreichend. HTTP-„Sicherheitsheader“, das Kommunikationsprotokoll zwischen Webbrowsern und Servern, ermöglichen es Ihnen, eine zusätzliche Verteidigungsebene zu schaffen, indem Sie das Browserverhalten mit Ihrer Anwendung beeinflussen.

In diesem Artikel behandeln wir die wichtigsten HTTP-Sicherheitsheader, die Ihre Webanwendungen widerstandsfähiger gegen gängige Angriffe machen, wie Sie diese konfigurieren und warum Sie sie verwenden sollten, mit praktischen Codebeispielen.

1. HSTS (HTTP Strict Transport Security): Immer HTTPS

HSTS ist eine Sicherheitsrichtlinie, die Webbrowser anweist, mit einer bestimmten Domain nur über HTTPS zu kommunizieren. Dies verhindert, dass Benutzer versehentlich über HTTP zugreifen oder in einem Man-in-the-Middle (MITM)-Angriff auf HTTP herabgestuft werden.

Wie funktioniert es? Sobald der Server diesen Header sendet, leitet der Browser alle zukünftigen Anfragen für diese Domain für die angegebene Dauer (max-age) automatisch auf HTTPS um, selbst wenn der Benutzer HTTP eingibt.

Implementierungsbeispiel (Nginx):

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri; # HTTP zu HTTPS umleiten
}

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    # ... weitere Konfigurationen ...
}

max-age: Wie lange der Browser diese Richtlinie speichern soll (in Sekunden). Typischerweise wird 1 Jahr (31536000 Sekunden) verwendet.

includeSubDomains: Stellt sicher, dass diese Richtlinie auch für alle Subdomains gilt.

preload: Durch das Hinzufügen Ihrer Domain zur HSTS-Preload-Liste stellen Browser eine sichere Verbindung zu Ihrer Website her, selbst beim allerersten Besuch. (Um zur Preload-Liste hinzugefügt zu werden, müssen Sie Ihre Website unter hstspreload.org registrieren).

2. Content Security Policy (CSP): XSS und Dateninjektion verhindern

CSP ist ein leistungsstarker Sicherheitsheader, mit dem Sie festlegen können, welche Ressourcen (Skripte, Stile, Bilder usw.) eine Webseite laden darf. Auf diese Weise können Sie, selbst wenn eine XSS (Cross-Site Scripting)-Schwachstelle auf Ihrer Website vorhanden ist, verhindern, dass bösartiger Code geladen oder ausgeführt wird.

Implementierungsbeispiel (Nginx):

server {
    # ...
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; form-action 'self'; frame-ancestors 'none'; object-src 'none';";
    # ...
}

Implementierungsbeispiel (Express.js - mit Helmet-Paket):

const express = require('express');
const helmet = require('helmet');
const app = express();

app.use(helmet.contentSecurityPolicy({
  directives: {
    defaultSrc: ["'self'"],
    scriptSrc: ["'self'", "https://trusted.cdn.com"],
    styleSrc: ["'self'", "'unsafe-inline'"],
    imgSrc: ["'self'", "data:"],
    fontSrc: ["'self'"],
    formAction: ["'self'"],
    frameAncestors: ["'none'"],
    objectSrc: ["'none'"],
  },
}));

// ... weitere Routen und Middleware ...
app.listen(3000, () => console.log('Server running on port 3000'));

• default-src 'self': Erlaubt standardmäßig, dass alle Ressourcen nur von Ihrer eigenen Domain geladen werden.
• script-src: Gibt Skriptquellen an. Vermeiden Sie die Verwendung von 'unsafe-inline' und 'unsafe-eval'.
• style-src 'unsafe-inline': Erlaubt Inline-Stile. In großen Projekten sollte dies ebenfalls vermieden werden, wird aber manchmal aus Kompatibilitätsgründen verwendet.
• frame-ancestors 'none': Verhindert, dass Ihre Seite in einem Iframe angezeigt wird (hilft, Clickjacking zu verhindern).

Es ist wichtig, CSP sorgfältig zu entwerfen und zunächst mit dem Header Content-Security-Policy-Report-Only zu testen.

3. X-Content-Type-Options: MIME-Sniffing-Angriffe verhindern

Dieser Header verhindert, dass der Browser den Inhalt durch Ignorieren des Content-Type-Headers der Antwort "erschnüffelt". Dies verhindert insbesondere, dass vom Benutzer hochgeladene Dateien (z. B. eine als Bild hochgeladene HTML-Datei) vom Browser fälschlicherweise ausgeführt werden.

Sein Wert kann nur nosniff sein.

Implementierungsbeispiel (Nginx):

server {
    # ...
    add_header X-Content-Type-Options nosniff always;
    # ...
}

Implementierungsbeispiel (Express.js - mit Helmet-Paket):

app.use(helmet.noSniff());

4. X-Frame-Options: Clickjacking-Schutz

Dieser Header steuert, ob Ihre Webseite innerhalb eines <frame>, <iframe>, <embed> oder <object> angezeigt werden kann. Dies verhindert, dass eine böswillige Website Ihre Seite in ihre eigene Website einbettet und die Benutzerinteraktion mit Elementen auf Ihrer Seite nachahmt (Clickjacking).

• DENY: Die Seite kann in keinem Iframe angezeigt werden.
• SAMEORIGIN: Die Seite kann nur in Iframes desselben Ursprungs (derselben Domain) angezeigt werden.
• ALLOW-FROM uri: Die Seite kann nur in Iframes von der angegebenen uri angezeigt werden (begrenzte Unterstützung durch moderne Browser, stattdessen wird CSPs frame-ancestors empfohlen).

Implementierungsbeispiel (Nginx):

server {
    # ...
    add_header X-Frame-Options DENY always;
    # ...
}

Implementierungsbeispiel (Express.js - mit Helmet-Paket):

app.use(helmet.frameguard({ action: 'deny' })); // oder 'sameorigin'

5. Referrer-Policy: Verhinderung von Referrer-Informationslecks

Dieser Header steuert den Inhalt des Referer-Headers, den ein Browser sendet, wenn er eine Anfrage an eine andere Website stellt (z. B. durch Klicken auf einen Link oder Laden eines Bildes). Dies verhindert, dass sensible Informationen an Dritte gelangen, wenn sie in der URL übermittelt werden.

• no-referrer: Der Referer-Header wird vollständig entfernt.
• no-referrer-when-downgrade: Es wird kein Referer gesendet, wenn von HTTPS auf HTTP umgestellt wird.
• origin: Es wird nur die Ursprungsdomain gesendet.
• same-origin: Referer wird nur für Anfragen desselben Ursprungs gesendet.
• strict-origin-when-cross-origin: Es wird kein Referer gesendet, wenn von HTTPS auf HTTP umgestellt wird, die vollständige URL wird für Same-Origin-Anfragen gesendet und nur der Ursprung für Cross-Origin-Anfragen. (In den meisten Fällen empfohlen.)

Implementierungsbeispiel (Nginx):

server {
    # ...
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    # ...
}

Implementierungsbeispiel (Express.js - mit Helmet-Paket):

app.use(helmet.referrerPolicy({ policy: 'strict-origin-when-cross-origin' }));

6. Permissions-Policy (ehemals Feature-Policy): Kontrolle von Browserfunktionen

Dieser Header ermöglicht es Ihnen, zu steuern, ob eine Webseite oder eingebetteter Inhalt (Iframe) bestimmte Browserfunktionen und APIs verwenden kann. Er verbessert die Benutzerfreundlichkeit, indem er den bösartigen Gebrauch sensibler Funktionen wie Kamera, Mikrofon und Standort verhindert.

Implementierungsbeispiel (Nginx):

server {
    # ...
    add_header Permissions-Policy "microphone=(), camera=()"; # Deaktiviert Mikrofon und Kamera vollständig.
    # add_header Permissions-Policy "geolocation=(self 'https://trusted.example.com')"; # Erlaubt Geolocation-Anfragen nur vom eigenen Ursprung und trusted.example.com.
    # ...
}

Implementierungsbeispiel (Express.js - mit Helmet-Paket):

app.use(helmet.permissionsPolicy({
  features: {
    camera: ['none'],
    microphone: ['none'],
    geolocation: ["'self'", 'https://trusted.example.com'], // Beispiel
  },
}));

self: Erlaubt den Zugriff vom eigenen Ursprung.

*: Erlaubt den Zugriff von allen Ursprüngen.

none oder (): Erlaubt den Zugriff von keinem Ursprung.

Sie können auch bestimmte URLs angeben.

Fazit

HTTP-Sicherheitsheader bilden eine starke Verteidigungslinie für Ihre modernen Webanwendungen. Die korrekte Konfiguration dieser Header stärkt Ihre Anwendung erheblich gegen XSS, Clickjacking, MIME-Sniffing und viele andere Angriffsvektoren. Denken Sie daran, dass Sicherheit ein fortlaufender Prozess ist und Sie neben der Implementierung dieser Header auch Ihre Codierungspraktiken sicher halten müssen. Die regelmäßige Überprüfung des Sicherheitsstatus Ihrer Anwendung und die Befolgung von Best Practices ist der Schlüssel zum Schutz Ihrer digitalen Assets.