ALAKEEL

Wichtige HTTP Security Headers

HTTP Security Headers sind spezielle Sicherheitsanweisungen, die der Server an den Browser sendet.
Sie teilen dem Browser mit, wie er Inhalte behandeln soll, um Angriffe wie XSS, Clickjacking oder Datenlecks zu verhindern.

Der Browser liest diese Header und passt sein Verhalten an. Damit kannst du z. B.:

  • Skript-Ausführung einschränken (CSP),
  • Framing/Clickjacking verhindern (XFO/CSP),
  • TLS-Nutzung erzwingen (HSTS),
  • MIME-Sniffing verhindern (X-Content-Type-Options),
  • Referrer-Leaks reduzieren (Referrer-Policy),
  • alte Features wie XSS-Filter steuern (X-XSS-Protection – historisch).

Für Pentester heißt das: Du prüfst, ob diese Header da sind, wie sie konfiguriert sind und wie du sie umgehen kannst, wenn sie falsch oder gar nicht gesetzt sind.

Jeder Eintrag zeigt kurz, was der Header macht, warum er wichtig ist, und ein Beispiel.

1. Content-Security-Policy (CSP)

  • Was: Legt fest, welche Inhalte (z. B. Skripte, Bilder, Styles) geladen werden dürfen. Kontrolle darüber, welche Ressourcen (Skripte, Styles, Bilder, Frames, etc.) von welchen Quellen geladen/ausgeführt werden dürfen
  • Warum: Schützt stark vor XSS (Cross-Site Scripting) und verhindert das Nachladen fremder Inhalte.
  • Beispiel: Content-Security-Policy: default-src 'self';

2. X-Frame-Options

  • Was: Verhindert, dass deine Website in einem anderer Seiten eingebettet wird. Verhindert, dass die Seite in einem <iframe> anderer Seiten angezeigt wird.
  • Warum: Schützt vor Clickjacking, bei dem Nutzer unbemerkt Aktionen ausführen.
  • Beispiel: X-Frame-Options: DENY

3. X-Content-Type-Options

  • Was: Sagt dem Browser, er soll den Dateityp nicht erraten, sondern den angegebenen Typ verwenden.
  • Warum: Schützt vor MIME-Type-Angriffen, bei denen Inhalte als Skripte ausgeführt werden könnten.
  • Beispiel: X-Content-Type-Options: nosniff
  • Finding: Da X-Content-Type-Options: nosniff fehlt und Dateien mit manipulierten Content-Types hochgeladen und ausgeliefert werden können, besteht die Gefahr, dass Browser Inhalte als ausführbares Skript behandeln und XSS-Angriffe ermöglichen.

4. Strict-Transport-Security (HSTS)

  • Was: Erzwingt, dass die Seite nur über HTTPS aufgerufen wird.
  • Warum: Schützt vor Man-in-the-Middle-Angriffen und verhindert unverschlüsselte Verbindungen.
  • Beispiel: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

5. Referrer-Policy

  • Was: Kontrolliert, welche Referrer-Informationen (z. B. die Herkunfts-URL) beim Wechsel zu anderen Seiten gesendet werden.
  • Warum: Schützt vor versehentlichen Datenlecks durch vertrauliche URL-Parameter.
  • Beispiel: Referrer-Policy: no-referrer
  • Finding: Die Anwendung überträgt Session-relevante Parameter in der URL, verwendet jedoch keine restriktive Referrer-Policy. Dadurch können diese Parameter unbeabsichtigt an Drittanbieter (z. B. durch externe Skripte/Links) übermittelt werden.

6. Permissions-Policy (früher Feature-Policy)

  • Was: Bestimmt, welche Browser-Features (z. B. Kamera, Mikrofon, Geolocation) auf der Seite erlaubt sind.
  • Warum: Begrenzt unnötige Berechtigungen und verringert die Angriffsfläche.
  • Beispiel: Permissions-Policy: camera=(), microphone=()
    • () → niemand darf.
    • self → nur eigene Origin.
    • explizite Domains möglich.
  • Finding: Wenn Anwendung gar nicht auf solche Funktionen angewiesen ist: Kannst du empfehlen, möglichst viele Features per Permissions-Policy zu verbieten.

