Analysezeitpunkt: 2026-06-29 12:18:22
Gesamtbewertung
⚠ Diese Website weist schwerwiegende DSGVO-Mängel auf. Es besteht dringender Handlungsbedarf.
DSGVO-Probleme erkannt (3):
❌ 2 Drittanbieter-Server außerhalb der EU/des EWR — Datenübermittlung ohne Rechtsgrundlage kann gegen Art. 44–49 DSGVO verstoßen.
Betroffene Server außerhalb der EU:
⚠ Keine Content Security Policy — erhöhtes Risiko für Cross-Site-Scripting (XSS) und Datendiebstahl.
⚠ Fehlende oder unsichere Referrer-Policy — URLs mit personenbezogenen Daten können an Dritte weitergegeben werden.
Hinweis: Diese automatisierte Analyse ersetzt keine rechtliche Beratung. Für eine vollständige DSGVO-Bewertung konsultieren Sie einen Datenschutzbeauftragten.
↓ Detaillierte Ergebnisse zu allen Kategorien finden Sie weiter unten.
Die Website nutzt eine verschlüsselte Verbindung (HTTPS).
Neueste Verschlüsselung aktiv (TLS 1.3 — TLSv1.3).
Das Sicherheitszertifikat ist gültig (läuft ab am 2026-08-31).
Starke Verschlüsselungsmethode (TLS_AES_256_GCM_SHA384, 256 Bit).
Kein HSTS-Header gesetzt. Browser werden nicht gezwungen, die verschlüsselte Verbindung zu nutzen.
HSTS (HTTP Strict Transport Security) sagt dem Browser: „Diese Domain IMMER über HTTPS aufrufen — egal was passiert." Das verhindert, dass ein Angreifer im WLAN die erste, ungeschützte Verbindung abfängt. Voraussetzung: Ihre Website läuft schon stabil über HTTPS.
Datei: .htaccess im Web-Root
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>⚠ max-age=31536000 sind 1 Jahr (in Sekunden). includeSubDomains gilt für blog.ihre-domain.de, shop.ihre-domain.de usw. — nur einbauen, wenn ALLE Subdomains HTTPS können, sonst sind die unerreichbar.
Datei: .htaccess im WordPress-Root
# BEGIN WebForensik HSTS
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>
# END WebForensik HSTS⚠ OBERHALB der „# BEGIN WordPress"-Zeile einfügen. Erst aktivieren, wenn HTTPS seit ein paar Tagen stabil läuft — der Header ist bewusst schwer rückgängig zu machen (Browser merken sich die Anweisung).
Datei: functions.php Ihres CHILD-Themes (Design → Theme-Datei-Editor → functions.php)
add_action('send_headers', function () {
header('Strict-Transport-Security: max-age=31536000; includeSubDomains');
});⚠ NIE direkt das Haupt-Theme bearbeiten — Änderungen sind bei Updates weg. Vorher Backup der functions.php!
✓ So prüfen Sie, ob es funktioniert: Browser-Konsole F12 → Tab „Netzwerk" → Seite neu laden → erste Anfrage anklicken → „Response Headers" — dort muss „strict-transport-security: max-age=31536000…" stehen.
Keine Content Security Policy (CSP) gefunden. Die Website hat keinen Schutz gegen eingeschleusten Schadcode.
Eine Content Security Policy (CSP) ist wie eine Türsteher-Regel für den Browser: „Skripte und Stile dürfen nur aus diesen erlaubten Quellen geladen werden." Ohne CSP kann eingeschleuster Schadcode (XSS) ungehindert nachladen, was er will. Starten Sie mit einer einfachen, sicheren Grundregel.
Datei: .htaccess im Web-Root
<IfModule mod_headers.c>
Header always set Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline'; font-src 'self' https: data:; object-src 'none'; frame-ancestors 'self'; base-uri 'self'"
</IfModule>⚠ Diese Policy ist bewusst pragmatisch (erlaubt Inline-Styles, weil viele Themes/Plugins sie brauchen). Wenn nach dem Aktivieren etwas nicht funktioniert: F12 → Konsole zeigt „Refused to load…" — dann die jeweilige Domain hinter script-src bzw. img-src ergänzen.
Datei: .htaccess im WordPress-Root
# BEGIN WebForensik CSP
<IfModule mod_headers.c>
Header always set Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline'; font-src 'self' https: data:; object-src 'none'; frame-ancestors 'self'; base-uri 'self'"
</IfModule>
# END WebForensik CSP⚠ WordPress nutzt häufig externe Skripte (Google Fonts, jQuery-CDN, Analytics-Pixel) — wenn die wegen CSP geblockt werden: in der Konsole sehen, welche Domain blockiert wurde, dann diese Domain hinter „script-src 'self'" mit Leerzeichen ergänzen.
Datei: functions.php Ihres CHILD-Themes
add_action('send_headers', function () {
header("Content-Security-Policy: default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline'; font-src 'self' https: data:; object-src 'none'; frame-ancestors 'self'; base-uri 'self'");
});⚠ Wenn Sie unsicher sind: erst mit „Content-Security-Policy-Report-Only" beginnen (nur überwachen, nicht blockieren), Verstöße in der Konsole beobachten, dann auf scharfe Policy umstellen.
✓ So prüfen Sie, ob es funktioniert: Seite öffnen, F12 → Konsole — keine roten „Refused to load…"-Meldungen. Tab „Netzwerk" → erste Anfrage → Response Header „content-security-policy" sichtbar.
Keine Referrer-Policy gesetzt. Beim Klick auf externe Links wird die vollständige Seiten-URL an andere Websites weitergegeben.
Ohne Referrer-Policy übermittelt der Browser bei jedem Klick die komplette URL Ihrer aktuellen Seite (inkl. Suchbegriffen, Nutzernamen in URL-Parametern) an die Ziel-Website. Datenschutzrelevant nach Art. 5 DSGVO. Empfohlene sichere Einstellung: strict-origin-when-cross-origin.
Datei: .htaccess im Web-Root
<IfModule mod_headers.c>
Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>⚠ „strict-origin-when-cross-origin" ist der moderne Standard: bei Klicks auf andere Domains wird nur Ihre Domain (ohne Pfad/Parameter) gesendet — bei internen Klicks die volle URL. Strenger wäre „no-referrer" (gar nichts senden), aber das bricht manche Analyse-Tools.
Datei: .htaccess im WordPress-Root
<IfModule mod_headers.c>
Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>⚠ WordPress sendet seit Version 4.9 standardmäßig schon ein meta-Tag mit dieser Policy — der HTTP-Header oben überschreibt aber für alle Ressourcen (Bilder, Skripte), nicht nur das HTML-Dokument.
Datei: functions.php Ihres CHILD-Themes
add_action('send_headers', function () {
header('Referrer-Policy: strict-origin-when-cross-origin');
});⚠ Backup vor jeder functions.php-Änderung anlegen.
✓ So prüfen Sie, ob es funktioniert: F12 → Netzwerk → erste Anfrage → Response Headers — „referrer-policy: strict-origin-when-cross-origin" muss sichtbar sein.
Kein MIME-Typ-Schutz (X-Content-Type-Options fehlt). Browser könnten Dateien falsch interpretieren.
Ohne den Header „X-Content-Type-Options: nosniff" rät der Browser den Dateityp aus dem Inhalt — was Angreifer ausnutzen können (z.B. eine als .jpg getarnte HTML-Datei wird als HTML ausgeführt). Der Fix ist eine einzige Zeile.
Datei: .htaccess im Web-Root
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
</IfModule>⚠ Keinerlei Nebenwirkungen zu erwarten — gilt als sicherer Standard und ist seit Jahren best practice.
Datei: .htaccess im WordPress-Root
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
</IfModule>⚠ Kann gefahrlos parallel zu anderen Header-set-Einträgen stehen.
Datei: functions.php Ihres CHILD-Themes
add_action('send_headers', function () {
header('X-Content-Type-Options: nosniff');
});⚠ Backup vor jeder Änderung an functions.php.
✓ So prüfen Sie, ob es funktioniert: F12 → Netzwerk → Response Header: „x-content-type-options: nosniff".
Kein Clickjacking-Schutz. Die Website könnte in andere Seiten eingebettet werden, um Nutzer zu täuschen.
Ohne Clickjacking-Schutz kann Ihre Website unsichtbar in eine fremde, betrügerische Seite eingebettet werden („Geben Sie hier Ihr Passwort ein" — der Klick landet aber auf Ihrer eingeblendeten Login-Seite). Lösung: SAMEORIGIN setzen (Einbettung nur durch Ihre eigene Domain).
Datei: .htaccess im Web-Root
<IfModule mod_headers.c>
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self'"
</IfModule>⚠ Beide Header parallel setzen: X-Frame-Options für ältere Browser, frame-ancestors für moderne. Wenn Sie eine CSP haben, ergänzen Sie „frame-ancestors 'self'" dort — nicht doppelt setzen.
Datei: .htaccess im WordPress-Root
<IfModule mod_headers.c>
Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>⚠ Falls Ihre Seite absichtlich anderswo eingebettet wird (z.B. Buchungs-Widget bei Partnern): statt SAMEORIGIN per CSP genau die erlaubten Domains nennen: Header always set Content-Security-Policy "frame-ancestors 'self' https://partner.example.com"
Datei: functions.php Ihres CHILD-Themes
add_action('send_headers', function () {
header('X-Frame-Options: SAMEORIGIN');
});⚠ WordPress versucht eigentlich selbst, X-Frame-Options zu setzen — der Hook überschreibt das gezielt.
✓ So prüfen Sie, ob es funktioniert: F12 → Netzwerk → Response Header: „x-frame-options: SAMEORIGIN".
Keine Permissions-Policy gesetzt. Drittanbieter-Skripte könnten auf Kamera, Mikrofon oder Standort zugreifen.
Die Permissions-Policy kontrolliert, ob Skripte (auch von Drittanbietern) auf Kamera, Mikrofon, Standort, Bewegungssensoren etc. zugreifen dürfen. DSGVO-relevant, weil sensible Geräte-APIs sonst unbemerkt angesprochen werden können.
Datei: .htaccess im Web-Root
<IfModule mod_headers.c>
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), interest-cohort=()"
</IfModule>⚠ „()" am Ende heißt: kein Aufrufer (auch nicht Ihre eigene Seite) darf diese API nutzen. Falls Sie z.B. eine Karten-Funktion mit Geolokalisierung haben: geolocation=(self) statt geolocation=(). „interest-cohort=()" deaktiviert Googles FLoC-Tracking.
Datei: .htaccess im WordPress-Root
<IfModule mod_headers.c>
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()"
</IfModule>⚠ Standard-WordPress braucht keine dieser APIs. Wenn Sie ein Plugin nutzen, das z.B. die Kamera braucht (QR-Scanner, Video-Upload): die entsprechende API auf „(self)" setzen.
Datei: functions.php Ihres CHILD-Themes
add_action('send_headers', function () {
header('Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()');
});⚠ Backup vor jeder Änderung an functions.php.
✓ So prüfen Sie, ob es funktioniert: F12 → Netzwerk → Response Header: „permissions-policy" sichtbar.
Keine Cookies gesetzt — vorbildlich für den Datenschutz.
0 localStorage- und 1 sessionStorage-Einträge gefunden.
| Name | Wert |
|---|---|
| wpEmojiSettingsSupports | {"supportTests":{"flag":false,"emoji":true},"timestamp":1782728298658} |
29 Anfrage(n) an 6 verschiedene Drittanbieter-Server.
2 Drittanbieter-Server außerhalb der EU/des EWR — potenziell problematisch für die DSGVO.
DSGVO-relevant: Daten Ihrer Besucher (mindestens IP-Adresse + User-Agent) werden an Server außerhalb der EU/des EWR übertragen. Seit dem Schrems-II-Urteil (2020) ist das nur mit Standardvertragsklauseln + zusätzlichen Schutzmaßnahmen UND vorheriger Einwilligung zulässig. Beste Lösung: durch EU-Alternativen ersetzen, wo möglich.
WordPress-Plugin: Häufige Übeltäter und EU-Alternativen: Google Fonts → Bunny Fonts oder lokal hosten (Plugin „OMGF — Host Google Fonts Locally"). Google Analytics → Matomo (selbst gehostet) oder Plausible (EU-Server). Google reCAPTCHA → hCaptcha (EU) oder Friendly Captcha. Google Maps → OpenStreetMap. YouTube-Einbettung → Plugin „WP YouTube Lyte" lädt erst nach Klick. CDN: Cloudflare → BunnyCDN (EU) oder KeyCDN.
✓ So prüfen Sie, ob es funktioniert: Im Inkognito-Modus laden, F12 → Netzwerk → alle Anfragen auflisten → unter „Domain" auf Server außerhalb EU prüfen. Nach Umstellung sollte hier keine US-Domain mehr unaufgefordert geladen werden.
4 Drittanbieter-Server innerhalb der EU/des EWR.
Aufgerufene URLs:
https://b.tile.openstreetmap.org/14/8596/5415.png
https://b.tile.openstreetmap.org/14/8594/5414.png
https://b.tile.openstreetmap.org/14/8595/5416.png
https://b.tile.openstreetmap.org/14/8593/5415.png
https://b.tile.openstreetmap.org/14/8594/5417.png
https://b.tile.openstreetmap.org/14/8597/5414.png
https://b.tile.openstreetmap.org/14/8597/5417.png
Aufgerufene URLs:
https://a.tile.openstreetmap.org/14/8596/5417.png
https://a.tile.openstreetmap.org/14/8593/5414.png
https://a.tile.openstreetmap.org/14/8593/5417.png
https://a.tile.openstreetmap.org/14/8594/5416.png
https://a.tile.openstreetmap.org/14/8595/5415.png
https://a.tile.openstreetmap.org/14/8597/5416.png
https://a.tile.openstreetmap.org/14/8596/5414.png
Aufgerufene URLs:
https://fonts.gstatic.com/s/poppins/v24/pxiEyp8kv8JHgFVrJJfecg.woff2
https://fonts.gstatic.com/s/ubuntu/v21/4iCs6KVjbNBYlgoKfw72.woff2
https://fonts.gstatic.com/s/ubuntu/v21/4iCv6KVjbNBYlgoCjC3jsGyN.woff2
https://fonts.gstatic.com/s/poppins/v24/pxiByp8kv8JHgFVrLCz7Z1xlFQ.woff2
https://fonts.gstatic.com/s/ubuntu/v21/4iCv6KVjbNBYlgoCxCvjsGyN.woff2
https://fonts.gstatic.com/s/worksans/v24/QGY_z_wNahGAdqQ43RhVcIgYT2Xz5u32K8nQBi8Jpg.woff2
Aufgerufene URLs:
https://c.tile.openstreetmap.org/14/8594/5415.png
https://c.tile.openstreetmap.org/14/8596/5416.png
https://c.tile.openstreetmap.org/14/8595/5414.png
https://c.tile.openstreetmap.org/14/8595/5417.png
https://c.tile.openstreetmap.org/14/8593/5416.png
https://c.tile.openstreetmap.org/14/8597/5415.png
Aufgerufene URLs:
https://fonts.googleapis.com/css?family=Roboto:400%7CWork+Sans:800&display=swap
https://fonts.googleapis.com/css?family=Poppins:400%2C700|Ubuntu:400%2C700%2C500&display=swap&ver=7.0
Aufgerufene URLs:
https://nominatim.openstreetmap.org/search?format=json&limit=1&q=Arminstr.%2080%2032756%20Detmold
Keine bekannten Tracker erkannt.
0 von 2 externen Ressource(n) nutzen Integritätsprüfung (SRI).
Nur ein Teil Ihrer externen Ressourcen (0 von 2) ist mit SRI gesichert. Ergänzen Sie integrity-Attribute auch bei den restlichen.
WordPress-Plugin: Vorgehen: Quelltext der Seite ansehen → alle <script src="https://…"> und <link href="https://…"> ohne integrity-Attribut → unter https://www.srihash.org/ Hash erzeugen → integrity="sha384-…" crossorigin="anonymous" ergänzen. Plugin „WP-SRI" kann das für viele Fälle automatisieren.
✓ So prüfen Sie, ob es funktioniert: F12 → Konsole bei Seitenladung: keine „Failed to find a valid digest"-Meldungen. Quelltext: alle externen <script>/<link> haben integrity-Attribut.
Keine externen Ressourcen nutzen Integritätsprüfung. Manipulierte Dateien würden nicht erkannt.
SRI (Subresource Integrity) ist eine Prüfsumme, die im HTML-Code angibt, wie eine extern geladene Datei aussehen MUSS. Manipuliert jemand die externe Datei (z.B. wenn ein CDN gehackt wird), lädt der Browser sie nicht aus. Sie ergänzen das Attribut „integrity" am script/link-Tag.
WordPress-Plugin: In WordPress lassen sich SRI-Hashes selten manuell ergänzen (Skripte werden via wp_enqueue_script() gesetzt). Plugin „WP-SRI" (im Plugin-Verzeichnis) ergänzt integrity-Hashes automatisch für externe Skripte/Styles. Für statisch ins Theme eingebundene Ressourcen: Hash unter https://www.srihash.org/ generieren, integrity="sha384-…" und crossorigin="anonymous" am <script>/<link>-Tag ergänzen.
✓ So prüfen Sie, ob es funktioniert: F12 → Netzwerk → Anfragen mit Code 200 von CDN-Domains (cdn.jsdelivr.net, cdnjs.cloudflare.com etc.) → im HTML-Quelltext muss der Tag „integrity=\"sha384-…\" crossorigin=\"anonymous\"" enthalten.
Keine CAA-Einträge. Jede Zertifizierungsstelle könnte ein Zertifikat für diese Domain ausstellen.
CAA-Einträge (Certification Authority Authorization) legen im DNS fest, welche Zertifizierungsstellen Zertifikate für Ihre Domain ausstellen dürfen. Ohne CAA-Eintrag könnte ein Angreifer bei jeder beliebigen CA ein falsches Zertifikat für Ihre Domain bestellen. Der Eintrag ist eine reine DNS-Konfiguration und wird im DNS-Panel Ihres Domain-Anbieters (NICHT in WordPress) gesetzt.
Suchen Sie Ihren Hoster in der Tabelle, kopieren Sie die passenden Werte ins DNS-Panel. Bei Mehrfach-CAs: für jede CA einen eigenen CAA-Record anlegen (alle mit Tag issue, Flag 0, Name @). Zusätzlich empfohlen: ein iodef-Record mit einer Kontakt-E-Mail für Missbrauchs-Meldungen.
| # | Hoster | Verwendete CA(s) | CAA-Wert(e) — Tag issue |
|---|---|---|---|
| 1 | Hetzner Webhosting (Basic-Zertifikat, kostenlos im Paket) | DigiCert (Programm „Encryption Everywhere") | digicert.com |
| 1 | Hetzner Webhosting (Let’s Encrypt, kostenlos) | Let’s Encrypt (ISRG) | letsencrypt.org |
| 2 | All-Inkl | Let’s Encrypt + Sectigo (Pro) | letsencrypt.orgsectigo.com |
| 3 | IONOS (1&1) | DigiCert (GeoTrust) + Let’s Encrypt | digicert.comletsencrypt.org |
| 4 | STRATO | Sectigo + Let’s Encrypt | sectigo.comletsencrypt.org |
| 5 | Cloudflare (Universal SSL) | Google Trust Services + DigiCert + Let’s Encrypt | pki.googdigicert.comletsencrypt.org |
| 6 | AWS (ACM / CloudFront) | Amazon Trust Services | amazon.comamazontrust.comawstrust.comamazonaws.com |
| 7 | Mittwald | Let’s Encrypt + Sectigo | letsencrypt.orgsectigo.com |
| 8 | Webgo | Let’s Encrypt + Sectigo | letsencrypt.orgsectigo.com |
| 9 | raidboxes (Managed WordPress) | Let’s Encrypt | letsencrypt.org |
| 10 | Host Europe / DomainFactory | Sectigo + Let’s Encrypt | sectigo.comletsencrypt.org |
Name Typ Flag Tag Wert
@ CAA 0 issue "digicert.com"
@ CAA 0 issue "letsencrypt.org"
@ CAA 0 iodef "mailto:security@ihre-domain.de"
Die iodef-Zeile (letzte Zeile) ist optional aber empfohlen: dort melden CAs Missbrauchsversuche an Sie. Falls Sie eine Sub-Domain zusätzlich absichern wollen (z.B. shop.ihre-domain.de), separate Records mit dem Sub-Domain-Namen statt @ anlegen — moderne CAs prüfen aber auch parent-CAA automatisch.
Wenn Sie Ihren Hoster nicht in der Liste finden: Schauen Sie das aktuell ausgestellte Zertifikat im Browser an (Schloss-Symbol → Zertifikat anzeigen → Aussteller). Dort steht der CA-Name (z.B. „Sectigo RSA Domain Validation Secure Server CA" → Wert sectigo.com). Den Wert als CAA-Record anlegen, fertig.
WordPress-Plugin: Die CAA-Records werden NICHT in WordPress angelegt, sondern im DNS-Panel Ihres Domain-Anbieters oder DNS-Providers (z.B. Hetzner-Robot, IONOS-Domains, Cloudflare-Dashboard, INWX, ns3.hajo-nolte.de etc.). Übliche Bezeichnung im DNS-Panel: „CAA-Record" oder unter „TXT-Records" mit Typ-Auswahl „CAA". Je CA ein separater Record.
✓ So prüfen Sie, ob es funktioniert: Auf https://www.ssllabs.com/ssltest/analyze.html?d=ihre-domain.de → Abschnitt „DNS CAA" → alle Ihre CAs sollten dort aufgelistet sein. Oder per dig: dig CAA ihre-domain.de.
4 Nameserver vorhanden — gute Redundanz.
Keine IPv6-Unterstützung (kein AAAA-Eintrag).
Ihre Domain hat keine IPv6-Adresse (AAAA-Eintrag). Über 40% aller deutschen Internetnutzer sind über IPv6 unterwegs (Mobilfunk vor allem) — die müssen dann den Umweg über IPv4-Gateways nehmen, was langsamer ist.
WordPress-Plugin: Reine DNS+Server-Sache. Schritt 1: prüfen, ob Ihr Hoster eine IPv6-Adresse für Sie hat (im Kundenpanel oder per Support-Anfrage). Schritt 2: im DNS-Panel einen AAAA-Eintrag mit dieser IPv6 anlegen. Schritt 3: testen.
✓ So prüfen Sie, ob es funktioniert: dig AAAA ihre-domain.de — oder online https://ipv6-test.com/validate.php?url=ihre-domain.de.
SPF-Eintrag vorhanden: v=spf1 mx a include:spf.protection.outlook.com ?all — schützt vor E-Mail-Spoofing.
DMARC-Eintrag vorhanden: v=DMARC1; p=none; rua=mailto:rua@dmarc.brevo.com — E-Mail-Authentifizierung aktiv.
Keine security.txt-Datei gefunden (RFC 9116). Sicherheitsforscher wissen nicht, wie sie Schwachstellen melden können.
Eine security.txt (RFC 9116) sagt Sicherheitsforschern, wie sie Schwachstellen verantwortungsvoll an Sie melden können. Ohne diese Datei landen Hinweise vielleicht im Spam oder werden gar nicht erst geschickt. Eine reine Textdatei am korrekten Pfad genügt.
Datei: /.well-known/security.txt (Ordner anlegen, falls noch nicht vorhanden)
Contact: mailto:security@ihre-domain.de
Expires: 2027-12-31T23:59:59.000Z
Preferred-Languages: de, en
Canonical: https://ihre-domain.de/.well-known/security.txt⚠ „security@ihre-domain.de" durch Ihre tatsächliche Sicherheitskontakt-Adresse ersetzen (oder eine generische wie info@). „Expires" muss ein zukünftiges Datum sein und sollte regelmäßig erneuert werden. Datei ist eine simple .txt-Datei, kein PHP.
Datei: Datei security.txt im Ordner /.well-known/ unter Ihrem WordPress-Root
Contact: mailto:security@ihre-domain.de
Expires: 2027-12-31T23:59:59.000Z
Preferred-Languages: de, en
Canonical: https://ihre-domain.de/.well-known/security.txt⚠ Per FTP/SFTP einen Ordner ".well-known" im WordPress-Root anlegen (der Punkt am Anfang ist wichtig — bei manchen FTP-Programmen muss man „versteckte Dateien anzeigen" aktivieren), darin die Datei security.txt mit obigem Inhalt speichern. Falls WordPress die URL umleitet: in .htaccess ergänzen: RewriteRule ^\.well-known/ - [L]
WordPress-Plugin: Plugin „security.txt" (im Plugin-Verzeichnis suchen) ermöglicht die Konfiguration über das WordPress-Backend ohne FTP.
✓ So prüfen Sie, ob es funktioniert: https://ihre-domain.de/.well-known/security.txt im Browser aufrufen — Inhalt muss sichtbar sein (kein 404).
Keine externen Reporting-Endpunkte erkannt.
Kein Consent-Banner nötig — keine Tracker oder Drittanbieter-Cookies erkannt.
Datenschutzerklärung verlinkt: „Datenschutz" (https://farben-willer.de/datenschutz/).
Impressum verlinkt: „Impressum" (https://farben-willer.de/impressum/).
Datenschutzerklärung ist erreichbar (HTTP 200).
Alle fehlenden Security-Header zu einem einzigen Block kombiniert. Diesen Block ans Ende Ihrer .htaccess hängen — fertig. 6 Header werden gesetzt.
Die Content-Security-Policy oben enthält bewusst 'unsafe-inline' sowohl für style-src als auch für script-src. Damit ist KEIN vollständiger XSS-Schutz möglich — das ist eine pragmatische Entscheidung, kein Bug.
Warum? Ein typisches WordPress-Setup (Theme + 5-15 Plugins) schreibt 10-50 verschiedene Inline-<script>-Blocks ins HTML: jQuery-Init, Slider-Initialisierung, Cookie-Banner, Tracking, GTM, Web Vitals, Lazy-Load, Speculation Rules usw. Wenn die strikte CSP script-src 'self' diese alle blockt, ist die Site optisch und funktional kaputt (Slider weiß, Cookie-Banner zerschossen, Plugins tot). Genau dieses Problem hatten Sie soeben mit Ihrer Slider-Seite.
Konsequenz fürs Scoring: Sites, die WordPress mit Plugins einsetzen, können in dieser App maximal ~75-85 Punkte in der CSP-Kategorie erreichen — das volle 100%-Rating ist erst möglich, wenn der inline-Code per Nonce oder Hash signiert wird (technisch anspruchsvoll, bricht bei jedem Theme/Plugin-Update).
Wege zum vollen XSS-Schutz (in steigender Komplexität):
Wer keinen dieser Wege geht, lebt mit 'unsafe-inline' — wie ca. 95% aller produktiven WordPress-Sites im Web. Die anderen CSP-Direktiven schützen weiterhin: default-src 'self' blockt externe Ressourcen, object-src 'none' verbietet Flash/Java, frame-ancestors 'self' verhindert Clickjacking, base-uri 'self' verhindert Base-Tag-Hijacking. Es ist kein Maximalschutz, aber realistischer Schutz für die WP-Praxis.
Diesen Block ans Ende Ihrer .htaccess im Web-Root hängen — fertig.
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline'; font-src 'self' https: data:; object-src 'none'; frame-ancestors 'self'; base-uri 'self'; upgrade-insecure-requests"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), interest-cohort=(), browsing-topics=()"
</IfModule>
Diesen Block OBERHALB der Zeile „# BEGIN WordPress" einfügen, sonst überschreibt WP ihn bei Permalink-Änderungen.
# BEGIN WebForensik Security
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline'; font-src 'self' https: data:; object-src 'none'; frame-ancestors 'self'; base-uri 'self'; upgrade-insecure-requests"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), interest-cohort=(), browsing-topics=()"
</IfModule>
# END WebForensik Security
Falls Ihr Hoster .htaccess-Änderungen nicht erlaubt: dieses PHP-Snippet ans Ende der functions.php Ihres CHILD-Themes hängen. Vorher Backup machen — NIE das Haupt-Theme bearbeiten, das wird bei Updates überschrieben.
add_action('send_headers', function () {
header("Strict-Transport-Security: max-age=31536000; includeSubDomains");
header("Content-Security-Policy: default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline'; font-src 'self' https: data:; object-src 'none'; frame-ancestors 'self'; base-uri 'self'; upgrade-insecure-requests");
header("Referrer-Policy: strict-origin-when-cross-origin");
header("X-Content-Type-Options: nosniff");
header("X-Frame-Options: SAMEORIGIN");
header("Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), interest-cohort=(), browsing-topics=()");
});
| Header | Wert |
|---|---|
| content-encoding | br |
| content-type | text/html; charset=UTF-8 |
| date | Mon, 29 Jun 2026 10:18:17 GMT |
| link | <https://farben-willer.de/wp-json/>; rel="https://api.w.org/", <https://farben-willer.de/wp-json/wp/v2/pages/135>; rel="alternate"; title="JSON"; type="application/json", <https://farben-willer.de/>; rel=shortlink |
| server | Apache |
| vary | Accept-Encoding,User-Agent |