HTTP-Sicherheitsheader | SeenSecure Hilfe

🛡️ X-Frame-Options — Clickjacking-Schutz

🎯 Was es tut

Steuert, ob Ihre Seite in einem <iframe> auf einer anderen Website angezeigt werden kann. Verhindert, dass externe Seiten Ihre Inhalte ohne Erlaubnis einbetten.

⚠️ Warum es wichtig ist

Ohne diesen Schutz kann ein Angreifer Ihre Seite in einem transparenten Iframe laden und Benutzer dazu verleiten, unwissentlich zu klicken (Clickjacking). Dies kann Anmeldedaten offenlegen, Zahlungen autorisieren oder Einstellungen ändern.

⚙️ Konfigurationsoptionen

DENY (empfohlen): Blockiert jeden Versuch, Ihre Seite in einem Iframe anzuzeigen, ausnahmslos.

SAMEORIGIN: Erlaubt nur Iframes von derselben Domain. Nützlich, wenn Sie eigene legitime Iframes verwenden.

🎯 Reales Beispiel: ein Angreifer erstellt eine Seite, die eine harmlose Verlosung oder Umfrage imitiert, und platziert Ihr WordPress-Admin-Panel (wp-admin) in einem transparenten <iframe>, exakt über dem "Teilnehmen"-Button. Das Opfer — in einem anderen Tab als Administrator angemeldet — glaubt, auf "Teilnehmen" zu klicken, aber der Klick landet tatsächlich auf dem darunter verborgenen echten wp-admin-Button, z.B. "Benutzer löschen" oder "Plugin installieren". Ohne X-Frame-Options erlaubt der Browser, dass Ihre Seite in diesem fremden Iframe geladen wird. Mit X-Frame-Options: DENY verweigert der Browser rundweg die Anzeige Ihrer Seite in jedem externen Iframe, und die Seite des Angreifers zeigt eine leere Lücke, wo der Köder sein sollte.

✅ Empfehlung: Verwenden Sie DENY, es sei denn, Sie haben einen spezifischen Grund, eigene Iframes zu benötigen, dann verwenden Sie SAMEORIGIN.

📝 X-Content-Type-Options — MIME-Sniffing-Prävention

🎯 Was es tut

Weist den Browser an, den Dateityp NICHT zu erraten (MIME-Sniffing). Er zwingt ihn, den im Content-Type-Header deklarierten Typ genau zu respektieren.

⚠️ Warum es wichtig ist

Ohne diesen Header kann ein Browser eine Textdatei als JavaScript interpretieren und ausführen. Dies ermöglicht Angreifern, eine Datei mit der Endung .txt aber mit schädlichem Code hochzuladen, den der Browser ausführt.

⚙️ Konfiguration

Der einzig gültige Wert ist nosniff. Es wird empfohlen, es immer zu aktivieren. Es hat keine negativen Nebenwirkungen.

🎯 Reales Beispiel: ein schlecht validiertes Datei-Upload-Formular (z.B. in einem Drittanbieter-Plugin) erlaubt einem Angreifer, eine Datei namens bild.jpg hochzuladen, die in Wirklichkeit als Bild getarnten JavaScript-Code enthält. Wenn der Browser eines Besuchers versucht, den Inhaltstyp zu "erraten", statt dem vom Server deklarierten Header zu vertrauen, kann er diese Datei als Skript interpretieren und im Kontext Ihrer Seite ausführen, statt sie als harmloses Bild anzuzeigen. Mit X-Content-Type-Options: nosniff hält sich der Browser strikt an den vom Server deklarierten Typ (Bild) und weigert sich, ihn als Code auszuführen, egal was der interne Inhalt nahelegt.

✅ SEHR EMPFOHLEN: Aktivieren Sie es ohne Zögern. Es ist einer der sichersten Header mit den geringsten Auswirkungen. Es bricht nichts und schützt vor einer häufigen Schwachstelle.

🔒 X-XSS-Protection — Warum Wir Ihn Nicht Mehr Senden

🎯 Was war es?

Ein Header, der einen integrierten Anti-XSS-Filter in älteren Browsern (Internet Explorer, alte Versionen von Chrome und Safari) aktivierte, der reflektierte Skriptinjektionsversuche erkennen und blockieren sollte.

⚠️ Warum wir ihn entfernt haben

