Analysezeitpunkt: 2026-10-06 18:56:35
Gesamtbewertung
Vergleich mit Scan vom 06.10.2026 18:54 (Score 56 → 58) · Kompletten Verlauf ansehen
✓ Neue Schutzmaßnahmen: dns_caa_yes, dns_ns_ok, dns_spf_yes, dns_dmarc_yes
⚠ Diese Website weist schwerwiegende DSGVO-Mängel auf. Es besteht dringender Handlungsbedarf.
DSGVO-Probleme erkannt (3):
⚠ 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.
❌ Keine Datenschutzerklärung gefunden — Pflicht nach Art. 13 DSGVO.
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 2027-02-15).
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.
Kein lokaler Speicher (Web Storage) genutzt — kein Tracking-Risiko.
Keine Drittanbieter-Anfragen erkannt — alle Inhalte kommen vom eigenen Server.
Keine bekannten Tracker erkannt.
Keine externen Skripte oder Stylesheets geladen.
CAA-Einträge vorhanden: sectigo.com — nur bestimmte Zertifizierungsstellen dürfen Zertifikate ausstellen.
4 Nameserver vorhanden — gute Redundanz.
IPv6-Unterstützung vorhanden (AAAA-Einträge).
SPF-Eintrag vorhanden: v=spf1 include:_spf-eu.ionos.com ~all — schützt vor E-Mail-Spoofing.
DMARC-Eintrag vorhanden: v=DMARC1; p=none; — E-Mail-Authentifizierung aktiv.
security.txt gefunden: https://bbsovg.de/.well-known/security.txt
Kontaktfeld vorhanden (Pflichtfeld) — Sicherheitsforscher können Schwachstellen melden.
Ablaufdatum vorhanden (Pflichtfeld).
Bevorzugte Sprachen angegeben.
Keine externen Reporting-Endpunkte erkannt.
Kein Consent-Banner nötig — keine Tracker oder Drittanbieter-Cookies erkannt.
Keine Datenschutzerklärung gefunden! Pflicht nach Art. 13 DSGVO.
Keine Datenschutzerklärung gefunden — Pflicht nach Art. 13 DSGVO. Bei Verstößen drohen Abmahnungen und Bußgelder. Die Datenschutzerklärung muss von JEDER Seite aus mit einem Klick erreichbar sein (üblich: Footer-Link).
WordPress-Plugin: Schritt 1: Datenschutzerklärung erstellen. Generatoren (juristisch geprüft): https://datenschutz-generator.de (Dr. Schwenke, kostenlos), https://www.e-recht24.de/muster-datenschutzerklaerung.html (Premium-Service kostenpflichtig). Pflichtinhalte u.a.: Name+Anschrift Verantwortlicher, Datenschutzbeauftragter (falls vorhanden), Zweck und Rechtsgrundlage jeder Datenverarbeitung, Empfänger/Drittlandtransfers, Speicherdauer, Betroffenenrechte, Beschwerderecht bei Aufsichtsbehörde. Schritt 2: in WordPress: Seiten → Erstellen → Inhalt einfügen → Veröffentlichen. Schritt 3: unter Einstellungen → Datenschutz die Seite als „Datenschutzseite" markieren. Schritt 4: Footer-Menü erstellen (Design → Menüs → neues Menü → der Position „Footer" zuordnen) und Datenschutzerklärung verlinken.
✓ So prüfen Sie, ob es funktioniert: Von der Startseite: nach unten scrollen → Footer → Link „Datenschutz" oder „Datenschutzerklärung" sichtbar → klick → öffnet die Erklärung. Funktioniert von ALLEN Seiten der Website.
Kein Impressum gefunden — Pflicht nach § 5 DDG (ehemals TMG).
Kein Impressum gefunden — Pflicht nach § 5 DDG (Digitale-Dienste-Gesetz, vormals TMG) für alle geschäftsmäßigen Websites. Selbst rein private Blogs mit Werbeeinblendungen oder Affiliate-Links sind in der Regel impressumspflichtig. Bei Verstößen: Abmahnungen sind sehr verbreitet.
WordPress-Plugin: Schritt 1: Impressum erstellen. Generator (kostenlos): https://www.e-recht24.de/impressum-generator.html. Pflichtangaben u.a.: Name (vollständig), Anschrift (Postfach reicht NICHT), Telefon ODER andere zweite Kontaktmöglichkeit, E-Mail, bei Firmen: Handelsregister + USt-IdNr, ggf. Aufsichtsbehörde, ggf. Berufshaftpflicht. Schritt 2: in WordPress → Seiten → Erstellen → Titel „Impressum" → veröffentlichen. Schritt 3: Footer-Menü → Eintrag „Impressum" hinzufügen. WICHTIG: Impressum muss „leicht erkennbar, unmittelbar erreichbar und ständig verfügbar" sein — ein Footer-Link erfüllt das, ein „über uns" → „dort dann impressum" NICHT.
✓ So prüfen Sie, ob es funktioniert: Footer auf jeder Seite → Link „Impressum" sichtbar → öffnet die Impressums-Seite mit allen Pflichtangaben.
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-type | text/html |
| date | Tue, 06 Oct 2026 16:56:32 GMT |
| retry-after | 180 |
| server | nginx |
| x-ws-origin | available |