Die unsichtbaren Türsteher: Security-Header und CSP – live demonstriert an dieser Seite

Es gibt eine Schutzschicht, die jede gute Website trägt und die trotzdem kaum jemand je zu Gesicht bekommt: ein paar Zeilen HTTP-Header, die der Server jeder Antwort mitgibt – und die Ihr Browser wie eine Hausordnung durchsetzt. Sie kosten nichts, bremsen nichts und verhindern ganze Angriffs-Klassen. Dieser Beitrag erklärt die sieben wichtigsten. Und weil Behaupten nicht unser Stil ist: Diese Seite prüft ihre eigenen Header gleich hier unten, live, in Ihrem Browser.

Stand: Juli 2026 · von byteland software solutions

Warum der Browser der beste Wachmann ist

Die meisten Angriffe auf Website-Besucher brauchen einen Komplizen: den Browser. Ein eingeschleustes Skript ausführen, die Seite unsichtbar in eine Falle einbetten, eine Verbindung auf unverschlüsselt herabstufen – all das tut am Ende der Browser, weil ihn niemand angewiesen hat, es zu lassen. Genau dafür sind Security-Header da: Der Server sagt einmal pro Antwort, was erlaubt ist, und der Browser setzt es kompromisslos durch. Der Clou: Die Regeln reisen mit jeder einzelnen Antwort mit. Es gibt keinen Agenten, den man installieren, und kein Plugin, das man aktuell halten müsste.

Die sieben Türsteher im Einzelnen

CSP in der Praxis: eine Positivliste, zwei Stufen

Die Content-Security-Policy ist der anspruchsvollste der sieben – denn sie muss exakt zur Website passen. Zu locker, und sie schützt nicht; zu streng, und sie legt die eigenen Funktionen lahm. Unsere Lösung auf byteland.de ist zweistufig: Global gilt die strenge Regel – diese Website darf ausschließlich von sich selbst laden, keine fremden Skripte, keine externen Schriften, keine Tracker (die es ohnehin nicht gibt – die CSP macht aus dem Versprechen eine technische Garantie). Nur die drei KI-Demos – Copilot, Werkstatt-Suche und Diktier-Demo – bekommen eine eigene, gezielt gelockerte Stufe, die genau die zwei Quellen erlaubt, die sie brauchen: die KI-Bibliothek vom CDN und die Modellgewichte von Hugging Face.

Beim Apache-Webhosting genügt dafür die .htaccess-Datei – hier die gekürzte Fassung unserer Konfiguration:

# Stufe 1 – alle Seiten: nur die eigene Domain
Header always set Content-Security-Policy "default-src 'self'; \
  script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; \
  img-src 'self' data:; connect-src 'self'; object-src 'none'; \
  frame-ancestors 'self'; base-uri 'self'; upgrade-insecure-requests"

# Stufe 2 – nur die KI-Demos: CDN + Modell-Host zusaetzlich erlaubt
<FilesMatch "^(copilot|suche|diktat)\.html$">
  Header always set Content-Security-Policy "default-src 'self'; \
    script-src 'self' 'unsafe-inline' 'wasm-unsafe-eval' blob: \
      https://esm.run https://cdn.jsdelivr.net; \
    connect-src 'self' https://cdn.jsdelivr.net \
      https://huggingface.co https://*.huggingface.co https://*.hf.co; \
    worker-src 'self' blob:; object-src 'none'; frame-ancestors 'self'"
</FilesMatch>

# Mikrofon: siteweit aus - nur die Diktier-Demo darf (nach Klick + Browser-Erlaubnis)
Header always set Permissions-Policy "microphone=(), camera=(), geolocation=()"
<Files "diktat.html">
  Header always set Permissions-Policy "microphone=(self), camera=(), geolocation=()"
</Files>

Das Prinzip: so streng wie möglich, so locker wie nötig – und die Lockerung gilt nur dort, wo sie begründet ist. Dass das Mikrofon auf genau einer Seite erlaubt ist und sonst nirgends, ist gelebter Datenschutz per Serverkonfiguration.

Als uns die eigene CSP ein Bein stellte

Wie ernst der Browser diese Regeln nimmt, haben wir beim Bau unserer Diktier-Demo selbst erlebt: Das Sprachmodell blieb beim Laden einfach stehen – kein Fehler auf der Seite, kein Absturz, nur ein Ladehinweis, der nie fertig wurde. Des Rätsels Lösung stand in der Entwicklerkonsole: Die KI-Bibliothek startet ihr WebAssembly-Laufzeitmodul als sogenanntes blob:-Skript – und genau diese Quelle stand nicht auf unserer Positivliste. Der Browser blockierte kommentarlos, wie bestellt. Eine Zeile Freigabe später lief alles. Die Lehre daraus geben wir gern weiter: Eine CSP testet man nicht, indem die Seite „aussieht wie immer", sondern indem man jede Funktion einmal wirklich benutzt. Der Türsteher unterscheidet nämlich nicht zwischen Angreifer und eigener Vergesslichkeit.

Selbst nachprüfen – bei uns und bei sich

Drei Handgriffe, keiner braucht Installation:

# 1. Kommandozeile: Header einer beliebigen Website ansehen
curl -I https://byteland.de

# 2. Browser: F12 druecken -> Netzwerk-Tab -> Dokument anklicken -> Antwort-Header

# 3. Schulnote mit Erklaerungen: https://securityheaders.com

Der dritte Weg ist der unterhaltsamste: securityheaders.com vergibt Noten von F bis A+ und erklärt zu jedem fehlenden Header, was er verhindern würde. Probieren Sie es ruhig mit ein paar bekannten Websites – die Ergebnisse sind ernüchternder, als man denkt. Kleiner Realitäts-Check: Der Mechanismus schützt die Besucher der Website; er ersetzt weder Updates noch Backups noch sichere Passwörter. Aber er gehört zur Grundhygiene – wie das Schloss an der Haustür.

Und unsere eigene Note?

Diese Website erreicht auf securityheaders.com die Note A (geprüft am 5. Juli 2026) – alle sechs bewerteten Header sind gesetzt. Das fehlende Plus ist kein Versehen, sondern ein ehrlicher Kompromiss, und der Prüfbericht benennt ihn korrekt: Unsere CSP erlaubt 'unsafe-inline' für Skripte. Der Grund: Diese Seite ist bewusst statisch gebaut – ohne Server-Anwendung gibt es keine Nonces, und das Pflegen von Hashes für jedes Inline-Skript wäre ein Wartungsrisiko, das mehr kaputt macht als absichert. Da hier kein fremder oder von Nutzern stammender Inhalt eingebettet wird, ist die realistische Angriffsfläche dafür minimal. So ist die Reihenfolge ehrlich: erst die Architektur ohne Einfallstore, dann die Header als Zaun – und eine Note, die wir erklären können, statt einer, die nur glänzt.

Häufige Fragen