Chrome entfernte ihn 2019 vollständig — er hatte nicht nur keine Wirkung mehr, Google betrachtete ihn tatsächlich eher als Risiko denn als Hilfe, da der Filter selbst dokumentierte Sicherheitslücken hatte und relativ leicht zu umgehen war. Firefox hat ihn nie implementiert. Microsoft beendete den Support für Internet Explorer 2022. Einen Header beizubehalten, der nichts Reales mehr schützt und einst eigene Probleme verursachen konnte, ergab keinen Sinn.

✅ Geht durch das Entfernen Schutz verloren? Nein. In Internet Explorer, dem einzigen Browser, in dem dieser Header je eine Rolle spielte, war der Filter standardmäßig aktiviert, selbst wenn die Seite keinen Header sendete — der Header erlaubte einer Seite lediglich, dieses Verhalten zu ändern (vollständige Blockierung erzwingen oder deaktivieren, falls er Fehlalarme verursachte). Ohne den Header behält IE einfach sein Werksverhalten bei: Es wird nichts abgeschaltet, was vorher an war.

🎯 Der echte Schutz, heute: der Angriff, den dieser Filter zu stoppen versuchte (reflektiertes XSS: eine manipulierte URL, die ein schlecht escaptes Such- oder Eingabefeld dazu bringt, ausführbaren Code an den Browser jedes Nutzers zurückzugeben, der auf einen präparierten Link klickt), wird heute durch zwei Schichten abgedeckt, die in jedem Browser gleich funktionieren, alt oder neu: die WAF der Firewall, die das Injektionsmuster auf Anfrageebene blockiert, bevor das HTML den Browser erreicht, und die Content-Security-Policy, die den Browser daran hindert, nicht autorisierte Skripte auszuführen, selbst wenn der bösartige Code bereits auf der Seite steht. Keine der beiden hängt davon ab, dass der Browser einen eigenen heuristischen Filter hat.

🔗 Referrer-Policy — Kontrolle von Referrer-Informationslecks

🎯 Was es tut

Steuert, wie viele Informationen aus der Ursprungs-URL im Referer-Header gesendet werden, wenn Benutzer auf einen Link klicken oder eine externe Ressource laden.

⚠️ Warum es wichtig ist

Ohne Kontrolle kann die vollständige URL (einschließlich Parameter wie Token, Sitzungs-IDs oder persönliche Daten) an externe Seiten gelangen. Dies verletzt die Privatsphäre des Benutzers und kann sensible Daten offenlegen.

⚙️ Konfigurationsoptionen

no-referrer: Sendet niemals den Referer. Maximale Privatsphäre, kann aber Analytics brechen.

same-origin: Sendet Referer nur innerhalb derselben Domain. Sendet nicht an externe Seiten.

strict-origin: Sendet nur die Herkunft (Domain), niemals die vollständige URL. Nur bei HTTPS-zu-HTTPS-Verbindungen.

strict-origin-when-cross-origin (empfohlen): Sendet die vollständige URL innerhalb derselben Domain und nur die Herkunft an externe Seiten. Die beste Balance zwischen Funktionalität und Privatsphäre.

🎯 Reales Beispiel: ein angemeldeter Benutzer navigiert zu einer Seite, deren URL ein sensibles Token als Parameter enthält (z.B. ein frisch generierter Passwort-Reset-Link). Enthält diese Seite eine von einer externen Domain geladene Ressource — eine Webschrift, ein Werbebanner, ein Drittanbieter-Widget — könnte der Browser diese vollständige URL, Token inklusive, als Referer-Header an den externen Server senden, ohne dass der Benutzer oder der Eigentümer der externen Seite dies ausdrücklich verlangt hat. Mit Referrer-Policy: strict-origin-when-cross-origin teilt der Browser externen Seiten nur die Ursprungsdomain mit, niemals den vollständigen Pfad mit Token, und Links innerhalb Ihrer eigenen Domain funktionieren weiterhin normal.

💡 Empfehlung: Verwenden Sie strict-origin-when-cross-origin. Es ist der Standard in modernen Browsern und bietet die beste Balance zwischen Funktionalität und Privatsphäre.

🔐 HSTS — HTTPS-Verbindung erzwingen

🎯 Was es tut

Zwingt Browser, ausschließlich über HTTPS zu verbinden, selbst wenn der Benutzer http:// eingibt oder auf einen HTTP-Link klickt. Der Browser merkt sich dies für die konfigurierte max-age.

