Alle Beiträge
Websecurity Security Header CSP SEO

Security Header für Websites: Warum HTTPS allein nicht reicht

HTTPS ist heute Pflicht. Ohne TLS-Verschlüsselung sollte keine Website mehr betrieben werden. Aber HTTPS löst nur einen Teil des Problems: Es schützt die Verbindung zwischen Browser und Server.

Was HTTPS nicht automatisch verhindert:

  • Einbettung der Website in fremde Frames
  • Ausführung unerwünschter Skripte
  • Lecks über Referrer-Informationen
  • Missbrauch von Browser-Funktionen
  • Downgrade-Versuche auf HTTP
  • Fehlerhafte Einbindung externer Inhalte

Dafür gibt es Security Header. Sie sind keine vollständige Web Application Firewall, aber eine wichtige Schutzschicht.

Was sind Security Header?

HTTP-Header sind Zusatzinformationen, die der Server mit jeder Antwort ausliefert. Der Browser nutzt sie, um zu entscheiden, wie er die Seite behandeln soll.

Security Header geben dem Browser Sicherheitsregeln mit:

  • Welche Skripte dürfen ausgeführt werden?
  • Darf die Seite in einem Frame geladen werden?
  • Soll immer HTTPS verwendet werden?
  • Welche Referrer-Daten dürfen an andere Seiten gehen?
  • Darf die Seite Kamera, Mikrofon oder Standort anfragen?

Der große Vorteil: Diese Regeln wirken direkt im Browser des Nutzers.

Content-Security-Policy: die wichtigste, aber anspruchsvollste Regel

Die Content-Security-Policy, kurz CSP, legt fest, aus welchen Quellen Inhalte geladen werden dürfen.

Eine CSP kann zum Beispiel definieren:

  • Skripte nur von der eigenen Domain
  • Bilder von eigener Domain und ausgewählten externen Quellen
  • Frames nur von hCaptcha
  • Keine Einbettung in fremde Seiten
  • Formulare nur an die eigene Domain

Das schützt vor vielen Cross-Site-Scripting-Szenarien und reduziert das Risiko, dass eingeschleuster Code beliebige externe Skripte nachlädt.

Eine gute CSP ist aber Arbeit. Moderne Websites nutzen Bundler, Inline-Skripte, Tracking, Captchas, Fonts und externe Dienste. Jede Quelle muss bewusst erlaubt werden. Zu breite Regeln wie script-src * oder dauerhaftes unsafe-inline nehmen der CSP viel Wirkung.

HSTS: immer HTTPS erzwingen

HTTP Strict Transport Security, kurz HSTS, sagt dem Browser: Diese Domain soll künftig nur noch per HTTPS aufgerufen werden.

Das schützt gegen Downgrade-Angriffe und versehentliche HTTP-Aufrufe. Besonders wichtig ist HSTS, wenn eine Website Logins, Formulare oder sensible Daten verarbeitet.

Ein typischer Header sieht vereinfacht so aus:

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

Mit preload kann eine Domain in Browser-Listen aufgenommen werden, sodass HTTPS sogar vor dem ersten Besuch erzwungen wird. Das ist stark, sollte aber bewusst eingesetzt werden. Wer Subdomains nicht sauber im Griff hat, kann sich sonst selbst aussperren.

X-Frame-Options und frame-ancestors

Clickjacking ist ein alter, aber weiterhin relevanter Angriff. Dabei wird eine Website unsichtbar oder manipuliert in eine fremde Seite eingebettet. Nutzer klicken scheinbar auf etwas Harmloses, tatsächlich interagieren sie mit der eingebetteten Website.

Dagegen helfen:

X-Frame-Options: DENY

und moderner in der CSP:

frame-ancestors 'none';

Für normale Unternehmensseiten ist DENY oder frame-ancestors 'none' meistens sinnvoll. Nur wenn die Website bewusst eingebettet werden soll, braucht es Ausnahmen.

X-Content-Type-Options

Dieser Header verhindert, dass Browser Dateitypen erraten.

X-Content-Type-Options: nosniff

Warum ist das wichtig? Wenn ein Server eine Datei falsch ausliefert, könnten Browser versuchen, sie trotzdem als Skript oder anderen aktiven Inhalt zu interpretieren. nosniff reduziert dieses Risiko.

Es ist ein kleiner Header, aber praktisch immer empfehlenswert.

Referrer-Policy

Wenn ein Nutzer von einer Seite auf eine andere klickt, kann der Browser die Ursprungsadresse als Referrer mitschicken. Das ist für Analytics hilfreich, kann aber sensible Pfade oder Parameter verraten.

Eine sinnvolle Einstellung ist oft:

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

Damit wird bei externen Zielen nur die Herkunfts-Domain übertragen, nicht der vollständige Pfad. Intern bleibt mehr Information erhalten.

Für viele Websites ist das ein guter Kompromiss zwischen Datenschutz und Auswertbarkeit.

Permissions-Policy

Die Permissions-Policy steuert, welche Browser-Funktionen eine Seite überhaupt nutzen darf.

Beispiele:

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

Wenn eine normale Website keine Kamera, kein Mikrofon, keinen Standort und keine Payment-API benötigt, sollte sie das auch nicht anfragen dürfen.

Das reduziert Angriffsfläche und verhindert überraschende Berechtigungsdialoge.

Security Header und SEO

Security Header sind nicht direkt der magische SEO-Booster. Aber technische Vertrauenswürdigkeit, HTTPS, saubere Canonicals, keine Mixed-Content-Probleme und stabile Auslieferung gehören zur Grundhygiene einer modernen Website.

Eine Website, die mit Zertifikatsfehlern, doppelten Hostnames oder unsauberen Weiterleitungen auffällt, macht weder auf Nutzer noch Suchmaschinen einen guten Eindruck.

Security und SEO sind hier kein Widerspruch. Sie teilen sich dieselbe Basis: saubere Technik.

Fazit

HTTPS ist die Grundlage, aber nicht das Ende. Security Header geben dem Browser klare Regeln und reduzieren typische Angriffsflächen.

Für die meisten Websites gehören mindestens dazu:

  • Content-Security-Policy
  • Strict-Transport-Security
  • X-Frame-Options oder frame-ancestors
  • X-Content-Type-Options
  • Referrer-Policy
  • Permissions-Policy

Wenn Sie wissen möchten, ob Ihre Website technisch sauber abgesichert ist, prüfe ich das gerne für Sie.