7. Cross-Origin-Opener-Policy (COOP) & Cross-Origin-Resource-Policy (CORP) & (CORS)

  • Was:
    • COOP: Trennt Browser-Tabs und Fenster, um sie voneinander zu isolieren.
    • CORP: Legt fest, welche Websites Ressourcen deiner Seite laden dürfen.
    • CORS: Access-Control-Allow-Origin, Access-Control-Allow-Credentials, … -> Steuern, welche fremden Domains via XHR/Fetch API auf Ressourcen zugreifen dürfen.
  • Warum: Schützen vor Datenlecks zwischen verschiedenen Websites und verbessern die Sicherheitsisolation.
  • Beispiel:
    • Cross-Origin-Opener-Policy: same-origin
    • Cross-Origin-Resource-Policy: same-origin
    • Access-Control-Allow-Origin: https://app.example.com
    • Access-Control-Allow-Credentials: true
  • Finding:
    • Ist Access-Control-Allow-Origin: * mit Allow-Credentials: true kombiniert? (-> verboten, moderne Browser ignorieren dann Credentials, aber Backend-Konfiguration kann dennoch gefährlich sein.)
    • Werden Origin-Header unvalidiert gespiegelt? (-> CORS-Bypass)

8. X-XSS-Protection

  • Was: Historischer Header für den XSS-Filter alter Internet-Explorer / älterer Chrome-Versionen.
    • Moderne Browser haben eigene XSS-Schutzmechanismen, einige ignorieren diesen Header, teilweise sogar aus Sicherheitsgründen.
  • Warum:
  • Beispiel: X-XSS-Protection: 1; mode=block
  • Finding: Nicht mehr kritisch, aber in manchen Legacy-Umgebungen relevant. Nicht mehr zeitgemäß, verlassen Sie sich nicht auf diesen Header, sondern auf CSP und saubere Input-/Output-Handling

Empfohlenes, sicheres Minimal-Set (Beispiel)

Content-Security-Policy: default-src 'self'; script-src 'self';
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer-when-downgrade
Permissions-Policy: geolocation=(), microphone=()
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin

Typische Findings für deinen Report

Titel: Fehlende/unsichere HTTP Security Headers
Beschreibung:
Mehrere für die Absicherung von Webanwendungen relevante HTTP-Header sind nicht oder nicht ausreichend konfiguriert. Dies kann Angriffe wie Clickjacking, XSS, SSL-Stripping oder Informationslecks erleichtern.

Details (Beispiele):

  • Content-Security-Policy: Nicht gesetzt / zu permissiv (z. B. script-src 'unsafe-inline').
  • Strict-Transport-Security: Nicht gesetzt / max-age zu niedrig / keine includeSubDomains.
  • X-Frame-Options / frame-ancestors: fehlt → Clickjacking möglich.
  • X-Content-Type-Options: fehlt → MIME-Sniffing möglich.
  • Referrer-Policy: fehlt → potentielle Weitergabe sensibler URL-Parameter an Fremddomains.

Risiko:

  • Potentiell mittel bis hoch, je nach Kontext (z. B. XSS real vorhanden → CSP crucial).

Empfehlungen:

  • CSP definieren und schrittweise verhärten.
  • HSTS mit ausreichendem max-age und includeSubDomains aktivieren.
  • frame-ancestors 'none' oder X-Frame-Options: DENY/SAMEORIGIN für kritische Views.
  • X-Content-Type-Options: nosniff für alle Responses.
  • Referrer-Policy: strict-origin-when-cross-origin oder strenger.

Security Headers sind kein Ersatz für sauberen Code

Wichtiger Pentester-Mindset:

  • Security-Header sind zusätzliche Schutzschichten:
    • CSP hilft gegen XSS, aber ersetzt nicht das Escaping/Encoding.
    • HSTS hilft gegen Stripping, aber ersetzt nicht eine korrekte TLS-Konfiguration.
    • XFO/CSP Clickjacking-Schutz ersetzt nicht eine gute UX/Sicherheitsbestätigung für kritische Aktionen.

Trotzdem: Im Report sind Security-Header-Findings beliebt, weil:

  • Sie relativ schnell „fixbar“ sind.
  • Sie oft ein guter Indikator dafür sind, wie „Security-aware“ ein Team ist.
  • Sie reale Angriffe erschweren.