⚠️ Warum es wichtig ist

Ohne HSTS kann ein Angreifer im selben Netzwerk (z.B. öffentliches WLAN) die erste HTTP-Verbindung abfangen und den Benutzer auf eine gefälschte Seite umleiten (Man-in-the-Middle-Angriff). HSTS beseitigt dieses Verwundbarkeitsfenster.

⚙️ Konfiguration: max-age

max-age=0: Deaktiviert HSTS. Zwingt Browser, die Richtlinie zu vergessen.

max-age=3600 (1 Stunde): Zum Testen. Geringes Risiko, Browser vergessen schnell.

max-age=63072000 (2 Jahre, empfohlen): Für die Produktion. Browser merken sich die HTTPS-Erzwingung für 2 Jahre.

🎯 Reales Beispiel: ein Kunde verbindet sich mit dem kostenlosen WLAN eines Cafés und tippt Ihre Domain aus dem Gedächtnis in die Adressleiste, ohne das https:// davor. Der Browser versucht zuerst die unsichere HTTP-Verbindung. Ein Angreifer im selben WLAN-Netzwerk kann diese erste HTTP-Anfrage abfangen und eine gefälschte Kopie Ihrer Seite zurückgeben, um Anmeldedaten zu stehlen, bevor die normale Weiterleitung zu HTTPS abgeschlossen ist (dies wird als Man-in-the-Middle-Angriff bezeichnet). Mit aktiviertem HSTS und einem bereits einmal zuvor über HTTPS besuchten Standort versucht der Browser die unsichere Verbindung erst gar nicht: Er erzwingt HTTPS direkt lokal auf dem Gerät selbst und verweigert dem Angreifer dieses Abfangfenster.

🚨 KRITISCHE WARNUNG: Wenn Sie HSTS mit einer hohen max-age aktivieren und später HTTPS auf Ihrem Server deaktivieren, werden Browser den Zugriff auf Ihre Seite blockieren, bis die max-age abläuft. Es gibt keine Möglichkeit, sie vorzeitig zu widerrufen. Verwenden Sie zuerst einen niedrigen Wert zum Testen.

🎯 Content-Security-Policy (CSP) — Die Content-Polizei

🎯 Was es tut

Definiert genau, welche Quellen zum Laden von Skripten, Stilen, Bildern, Schriftarten und anderen Ressourcen auf Ihrer Seite autorisiert sind. Jede nicht autorisierte Ressource wird automatisch vom Browser blockiert.

⚠️ Warum es wichtig ist

CSP ist die stärkste Verteidigung gegen XSS. Selbst wenn ein Angreifer ein bösartiges Skript injizieren kann, blockiert CSP es, weil das Skript nicht von einer autorisierten Quelle stammt. Es ist Ihre letzte Verteidigungslinie.

🎯 Reales Beispiel: ein schlecht gefiltertes Kommentar- oder Formularfeld erlaubt einem Angreifer, ein <script>-Tag zu injizieren, das Code von einer fremden Domain in eine Ihrer Seiten lädt (ein typischer Fehler, wenn ein Plugin Benutzereingaben nicht korrekt escapt). Ohne CSP würde der Browser jedes Besuchers, der diese Seite lädt, das Skript ohne Nachfrage ausführen, und der Code könnte Sitzungscookies stehlen, auf eine Phishing-Seite umleiten oder Tastatureingaben abfangen. Mit einer CSP, die script-src auf Ihre eigene Domain beschränkt (und auf explizit autorisierte Quellen), erkennt der Browser, dass diese fremde Domain nicht auf der erlaubten Liste steht, und weigert sich, das Skript zu laden und auszuführen, obwohl der bösartige Code bereits im HTML der Seite sitzt.

⚙️ Konfiguration

CSP verwendet einen Freitext-Editor, in den Sie die Richtlinie direkt schreiben. Es gibt keine Ein-Klick-Vorlagen-Schaltflächen.

