Security-Header für Kanzleien — CSP, HSTS und Co.

Würdigung — was ein Security-Header ist und warum er fast immer fehlt#

Jede Website antwortet auf einen Seitenaufruf nicht nur mit dem sichtbaren Inhalt, sondern mit einem unsichtbaren Vorspann: den HTTP-Response-Headern. Das sind kurze Anweisungen vom Server an den Browser — „diese Antwort ist ein HTML-Dokument", „cache das eine Stunde", „lade Skripte nur von dieser Quelle". Ein Teil dieser Header ist sicherheitsrelevant. Sie weisen den Browser an, bestimmte Angriffsmuster gar nicht erst zuzulassen.

Dass diese Header auf Kanzlei-Websites fast durchgängig fehlen, ist keine böse Absicht. Es ist die Standard-Konfiguration. Ein WordPress-Theme bringt sie nicht mit, ein Baukasten-Hoster setzt sie selten, und niemand in der Kanzlei hat je entschieden, sie wegzulassen — sie waren einfach nie da. In den Kanzlei-Website-Audits, die wir fahren, ist „keine Schutz-Header" der mit Abstand häufigste Befund in der Kategorie Sicherheit.

Die securityheaders.com-Note (eine Skala von A+ bis F) ist deshalb kein Selbstzweck. Sie ist ein billiger, schneller Stellvertreter für eine schwer messbare Frage: Hat sich jemand um die Härtung dieser Seite gekümmert? Eine Note F heißt nicht zwingend, dass die Seite morgen gehackt wird. Sie heißt, dass die einfachsten, kostenlosen Schutzmaßnahmen nicht getroffen wurden — und das ist für eine Kanzlei, die unter § 203 StGB Verschwiegenheit schuldet, ein schlechtes Signal nach außen.

HSTS — der Header, der das Schloss-Symbol erzwingt#

Strict-Transport-Security (kurz HSTS) ist der Header mit dem unmittelbarsten Schutz-Effekt. Er weist den Browser an, eine Domain ab dem ersten Besuch ausschließlich über die verschlüsselte https://-Variante zu laden — auch dann, wenn jemand später nur kanzlei-beispiel.de ohne Protokoll in die Adresszeile tippt.

Das schließt eine konkrete Lücke. Ohne HSTS sendet der Browser die erste Anfrage oft unverschlüsselt über http:// und wird dann per Weiterleitung auf https:// geschoben. Diese erste, ungeschützte Anfrage ist der Moment, in dem ein Angreifer im selben offenen WLAN — Café, Bahn, Kanzlei-Wartezimmer — die Verbindung umbiegen kann (klassisches „SSL-Stripping"). HSTS macht diese erste Anfrage von vornherein verschlüsselt.

Unsere Konfiguration auf fahoch2.de lautet max-age=63072000; includeSubDomains; preload. Übersetzt: zwei Jahre Gültigkeit, Einschluss aller Subdomains, und die Bereitschaft zur Aufnahme in die Browser-Preload-Liste. Diese Preload-Liste wird direkt in Chrome, Firefox und Safari ausgeliefert — eine Domain darauf wird selbst beim allerersten Besuch nie unverschlüsselt geladen. Der häufigste Fehler in der Praxis ist eine zu kurze max-age (ein paar Stunden statt Monate) oder ein fehlendes includeSubDomains, sodass ein vergessenes blog.kanzlei-beispiel.de ungeschützt bleibt.

Content-Security-Policy — die Regel, welche Skripte laden dürfen#

Die Content-Security-Policy (CSP) ist der mächtigste und der unbequemste Header. Sie ist eine Whitelist: Sie legt fest, aus welchen Quellen der Browser Skripte, Stylesheets, Bilder, Schriften und eingebettete Inhalte überhaupt laden darf. Alles, was nicht auf der Liste steht, blockt der Browser. Der Schutz richtet sich gegen Cross-Site-Scripting (XSS) — den Fall, dass ein eingeschleustes Skript, etwa über eine Plugin-Lücke, im Browser Ihrer Besucher fremden Code ausführt.

Hier liegt zugleich der Punkt, an dem die meisten Anläufe scheitern. Eine strikte CSP verbietet auch eingebettete (inline) Skripte und Styles — und genau die nutzen viele Frameworks intern. Es gibt drei Wege, damit umzugehen, und die Wahl ist eine echte Architektur-Entscheidung, keine Geschmacksfrage:

• 'unsafe-inline' erlaubt eingebettete Skripte pauschal. Bequem, aber es weicht den XSS-Schutz auf. Für eine rein statische Marketing-Seite ohne Nutzer-Eingaben, die im Seiteninhalt landen, ist das Restrisiko überschaubar.
• Nonce-basiert vergibt pro Seitenaufruf eine zufällige Einmal-Kennung an jedes erlaubte Skript. Sehr sicher — aber es zwingt die Seite zu dynamischem Rendering bei jedem Request. Damit fällt das CDN-Caching weg, die Auslieferung wird langsamer und teurer. Die Next.js-Dokumentation beschreibt diesen Weg über eine proxy.ts ausführlich.
• Hash-basiert (in Next.jsNext.js · zum GlossarReact-Framework für SSG/SSR/ISR — der aktuelle Standard für moderne Kanzlei-Sites. als experimentelle Subresource Integrity) berechnet zur Build-Zeit Prüfsummen der Skripte. Das erlaubt eine strikte CSP bei gleichzeitig statischer Auslieferung — der vielversprechende Mittelweg, aber noch als experimentell markiert.

Auf fahoch2.de fahren wir bewusst den 'unsafe-inline'-Weg in Kombination mit einer engen default-src 'self': Skripte, Verbindungen und Einbettungen sind auf die eigene Domain begrenzt, die einzige Fremdquelle ist das cookielose Analytics von CloudflareCloudflare · zum GlossarUS-Anbieter für CDN, WAF, DDoS-Schutz und Turnstile — Privacy-by-Design-Ausrichtung.. Der entscheidende Punkt dabei: Weil die Seite kein Login, keine Kommentare und keinen Nutzer-Content rendert, der ins HTML zurückgespiegelt wird, gibt es praktisch kein Einfallstor, über das 'unsafe-inline' ausnutzbar wäre — das Restrisiko ist hier gering, der Performance-Gewinn durch CDN-Caching real. Diese Entscheidung hängt direkt an unserer cookielosen Architektur und am Wunsch, jede Seite vom CDN-Edge ausliefern zu können. Für ein Mandanten-Portal mit Login und sensiblen Eingaben würden wir anders entscheiden und auf Nonce oder Hash gehen.

Eine CSP enthält außerdem die Direktive frame-ancestors 'none' — der moderne Clickjacking-Schutz, zu dem wir gleich kommen.

X-Frame-Options und X-Content-Type-Options — Clickjacking und MIME-Verwechslung#

X-Frame-Options: DENY verhindert, dass die Seite in einen <iframe> einer fremden Website eingebettet wird. Der Angriff dahinter heißt Clickjacking: Eine bösartige Seite legt Ihre Kanzlei-Seite unsichtbar über einen eigenen Button, und der Klick des Nutzers landet woanders, als er denkt. Der modernere Mechanismus dafür ist die CSP-Direktive frame-ancestors 'none'; wir setzen beide, weil ältere Browser X-Frame-Options brauchen und neuere die CSP-Variante bevorzugen.

Diese Header sind übrigens der Grund, warum sich ein DATEV-Mandantenportal nicht einfach per Iframe in die Kanzlei-Website einbetten lässt — DATEV setzt dieselbe Sperre aktiv. Wir haben das im Detail im Artikel zur DATEV-Portal-Integration und im Software-Vergleich DATEV/Stotax/Addison beschrieben.

X-Content-Type-Options: nosniff ist der leiseste der Gruppe. Er verbietet dem Browser, den Inhalts-Typ einer Datei selbst zu „erraten". Ohne diesen Header kann eine als Text hochgeladene Datei unter Umständen als Skript interpretiert und ausgeführt werden — relevant überall dort, wo Nutzer Dateien hochladen, etwa über ein Bewerbungs- oder Kontaktformular. Ein Wort, ein Schutz, keine Nebenwirkung.

Referrer-Policy und Permissions-Policy — die leisen Header#