🔎 Zusätzliche Tipps

  • Teste deine CSP schrittweise (z. B. Content-Security-Policy-Report-Only) bevor du streng blockierst.
  • HSTS nur aktiv setzen, wenn HTTPS überall korrekt läuft (sonst sperrst du Zugriffe).
  • Nutze Security-Header zusammen mit anderen Maßnahmen (CORS richtig konfigurieren, sichere Cookies, Input-Sanitizing).
  • Überwache und iteriere: Protokolle und Reports (CSP-Reports, Logs) helfen, Fehlkonfigurationen zu erkennen.
  • Kombiniere diese Header für optimalen Schutz.
  • Sie ergänzen sich gegenseitig und bilden zusammen ein starkes
  • Sicherheitsfundament für jede moderne Website.

Kurz-Checkliste für dich im Pentest

Wenn du eine Web-App prüfst, kannst du dir folgende Mini-Checkliste merken:

  1. HSTS
    • Ist Strict-Transport-Security gesetzt?
    • max-age ausreichend?
    • includeSubDomains sinnvoll?
  2. CSP
    • Ist Content-Security-Policy vorhanden?
    • Ist script-src restriktiv (kein unsafe-inline, keine wilden *-Domains)?
  3. Clickjacking
    • X-Frame-Options oder frame-ancestors in CSP gesetzt?
  4. MIME-Sniffing
    • X-Content-Type-Options: nosniff gesetzt?
  5. Referrer
    • Referrer-Policy gesetzt, sensiblen Kontext berücksichtigen?
  6. Permissions/CORS
    • CORS-Header sinnvoll/ restriktiv?
    • Permissions-Policy vorhanden, wenn möglich?

Wichtige Security-Attribute für Cookies

Diese werden direkt im Set-Cookie-Header gesetzt – also vom Server, wenn er Cookies an den Browser schickt. Cookies sind oft Ziel von Angriffen, z. B. bei Session Hijacking oder Cross-Site-Angriffen – daher gibt es spezielle Cookie-bezogene Security-Header bzw. Cookie–Attribute, die man immer setzen sollte. Hier ist eine einfache, verständliche Übersicht 👇

1. Secure

  • Sorgt dafür, dass das Cookie nur über HTTPS übertragen wird.
  • ❗ Ohne das kann ein Angreifer Cookies in HTTP-Verbindungen abfangen (z. B. im WLAN).
  • Beispiel: Set-Cookie: sessionId=abc123; Secure

2. HttpOnly

  • Verhindert, dass das Cookie per JavaScript (z. B. durch document.cookie) ausgelesen wird.
  • ❗ Sehr effektiv gegen XSS-Angriffe, die Session-Cookies stehlen wollen.
  • Beispiel: Set-Cookie: sessionId=abc123; HttpOnly

3. SameSite

  • Schützt vor CSRF-Angriffen (Cross-Site Request Forgery), indem das Cookie nicht bei fremden Seitenanfragen mitgeschickt wird.
  • Werte:
    • Strict → Cookies werden nur gesendet, wenn der Nutzer auf derselben Domain bleibt (höchste Sicherheit).
    • Lax → Wird bei normalen Navigationen (z. B. Klick auf Link) erlaubt, aber nicht bei Formularen oder Ajax.
    • None → Erlaubt Cross-Site, aber nur mit Secure.
  • Beispiel: Set-Cookie: sessionId=abc123; SameSite=Strict

4. Domain

  • Gibt an, für welche Domain das Cookie gilt.
  • Zu weite Domains (z. B. .example.com) können gefährlich sein, da Subdomains es dann auch lesen können.
  • Am besten nur für die Hauptdomain oder so eng wie nötig setzen.

5. Path

  • Gibt an, welcher Pfad auf der Website das Cookie verwenden darf.
  • Beschränke es, z. B. nur auf /app/ statt /, um Zugriffsbereich zu minimieren.

6. Expires / Max-Age

  • Steuert, wie lange das Cookie gültig bleibt.
  • Für Sitzungen am besten Session-Cookies (ohne Expires), damit sie beim Schließen des Browsers gelöscht werden.
  • Beispiel: Set-Cookie: sessionId=abc123; Max-Age=3600

Empfohlenes sicheres Beispiel

Set-Cookie: sessionId=abc123;
  Secure;
  HttpOnly;
  SameSite=Strict;
  Path=/;
  Max-Age=3600;

Zusätzliche Tipps

  • Vermeide Cookies für sensible Daten, wenn möglich (z. B. Tokens lieber im Header senden).
  • Verwende HSTS (Strict-Transport-Security), um HTTPS-Verbindungen zu erzwingen.
  • Trenne Cookies für verschiedene Subdomains oder Funktionen (z. B. auth.example.com getrennt von shop.example.com).

In

, , , , , , , , , , , , ,