🚨 Der Standardwert ist KEINE vollständige Richtlinie — nur eine minimale Zeile: wenn Sie CSP zum ersten Mal aktivieren, ist das Textfeld nur mit default-src 'self'; vorausgefüllt. Diese einzelne Direktive gilt als Fallback für JEDEN Ressourcentyp ohne eigene explizite Direktive (Skripte, Stile, Bilder, Schriftarten...), und da sie weder 'unsafe-inline' noch externe Domänen enthält, blockiert sie die Inline-Stile und -Skripte, die fast jedes WordPress-Theme oder -Plugin direkt in das HTML schreibt, sowie jede Ressource, die von einem externen CDN geladen wird (Google Fonts, jQuery, YouTube usw.). Aktivieren Sie den CSP-Schalter nicht mit diesem unveränderten Wert — es wird sehr wahrscheinlich das Erscheinungsbild und die Funktionalität eines echten WordPress zerstören.

💡 Was Sie stattdessen tun sollten: Bevor Sie den CSP-Schalter aktivieren, öffnen Sie Ihre Website mit der Browserkonsole (F12) und fügen Sie dem Textfeld manuell die Domänen hinzu, die Ihr Theme, Ihre Plugins und Drittanbieter-Skripte benötigen (Google Fonts, YouTube, Ihr Analytics-Anbieter usw.), gemäß der unten erklärten Direktiven-Syntax. Beginnen Sie immer mit der Firewall im Modus Monitoring, damit Sie Konsolenfehler prüfen können, ohne zu riskieren, Ihre Live-Website unbrauchbar zu machen.

Warum gibt es keine Ein-Klick-Vorlage "sicher für WordPress"? Es wurde vorher gründlich getestet: Es gibt keine einzige CSP-Richtlinie, die bei den Tausenden verschiedenen Kombinationen aus Theme, Plugins und Drittanbieterdiensten, die auf diesem Plugin laufen, nichts zerstört — es gibt immer einen Fall, der unsafe-inline, eine bestimmte CDN-Domäne oder eine Berechtigung benötigt, die eine andere Website nicht braucht. Deshalb bleibt das Feld leer (mit dem minimalen Fallback default-src 'self';), damit Sie es selbst nach dem aufbauen, was Ihre Website tatsächlich lädt, statt eine Schaltfläche anzubieten, die zu blindem Aktivieren einlädt.

⚠️ CSP-Risiko: Eine falsch konfigurierte Richtlinie kann Ihre Seite beschädigen (wichtige Skripte, Stile, Bilder oder Ressourcen blockieren). Testen Sie immer zuerst mit der Firewall im Monitoring-Modus und beobachten Sie dabei die Browserkonsole. Fügen Sie Direktive für Direktive nur hinzu, was Ihre Seite wirklich braucht.

💡 Tipp: Wenn nach der Aktivierung von CSP etwas nicht mehr funktioniert, öffnen Sie die Browserkonsole (F12). Die Fehler zeigen Ihnen genau, welche Ressource blockiert wurde und von welcher Domain. Fügen Sie diese Domain einfach zu den entsprechenden Direktiven hinzu.

✍️ Wie Eine CSP-Richtlinie Geschrieben Wird (Grundlegende Syntax)

Auch wenn es wie ein einschüchternder Textblock aussieht, folgt CSP immer einer sehr einfachen, gleichbleibenden Struktur:

directiva1 valor1 valor2 valor3; directiva2 valor1; directiva3 valor1 valor2;

Jede Direktive endet mit einem Semikolon (;). Das trennt eine Regel von der nächsten — vergessen Sie eines, kann die nächste Direktive an der vorherigen „kleben" bleiben und nicht mehr funktionieren.
Innerhalb einer Direktive werden Werte durch Leerzeichen getrennt (niemals Kommas): script-src 'self' https://beispiel.com https://andere.com; autorisiert drei verschiedene Quellen für Skripte.
Spezielle Schlüsselwörter stehen in einfachen Anführungszeichen: 'self' (die eigene Domain), 'none' (nichts, komplett verboten), 'unsafe-inline' (erlaubt Code, der direkt im HTML steht). Normale Domains bekommen nie Anführungszeichen: https://fonts.googleapis.com, nicht 'https://fonts.googleapis.com'.
Sie können eine ganze Domain mit einem Platzhalter autorisieren: https://*.googleapis.com erlaubt jede Subdomain von googleapis.com, statt jede einzeln aufzulisten.

✏️ Wie man eine neue Erlaubnis Schritt für Schritt hinzufügt: Finden Sie die passende Direktive (z. B. script-src für ein Skript) im bereits im Feld stehenden Text, und fügen Sie die neue Domain direkt vor dem Semikolon dieser Direktive hinzu, durch ein Leerzeichen vom vorherigen Wert getrennt. Beispiel: Hatten Sie script-src 'self' 'unsafe-inline'; und müssen https://widget.beispiel.com autorisieren, ändern Sie es zu: script-src 'self' 'unsafe-inline' https://widget.beispiel.com;. Löschen Sie nichts, was schon da war, fügen Sie nur hinzu.