Die Referrer-Policy steuert, wie viel Ihre Seite über sich preisgibt, wenn ein Besucher auf einen externen Link klickt. Im Standard übermittelt der Browser dem Ziel die Herkunfts-URL — und das kann mehr verraten als gewünscht. Klickt ein Mandant von einer URL wie /mandantenportal/dokumente auf einen externen Link, würde der vollständige Pfad mitwandern. Unser Wert strict-origin-when-cross-origin sorgt dafür, dass externen Zielen nur die nackte Domain (https://fahoch2.de) übermittelt wird, nicht der konkrete Pfad. Das ist heute zwar der Browser-Standard, aber explizit gesetzt ist es belastbarer als auf Default-Verhalten zu vertrauen.

Die Permissions-Policy schaltet Browser-Funktionen ab, die die Seite gar nicht braucht. Unser Wert camera=(), microphone=(), geolocation=(), interest-cohort=() deaktiviert Kamera, Mikrofon und Standortabfrage komplett und meldet die Seite zusätzlich aus Googles Interessen-basiertem Tracking ab. Wichtig zur Einordnung: Das OWASP Secure Headers Project führt die Permissions-Policy noch als „Working Draft" — der Standard ist also in Bewegung, der Schutz-Gewinn aber real und ohne Risiko mitzunehmen.

Was die securityheaders.com-Note bewertet — und wie wir fahoch2.de setzen#

securityheaders.com prüft das Vorhandensein und die sinnvolle Belegung genau dieser Header und vergibt daraus eine Note. Es ist eine Anwesenheits-Prüfung, kein Penetrationstest — aber als erster, kostenloser Indikator zuverlässig. Die folgende Konfiguration liefert fahoch2.de an jede Anfrage aus:

Header	Wert (Kurzform)
Content-Security-Policy	default-src 'self'; Skripte nur von eigener Domain + Cloudflare-Analytics; frame-ancestors 'none', object-src 'none', base-uri 'self', form-action 'self'
Strict-Transport-Security	max-age=63072000; includeSubDomains; preload (2 Jahre, Preload-Liste)
X-Frame-Options	DENY
X-Content-Type-Options	nosniff
Referrer-Policy	strict-origin-when-cross-origin
Permissions-Policy	camera=(), microphone=(), geolocation=(), interest-cohort=()
Cross-Origin-Opener-Policy	same-origin
Cross-Origin-Embedder-Policy	credentialless

Dazu kommt eine Kleinigkeit mit Symbolwirkung: Wir entfernen den X-Powered-By-Header. Standardmäßig verrät eine Seite damit ihre Technik — ein unnötiger Hinweis für jeden, der gezielt nach bekannten Lücken eines Stacks sucht. Ein Detail derselben Sorgfalt: Die script-src trägt 'unsafe-eval' ausschließlich im lokalen Entwicklungs-Server (React nutzt es dort zum Debuggen) — die ausgelieferte Produktion verzichtet darauf, weil sie es nicht braucht. Die beiden Cross-Origin-*-Header (COOPCOOP · zum GlossarCross-Origin-Opener-Policy — isoliert das Browser-Tab gegenüber anderen Fenstern. und COEPCOEP · zum GlossarCross-Origin-Embedder-Policy — zwingt eingebettete Ressourcen zu expliziter Cross-Origin-Erlaubnis.) gehören zu einem eigenen Thema, der Cross-Origin-Isolation; die behandeln wir gesondert.

Der Aufwand, eine bestehende Seite von Note F auf Note A zu heben, liegt — wenn die Hosting-Umgebung eigene Header zulässt — im Bereich von ein bis zwei Stunden. Bei manchen Baukasten-Hostern geht es technisch nicht, weil sie keine eigenen Header erlauben; das ist dann selbst ein Befund. Für eine strukturierte Bestandsaufnahme über alle Hebel hinweg — Header, Performance, Cookie-Sauberkeit, Barrierefreiheit — inklusive Aufwand- und Effekt-Schätzung pro Punkt empfehlen wir unseren Hebel-Audit (890 €, bei Beauftragung eines Mandanten-Boost innerhalb von 60 Tagen voll anrechenbar). Wie sehr die Header-Architektur mit der Ladezeit zusammenhängt, ordnet ergänzend der Artikel zu den Core Web Vitals ein.

Zusammenfassung#

Schutz-Header sind die günstigste Sicherheitsmaßnahme einer Website: kein laufender Aufwand, keine Lizenz, in den meisten Fällen ein bis zwei Stunden Arbeit. HSTS erzwingt verschlüsselte Verbindungen, die Content-Security-Policy begrenzt, welche Skripte laden dürfen, X-Frame-Options und frame-ancestors wehren Clickjacking ab, nosniff verhindert MIME-Verwechslung, und Referrer- sowie Permissions-Policy stopfen kleine, aber unnötige Daten-Lecks. Die securityheaders.com-Note fasst das in einer Zahl zusammen — nicht als Trophäe, sondern als ehrlicher Hinweis, ob sich jemand gekümmert hat. Wer die eigene Seite einordnen will, beginnt mit dem kostenfreien Note-Check und entscheidet danach, ob die Header an der Hosting-Umgebung scheitern oder nur fehlen.

Quellen#

• MDN — Content-Security-Policy — abgerufen 2026-05-29
• MDN — Strict-Transport-Security — abgerufen 2026-05-29
• MDN — X-Frame-Options — abgerufen 2026-05-29
• MDN — X-Content-Type-Options — abgerufen 2026-05-29
• MDN — Referrer-Policy — abgerufen 2026-05-29
• MDN — Permissions-Policy — abgerufen 2026-05-29
• OWASP Secure Headers Project — abgerufen 2026-05-29
• web.dev — Content Security Policy — abgerufen 2026-05-29
• Next.js — Content Security Policy — abgerufen 2026-05-29
• StGB § 203 — Verletzung von Privatgeheimnissen — abgerufen 2026-05-29

Disclaimer: Allgemeine fachliche Information zum Zeitpunkt der Veröffentlichung — keine Rechtsberatung im Einzelfall. Maßgeblich ist der jeweils aktuelle Gesetzes- und Technik-Stand.