📚 Die Direktiven, Die Sie Tatsächlich Verwenden (Wie Viele Es Gibt und Wofür Jede Dient)

Die CSP-Spezifikation definiert insgesamt mehr als 20 Direktiven, aber auf einer normalen WordPress-Seite müssen Sie nur diese 12 anfassen — es sind die, die bereits im Standardwert stehen, oder die, die beim Hinzufügen eines neuen Dienstes am häufigsten gebraucht werden:

Direktive	Wofür sie dient (was sie kontrolliert)	Wann Sie sie anfassen
`default-src`	Standardwert: gilt für jeden Ressourcentyp, der unten keine eigene spezifische Direktive hat.	Fast nie — dient als Sicherheitsnetz
`script-src`	Von wo JavaScript geladen und ausgeführt werden darf (`<script>`, Code in `onclick`-Attributen usw.)	Beim Installieren eines Chatbots, eines Tracking-Pixels, eines Bewertungs-Widgets...
`style-src`	Von wo CSS-Stylesheets und direkt im HTML geschriebene Stile geladen werden dürfen	Beim Hinzufügen einer externen Schriftart (Google Fonts, Adobe Fonts...)
`img-src`	Von wo Bilder geladen werden dürfen	Wenn Sie ein Bild-CDN, externe Avatare (Gravatar), eingebettete Karten verwenden...
`font-src`	Von wo Schriftdateien (.woff, .ttf...) geladen werden dürfen	Geht fast immer Hand in Hand mit `style-src` für denselben Schriftdienst
`connect-src`	Zu welchen Domains sich das JavaScript der Seite verbinden darf (`fetch`-Anfragen, `XMLHttpRequest`, WebSockets)	Bei der Integration von Analytics, Live-Chat, jedem Dienst, der Daten im Hintergrund sendet
`frame-src`	Welche externen Seiten in einem `<iframe>` auf Ihrer Seite eingebettet werden dürfen	Beim Einbetten eines YouTube/Vimeo-Videos, einer Google-Maps-Karte, eines Formulars eines anderen Dienstes
`media-src`	Von wo Audio-/Videodateien geladen werden dürfen, die mit `<audio>`/`<video>` abgespielt werden	Wenn Sie Podcasts oder eigenes Video außerhalb Ihrer Domain hosten (z. B. auf einem separaten CDN)
`object-src`	Steuert `<object>`, `<embed>` und `<applet>` (Flash und alte Browser-Plugins)	Nie — lassen Sie sie immer bei `'none'`, es ist veraltete und unsichere Technologie
`base-uri`	Welche URLs die Seite als Basis für relative Links verwenden darf (`<base>`-Tag)	Fast nie — `'self'` ist in 99 % der Fälle richtig
`form-action`	An welche URLs ein Formular auf Ihrer Seite gesendet werden darf (`action=`)	Wenn ein Formular Daten an eine externe Domain sendet (z. B. ein Zahlungsgateway mit Weiterleitung)
`frame-ancestors`	Wer IHRE Seite in einem `<iframe>` einbetten darf (Anti-Clickjacking-Schutz)	Fast nie — `'self'` deckt bereits die meisten Fälle ab
`upgrade-insecure-requests`	Erzwingt, dass jede über HTTP angeforderte Ressource automatisch über HTTPS neu geladen wird (nimmt keine Werte, steht allein)	Immer aktiviert lassen, wenn Ihre Seite HTTPS verwendet (heute die Norm)

🔍 Wie Man den Gesuchten Wert Findet, Wenn Etwas Kaputtgeht

Sie haben drei Möglichkeiten herauszufinden, welche Domain in Ihrer CSP fehlt, von der schnellsten bis zur gründlichsten:

Browser-Konsole (F12 → Tab „Console"): die direkteste Methode. Jede blockierte Ressource erscheint als rote Zeile mit dem Wortlaut „Refused to load/execute... because it violates the following Content Security Policy directive: 'script-src ...'" — der letzte Teil nennt die genaue Direktive, und direkt davor steht die vollständige URL der blockierten Ressource. Kopieren Sie die Domain dieser URL und fügen Sie sie dieser Direktive hinzu.
Browser-Tab „Network" (F12 → „Network"): nützlich, wenn Sie sehen möchten, von welchen Domains Ihre Seite tatsächlich abhängt — noch bevor Sie CSP aktivieren. Laden Sie die Seite bei geöffnetem Tab neu und Sie sehen jede Anfrage mit ihrer Herkunftsdomain — so wissen Sie im Voraus, was Sie autorisieren müssen.
Die eigene Dokumentation des externen Dienstes: Wenn Sie einen Live-Chat, ein Zahlungsformular oder ein bekanntes Drittanbieter-Widget installieren, suchen Sie auf dessen Hilfeseite nach „CSP" oder „Content Security Policy" — die meisten seriösen Dienste (Stripe, Intercom, HubSpot usw.) veröffentlichen genau, welche Domains Sie in welcher Direktive autorisieren müssen, da dies eine sehr häufige Frage unter ihren eigenen Kunden ist.

🧩 Vollständiges Schritt-für-Schritt-Beispiel: Sie installieren ein Chat-Widget eines externen Anbieters und nach Aktivierung von CSP erscheint es nicht mehr. Sie öffnen die Konsole (F12) und sehen:

Refused to load the script 'https://widget.chatanbieter.com/loader.js' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline'"

. Sie finden script-src im Textfeld und fügen die Domain hinzu: aus script-src 'self' 'unsafe-inline'; wird script-src 'self' 'unsafe-inline' https://widget.chatanbieter.com;. Sie speichern, laden die Seite mit geöffnetem F12 erneut — lädt der Chat und erscheint kein neuer zugehöriger Fehler, ist es gelöst. Muss sich der Chat nach dem Laden auch mit einer anderen Domain verbinden, um Nachrichten zu senden, sehen Sie einen zweiten Fehler bei connect-src und wiederholen den Vorgang mit dieser Direktive.

📖 Wo Man die Vollständige Referenz Nachschlägt

Mit den 12 Direktiven aus der obigen Tabelle lösen Sie praktisch jeden echten Fall in WordPress. Falls Sie jemals eine speziellere Direktive brauchen, die hier nicht steht (es gibt insgesamt mehr als 20, einige sehr selten außerhalb komplexer Webanwendungen verwendet), ist die offizielle und vollständigste Referenz die Dokumentation von MDN Web Docs (Mozilla), die die vollständige Liste mit Beispielen und Browser-Kompatibilität pflegt — suchen Sie „MDN Content-Security-Policy" in einer beliebigen Suchmaschine. Es ist dieselbe Quelle, die Browser-Entwickler selbst verwenden.

🛠️ Auch innerhalb des Plugins selbst: auf demselben Headers-Tab lässt Sie der Abschnitt „Logging und Diagnose" protokollieren, welche Header tatsächlich gesendet werden, und sie in einem Diagnosepanel anzeigen — nützlich, um zu bestätigen, dass die gespeicherte Richtlinie wirklich bei den Browsern Ihrer Besucher ankommt, ohne sich nur auf die Ansicht des Seitenquelltexts zu verlassen.

🔌 Permissions-Policy — Browser-API-Kontrolle

🎯 Was es tut (einfache Erklärung)

Stellen Sie sich Ihre Website als ein Haus vor und jeder Besucher kommt mit seinem Handy herein. Diese Berechtigung sagt dem Browser: „Diese Seite muss nicht wissen, wo Sie sind, Ihr Gesicht sehen oder Ihnen zuhören". Selbst wenn ein böswilliges Skript auf Ihre Seite gelangt, leiht der Browser ihm keine Kamera, kein Mikrofon und keinen Standort.

⚠️ Warum es wichtig ist (echtes Szenario)

Denken Sie darüber nach: Sie haben einen Online-Shop. Ein Hacker findet eine Schwachstelle in einem Plugin, das Sie vor 2 Jahren installiert haben, und injiziert ein Skript. Dieses Skript könnte still die Kamera des Besuchers einschalten, seinen genauen Standort abrufen oder mit dem Mikrofon aufnehmen. Ohne Permissions-Policy sagt der Browser nicht nein. Mit aktivierter Funktion antwortet der Browser: „Entschuldigung, diese Seite hat keine Erlaubnis, die Kamera zu benutzen". Und der Besucher erfährt nie von dem Versuch.

🧠 Stellen Sie es sich so vor: Es ist, als würden Sie einem Angestellten sagen: „Sie arbeiten an der Theke, Sie brauchen nicht die Schlüssel für den Safe". Selbst wenn jemand seine Identität stiehlt und in den Laden kommt, kann er den Safe nicht öffnen, weil dieser Angestellte nie Zugang hatte. Permissions-Policy macht genau das: es sagt dem Browser „Diese Seite braucht keine Kamera, gib keinen Zugriff, selbst wenn darum gebeten wird".

🧩 Was blockiert es genau?

Dies sind Telefon- oder Computerfunktionen, die eine normale Website NICHT benötigt, um zu funktionieren. Wenn Ihre Seite ein Blog, ein Shop oder eine Unternehmensseite ist, sollten Sie keine davon benötigen:

📡 Standort

Beispiel: Eine Bäckerei-Website muss nicht wissen, wo Sie wohnen, um Ihnen einen Kuchen zu zeigen. Risiko: Ein Spionageskript könnte Ihre Besucher verfolgen. Blockiert ✅

🎥 Kamera

Beispiel: Eine Rezeptseite muss Sie nicht sehen, um Ihnen das Kochen beizubringen. Risiko: Besucher ausspionieren, indem sie ohne ihr Wissen aufgenommen werden. Blockiert ✅

🎤 Mikrofon

Beispiel: Eine digitale Zeitung muss Sie nicht hören, um Ihnen Nachrichten zu zeigen. Risiko: Aufzeichnung privater Gespräche. Blockiert ✅

💳 Zahlungen / 🔔 Benachrichtigungen

Beispiel: Die meisten Seiten verwenden ihr eigenes Zahlungsformular oder Drittanbieter-Plugins, nicht die native Browser-API. Risiko: Nicht autorisierte Skripte, die Geld abheben oder gefälschte Benachrichtigungen senden. Blockiert ✅

🔄 Sensoren / 🔗 USB

Beispiel: Eine Nachrichtenseite muss nicht wissen, ob Sie gehen (Beschleunigungsmesser) oder auf Ihre USB-Geräte zugreifen. Risiko: Wissen, ob der Benutzer stillsteht oder sich bewegt, oder Zugriff auf USB-Dateien ohne Erlaubnis. Blockiert ✅

✅ Ist es sicher zu aktivieren? Ja, absolut. Die meisten WordPress-Seiten verwenden keine dieser Funktionen (Kamera, Mikrofon, GPS...), um zu funktionieren. Es ist wie das Schließen einer Tür, die bereits geschlossen war: Es beeinträchtigt nichts und schützt, wenn jemand versucht, sie zu öffnen. Wenn Ihre Seite ein Blog, ein Shop, eine Landing Page oder eine Unternehmensseite ist, aktivieren Sie es ohne Bedenken. Nur wenn Ihre Seite Videoanrufe anbietet oder den Standort des Benutzers verwendet, sollten Sie es deaktivieren.

🔐 SRI (Subresource Integrity) — CDN-Ressourcenschutz

🎯 Was es tut (einfache Erklärung)

Stellen Sie sich vor, Sie bestellen eine Pizza zur Lieferung. Der Lieferant bringt Ihnen eine versiegelte Schachtel mit einem Sicherheitssiegel. Wenn das Siegel gebrochen ist, wissen Sie, dass jemand es geöffnet hat, und essen sie nicht. SRI macht genau das mit den Dateien, die Ihre Seite von anderen Servern lädt (Google Fonts, jQuery, Bootstrap...): es bringt ein „digitales Siegel" auf jeder Datei an. Wenn die Datei modifiziert ankommt (z.B. von einem Hacker), erkennt der Browser, dass das Siegel gebrochen ist, und lehnt sie ab. Der Benutzer merkt nichts, ist aber geschützt.

⚠️ Warum es wichtig ist (echtes Szenario)

Fast alle Websites verwenden externe Ressourcen: Google Fonts für schöne Schriftarten, jQuery für visuelle Effekte, Bootstrap für mobile Darstellung, Google Analytics für Besucherstatistiken... All diese Dateien befinden sich auf Servern, die Sie NICHT kontrollieren. Es gab reale Fälle, in denen Hacker bösartigen Code in bekannte CDNs eingeschleust haben. Ohne SRI würde Ihre Seite diesen Virus laden, ohne dass Sie es merken. Mit SRI sagt der Browser: „Diese Datei stimmt nicht mit ihrem Fingerabdruck überein, ich blockiere sie".

🔍 Realer Fall, der passiert ist: 2018 gelang es einem Angreifer, eine JavaScript-Datei auf einem von Millionen von Websites genutzten CDN zu modifizieren (eine Bibliothek namens Event-Stream). Die modifizierte Datei stahl Kryptowährungen von Besuchern. Wenn diese Websites SRI aktiviert gehabt hätten, hätte der Browser erkannt, dass die Datei nicht mehr mit ihrem ursprünglichen Fingerabdruck übereinstimmt, und sie automatisch blockiert. Niemand hätte Geld verloren.

⚙️ Wie es in 3 Schritten funktioniert (einfach)

1️⃣ Automatischer Scan

SeenSecure durchsucht Ihre Seite und findet alle Dateien, die von externen Servern geladen werden (Google Fonts, jQuery, Bootstrap, Icons usw.). Es ist wie eine Bestandsaufnahme von allem, was in Ihr Haus kommt.

2️⃣ Fingerabdruck wird berechnet

Für jede Datei generiert SeenSecure einen eindeutigen „digitalen Fingerabdruck" (einen speziellen Code, der diese genaue Datei identifiziert). Es ist wie die Aufnahme von Fingerabdrücken jeder Ressource. Ändert sich die Datei auch nur um einen Buchstaben, ändert sich der Fingerabdruck vollständig.

3️⃣ Aktiver Schutz

Wenn jemand Ihre Seite besucht, vergleicht der Browser den Fingerabdruck der ankommenden Datei mit dem, den sie haben sollte. Wenn sie übereinstimmen → wird die Datei normal ausgeführt. Wenn sie nicht übereinstimmen → wird die Datei abgelehnt. So einfach. Der Besucher sieht die Seite korrekt und erfährt nie, dass es einen Angriffsversuch gab.

📌 Wie oft muss neu gescannt werden? Nur wenn Sie etwas Neues hinzufügen: ein Plugin, das jQuery von einem CDN lädt, ein Theme, das Google Fonts verwendet, ein neues Icon. Das heißt, fast nie. Und wenn Sie es tun, ist es nur ein Klick im Panel. Die restliche Zeit arbeitet SRI von selbst.

✅ Ist es sicher zu aktivieren? Ja, absolut. SRI verlangsamt Ihre Seite nicht (die Überprüfung erfolgt durch den Browser des Besuchers, nicht durch Ihren Server). Es bricht nichts, wenn die Dateien legitim sind. Der einzige Fall, in dem es etwas blockieren würde, ist, wenn eine CDN-Datei modifiziert wurde... und genau das wollen wir. Aktivieren Sie es und vergessen Sie es.

📋 Zusammenfassung & Empfehlungen

Nicht alle Header haben das gleiche Risiko- oder Dringlichkeitsniveau. Diese Tabelle hilft Ihnen bei der Priorisierung:

Sofort aktivieren

Diese Header haben keine negativen Nebenwirkungen und schützen vor häufigen Angriffen:

✅ X-Frame-Options: DENY — Clickjacking

✅ X-Content-Type-Options: nosniff — MIME-Sniffing

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

✅ Permissions-Policy — Browser-APIs

✅ SRI — CDN-Ressourcenintegrität

Mit Vorsicht aktivieren

Diese Header erfordern vorherige Überprüfung. Sie können die Seite blockieren, wenn sie falsch konfiguriert sind:

⚠️ HSTS — Beginnen Sie mit einer niedrigen max-age (3600). Erhöhen Sie erst auf 2 Jahre, wenn Sie zu 100% sicher sind, dass HTTPS niemals deaktiviert wird.

⚠️ CSP — Nicht mit dem vorausgefüllten einzeiligen Standardwert aktivieren. Bauen Sie die Richtlinie zuerst selbst im Monitoring-Modus auf und beobachten Sie dabei die Browserkonsole. Wenn etwas blockiert wird, passen Sie die Richtlinie an.

🎯 Empfohlene Aktivierungsreihenfolge: 1️⃣ X-Frame-Options → 2️⃣ X-Content-Type-Options → 3️⃣ Referrer-Policy → 4️⃣ HSTS (mit Vorsicht) → 5️⃣ CSP (mit Vorsicht). Die ersten 3 sind sicher und können zusammen aktiviert werden.