Deutsch | English Header-Test API Über WebForensik

WebForensik

Ergebnisse für https://kwork.ru/

Analysezeitpunkt: 2026-07-04 11:29:34

41

Gesamtbewertung

Score-Verlauf für diese Domain Kompletten Verlauf ansehen →

DSGVO-Zusammenfassung

⚠ Diese Website weist schwerwiegende DSGVO-Mängel auf. Es besteht dringender Handlungsbedarf.

DSGVO-Probleme erkannt (6):

❌ 5 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:

  • smartcaptcha.yandexcloud.net (Russian Federation)
  • mc.webvisor.org (Russian Federation)
  • mc.yandex.com (Russian Federation)
  • counter.yadro.ru (Russian Federation)
  • mc.yandex.ru (Russian Federation)

❌ 2 Tracking-Dienst(e) erkannt — ohne vorherige Einwilligung (Opt-in) ein Verstoß gegen Art. 6 Abs. 1 DSGVO und § 25 TDDDG.

Erkannte Tracker:

  • Yandex (FingerprintingInvasive)
  • Yandex (Advertising)

⚠ Drittanbieter-Cookies werden gesetzt — ohne Einwilligung ein Verstoß gegen § 25 TDDDG.

⚠ Fehlende oder unsichere Referrer-Policy — URLs mit personenbezogenen Daten können an Dritte weitergegeben werden.

❌ Kein Cookie-Consent-Banner erkannt, obwohl Tracker oder Drittanbieter-Cookies geladen werden — Verstoß gegen § 25 TDDDG.

❌ 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.

Anzeigen:
95 HTTPS / Verschlüsselung

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-09-29).

Ausreichende Verschlüsselungsmethode (TLS_AES_128_GCM_SHA256, 128 Bit).

☛ Handlungsbedarf: Die Verschlüsselungsmethode ist ausreichend, aber nicht optimal. Bitten Sie Ihren Hoster, stärkere Cipher Suites zu konfigurieren.
70 Erzwungene Verschlüsselung (HSTS)

HSTS ist aktiviert — der Browser wird angewiesen, immer die verschlüsselte Verbindung zu nutzen.

HSTS-Dauer: 15552000 Sekunden (mindestens 180 Tage). Empfohlen: mindestens 1 Jahr.

☛ Handlungsbedarf: Erhöhen Sie den HSTS-max-age-Wert auf mindestens 31536000 (1 Jahr) für optimalen Schutz.
↓ KOMPLETT-LÖSUNG ANZEIGEN Alle fehlenden Security-Header zusammen am Ende des Reports — fertig zum Kopieren.
40 Content Security Policy (CSP)

Content Security Policy vorhanden (via HTTP-Header).

Keine Einschränkung für Skripte definiert (script-src/default-src fehlt).

☛ Handlungsbedarf: Ergänzen Sie Ihre Content Security Policy um eine script-src-Direktive, die festlegt, von wo Skripte geladen werden dürfen. Beispiel: script-src 'self'
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

Ihre CSP ist vorhanden, aber ohne script-src — d.h. für Skripte gilt keine Einschränkung. Genau die sind aber der häufigste XSS-Angriffsvektor. Ergänzen Sie script-src zusammen mit den anderen wichtigen Direktiven.

Apache-Server (klassisches Hosting bei den meisten Anbietern)

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>

⚠ Bestehende CSP-Zeile ersetzen (NICHT zusätzlich eintragen). Diese Policy ist bewusst pragmatisch — sie erlaubt Inline-Styles und data:-URIs für Bilder, weil fast alle Themes (besonders WordPress!) das brauchen. Wenn Sie externe Skripte nutzen (z.B. CDN), Domain in script-src anhängen: script-src 'self' https://cdn.example.com. Wer maximale Sicherheit will, kürzt style-src später schrittweise auf 'self' und prüft im Browser (F12 → Konsole), ob keine Inline-Styles mehr klagen.

WordPress Spezial für WordPress: so tragen Sie es ein

Weg 1: per .htaccess (empfohlen — kein Theme bearbeiten)

Datei: .htaccess im WordPress-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>

⚠ Vorhandenen CSP-Header ersetzen. WICHTIG für WordPress: img-src mit data: erlaubt Emoji + Admin-Bar-SVGs, style-src 'unsafe-inline' erlaubt die zahlreichen Inline-Styles aus Themes und Plugins — ohne diese beiden Direktiven wird die Seite optisch zerschossen. Häufig genutzte WP-Skript-Quellen für script-src: 'self' (eigene), https://www.googletagmanager.com (GTM), https://www.google-analytics.com (GA) — bei Bedarf hinter 'self' mit Leerzeichen anhängen.

Weg 2: per functions.php im Child-Theme (Alternative für Fortgeschrittene)

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'");
});

⚠ Achten Sie auf bestehende send_headers-Hooks — nur einer pro Datei aktiv halten. Backup der functions.php vorher!

✓ So prüfen Sie, ob es funktioniert: F12 → Netzwerk → Response Header content-security-policy enthält „script-src 'self'". Konsole: keine Skript-Blockaden, keine „Refused to load…"-Meldungen.

Einbettungsschutz (frame-ancestors) ist konfiguriert — schützt vor Clickjacking.

↓ KOMPLETT-LÖSUNG ANZEIGEN Alle fehlenden Security-Header zusammen am Ende des Reports — fertig zum Kopieren.
0 Referrer-Policy

Keine Referrer-Policy gesetzt. Beim Klick auf externe Links wird die vollständige Seiten-URL an andere Websites weitergegeben.

☛ Handlungsbedarf: Setzen Sie eine Referrer-Policy, um zu verhindern, dass die vollständige URL Ihrer Seiten an externe Websites weitergegeben wird. DSGVO-relevant: URLs können persönliche Daten enthalten (z.B. Nutzernamen, Suchbegriffe). Empfohlene Einstellung: Referrer-Policy: strict-origin-when-cross-origin
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

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.

Apache-Server (klassisches Hosting bei den meisten Anbietern)

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.

WordPress Spezial für WordPress: so tragen Sie es ein

Weg 1: per .htaccess (empfohlen — kein Theme bearbeiten)

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.

Weg 2: per functions.php im Child-Theme (Alternative für Fortgeschrittene)

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.

↓ KOMPLETT-LÖSUNG ANZEIGEN Alle fehlenden Security-Header zusammen am Ende des Reports — fertig zum Kopieren.
100 MIME-Typ-Schutz

MIME-Typ-Schutz aktiv (nosniff) — Browser interpretieren Dateien nicht falsch.

100 Clickjacking-Schutz

Clickjacking-Schutz aktiv über CSP frame-ancestors.

0 Berechtigungen (Kamera, Mikrofon etc.)

Keine Permissions-Policy gesetzt. Drittanbieter-Skripte könnten auf Kamera, Mikrofon oder Standort zugreifen.

☛ Handlungsbedarf: Setzen Sie eine Permissions-Policy, um den Zugriff auf Kamera, Mikrofon und Standort zu kontrollieren. DSGVO-relevant: Ohne diese Einstellung könnten Drittanbieter-Skripte unbemerkt auf sensible Geräte-Funktionen zugreifen. Beispiel: Permissions-Policy: camera=(), microphone=(), geolocation=()
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

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.

Apache-Server (klassisches Hosting bei den meisten Anbietern)

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.

WordPress Spezial für WordPress: so tragen Sie es ein

Weg 1: per .htaccess (empfohlen — kein Theme bearbeiten)

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.

Weg 2: per functions.php im Child-Theme (Alternative für Fortgeschrittene)

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.

↓ KOMPLETT-LÖSUNG ANZEIGEN Alle fehlenden Security-Header zusammen am Ende des Reports — fertig zum Kopieren.
45 Cookies

5 Erstanbieter- und 20 Drittanbieter-Cookie(s).

20 Drittanbieter-Cookie(s) erkannt. Diese können genutzt werden, um Sie über verschiedene Websites hinweg zu verfolgen.

☛ Handlungsbedarf: DSGVO-VERSTOSS: Drittanbieter-Cookies tracken Besucher über mehrere Websites hinweg. Das erfordert eine ausdrückliche Einwilligung (Opt-in) BEVOR die Cookies gesetzt werden. Lösung: (1) Prüfen Sie, welche externen Dienste die Cookies setzen. (2) Entfernen Sie nicht benötigte Dienste. (3) Für notwendige Dienste: Implementieren Sie einen Cookie-Consent-Banner, der diese Cookies erst nach Zustimmung lädt.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

Drittanbieter-Cookies (z.B. von Google, Facebook) verfolgen Besucher über Websites hinweg. Nach § 25 TDDDG und Art. 6 DSGVO ist VOR dem Setzen eine ausdrückliche Einwilligung Pflicht. Lösung in drei Schritten: (1) prüfen, welche externen Dienste die Cookies setzen, (2) nicht zwingend nötige Dienste entfernen, (3) für unverzichtbare Dienste ein Consent-Banner einbauen, das die Cookies erst nach „Zustimmen" lädt.

WordPress Spezial für WordPress: so tragen Sie es ein

WordPress-Plugin: Cookie-Consent-Plugins für WordPress: „Complianz" (kostenlos, sehr gründlich), „Borlabs Cookie" (kostenpflichtig, deutsch, sehr gut für Profis), „Real Cookie Banner" (DSGVO-fokussiert). Wichtig bei der Konfiguration: alle Tracking-Dienste auf „Vor Einwilligung NICHT laden" stellen — die meisten Plugins erkennen Standard-Dienste (GA, Maps, YouTube) automatisch.

✓ So prüfen Sie, ob es funktioniert: Browser im Inkognito-Modus öffnen, F12 → Tab „Application" → „Cookies" → ihre-domain.de. VOR dem Klick auf „Zustimmen" dürfen dort KEINE Cookies von google.com, facebook.com etc. stehen. NACH Zustimmung dann ja.

22 von 25 Cookie(s) ohne HttpOnly-Flag — könnten von Schadcode ausgelesen werden.

☛ Handlungsbedarf: Setzen Sie das HttpOnly-Flag für alle Cookies, die nicht von JavaScript benötigt werden. Das schützt vor dem Diebstahl von Sitzungsdaten durch Schadcode.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

Cookies ohne „HttpOnly"-Flag können von JavaScript ausgelesen werden — ein XSS-Angreifer kann damit Session-Cookies stehlen und sich als der eingeloggte Nutzer ausgeben. Setzen Sie HttpOnly für alle Cookies, die JavaScript nicht aktiv selbst braucht.

Apache-Server (klassisches Hosting bei den meisten Anbietern)

Datei: .htaccess im Web-Root

<IfModule mod_headers.c>
    Header always edit Set-Cookie "^(.*)$" "$1; HttpOnly" "expr=!(resp('Set-Cookie') -strmatch '*HttpOnly*')"
</IfModule>

⚠ Sauberer wäre, Cookies direkt mit HttpOnly zu setzen (PHP: setcookie(..., [..., 'httponly'=>true])). Ausnahme: Cookies, die JS aktiv lesen muss (z.B. manche Consent-Cookies).

WordPress Spezial für WordPress: so tragen Sie es ein

Weg 2: per functions.php im Child-Theme (Alternative für Fortgeschrittene)

Datei: functions.php Ihres CHILD-Themes (oder besser wp-config.php)

@ini_set('session.cookie_httponly', '1');
@ini_set('session.cookie_secure', '1');

⚠ WordPress-Login-Cookies sind seit Version 2.x bereits HttpOnly. Wenn Sie ein Plugin nutzen, das Session-Cookies setzt (z.B. WooCommerce-Cart vor Login), prüfen Sie dort die Einstellungen.

✓ So prüfen Sie, ob es funktioniert: F12 → Application → Cookies → Spalte „HttpOnly" zeigt überall Häkchen (außer bei bewusst JS-lesbaren Cookies wie z.B. dem Consent-Cookie).

25 von 25 Cookie(s) ohne SameSite-Schutz — werden bei Anfragen von anderen Websites mitgesendet.

☛ Handlungsbedarf: Setzen Sie das SameSite-Attribut (Lax oder Strict) für alle Cookies. Das verhindert, dass Cookies bei Anfragen von fremden Websites mitgesendet werden (CSRF-Schutz).
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

Ohne „SameSite"-Attribut werden Cookies bei Anfragen von fremden Websites an Sie mitgesendet — Grundlage für CSRF-Angriffe (eine fremde Seite kann im Hintergrund Aktionen in Ihrem Namen auslösen, weil das Login-Cookie mitgeschickt wird). Setzen Sie SameSite=Lax als Minimum.

Apache-Server (klassisches Hosting bei den meisten Anbietern)

Datei: .htaccess im Web-Root

<IfModule mod_headers.c>
    Header always edit Set-Cookie "^(.*)$" "$1; SameSite=Lax" "expr=!(resp('Set-Cookie') -strmatch '*SameSite*')"
</IfModule>

⚠ SameSite=Lax ist ein guter Standard. Strict ist sicherer, bricht aber externe Verlinkungen (User klickt von Google auf Ihre Seite — Cookies werden NICHT gesendet, Login ist weg). None erlaubt Cross-Site, braucht zwingend „; Secure".

WordPress Spezial für WordPress: so tragen Sie es ein

Weg 2: per functions.php im Child-Theme (Alternative für Fortgeschrittene)

Datei: wp-config.php (oberhalb von „/* That’s all, stop editing! */")

@ini_set('session.cookie_samesite', 'Lax');
@ini_set('session.cookie_secure', '1');
@ini_set('session.cookie_httponly', '1');

⚠ Setzt SameSite/Secure/HttpOnly für PHP-Session-Cookies. WordPress-Login-Cookies sind seit WP 6.2 standardmäßig SameSite=Lax. Bei älteren Versionen unbedingt updaten.

✓ So prüfen Sie, ob es funktioniert: F12 → Application → Cookies → Spalte „SameSite" — sollte überall „Lax" oder „Strict" stehen, nicht leer.

Erstanbieter

Name Domain Verschlüsselt Nur Server SameSite
_ym_uid .kwork.ru Ja Nein None
_ym_d .kwork.ru Ja Nein None
_ym_isad .kwork.ru Ja Nein None
referrer_url kwork.ru Ja Ja None
_ym_visorc .kwork.ru Ja Nein None

Drittanbieter

Name Domain Verschlüsselt Nur Server SameSite
bh .webvisor.org Ja Nein None
sync_cookie_csrf .mc.webvisor.org Ja Nein None
sync_cookie_csrf .mc.yandex.com Ja Nein None
bh .yandex.ru Ja Nein None
sync_cookie_csrf .mc.yandex.ru Ja Nein None
yabs-sid mc.yandex.com Ja Nein None
i .yandex.com Ja Ja None
yandexuid .yandex.com Ja Nein None
yuidss .yandex.com Ja Nein None
ymex .yandex.com Ja Nein None
receive-cookie-deprecation .yandex.com Ja Ja None
bh .yandex.com Ja Nein None
sync_cookie_csrf_secondary .mc.yandex.com Ja Nein None
sync_cookie_csrf_secondary .mc.webvisor.org Ja Nein None
sync_cookie_csrf_secondary .mc.yandex.ru Ja Nein None
_yasc .yandex.ru Ja Nein None
sync_cookie_ok_secondary .mc.yandex.com Ja Nein None
yandexuid .yandex.ru Ja Nein None
yuidss .yandex.ru Ja Nein None
i .yandex.ru Ja Nein None
↓ KOMPLETT-LÖSUNG ANZEIGEN Alle fehlenden Security-Header zusammen am Ende des Reports — fertig zum Kopieren.
50 Lokaler Speicher (Web Storage)

7 localStorage- und 1 sessionStorage-Einträge gefunden.

Umfangreiche localStorage-Nutzung — könnte auf Tracking oder Fingerprinting hindeuten.

☛ Handlungsbedarf: Die umfangreiche Nutzung von localStorage kann auf Tracking oder Fingerprinting hindeuten. Prüfen Sie, welche Daten gespeichert werden und ob diese für die Funktion der Website notwendig sind. DSGVO-relevant: Auch localStorage-Daten können unter die Datenschutzrichtlinie für elektronische Kommunikation fallen.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

Umfangreiche Nutzung von localStorage kann auf Tracking oder Fingerprinting hindeuten (localStorage ist nicht vom Cookie-Consent erfasst, taugt aber zur Wiedererkennung). Prüfen Sie, ob die Daten wirklich nötig sind — und wenn ja: in die Datenschutzerklärung aufnehmen.

WordPress Spezial für WordPress: so tragen Sie es ein

WordPress-Plugin: localStorage-Belegungen kommen meist aus Themes oder Plugins (Cookie-Banner-Status, Warenkorb, A/B-Testing, Slider-Position). Vorgehen: F12 → Application → Local Storage → ihre-domain.de — Einträge ansehen, mutmaßlichen Verursacher (Plugin-Name im Schlüssel) identifizieren, in den Plugin-Einstellungen prüfen oder Plugin entfernen, wenn nicht notwendig.

✓ So prüfen Sie, ob es funktioniert: Inkognito-Browser → Seite einmal laden → F12 → Application → Local Storage — möglichst wenig Einträge, jedenfalls keine ohne Funktionsbezug.

localStorage

NameWert
_ym_synced {"com":29719289,"mc.webvisor.org":29719289}
_ym_uid "1783157369782664323"
header-theme-dark 0
_ym_retryReqs {}
_ym_wv2rf:32983614:0 1
_ym32983614:0_reqNum 1
_ym32983614_lsid 931669575566

sessionStorage

NameWert
__ym_tab_guid 39b1670e-3a6b-d761-3b9d-c4b14d7c7284
35 Drittanbieter-Anfragen

21 Anfrage(n) an 5 verschiedene Drittanbieter-Server.

5 Drittanbieter-Server außerhalb der EU/des EWR — potenziell problematisch für die DSGVO.

☛ Handlungsbedarf: DSGVO-VERSTOSS MÖGLICH: Daten Ihrer Besucher werden an Server außerhalb der EU/des EWR übertragen. Seit dem Schrems-II-Urteil ist das nur mit besonderen Schutzmaßnahmen zulässig. Lösungen: (1) Wechseln Sie zu EU-basierten Alternativen (z.B. Matomo statt Google Analytics, Bunny Fonts statt Google Fonts). (2) Falls nicht möglich: Stellen Sie sicher, dass Standardvertragsklauseln (SCC) und zusätzliche technische Maßnahmen vorhanden sind. (3) Holen Sie eine ausdrückliche Einwilligung der Besucher ein, BEVOR Daten übertragen werden.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

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 Spezial für WordPress: so tragen Sie es ein

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.

mc.yandex.com 7 Anfragen · Russian Federation (RU) · Nicht-EU
⚠ DSGVO-Problem: Dieser Server steht außerhalb der EU/des EWR. Die Übertragung personenbezogener Daten (z.B. IP-Adressen Ihrer Besucher) an diesen Server kann gegen Art. 44–49 DSGVO verstoßen. Ohne gültige Rechtsgrundlage (z.B. Einwilligung, Standardvertragsklauseln) ist diese Datenübermittlung unzulässig.

Aufgerufene URLs:

https://mc.yandex.com/sync_cookie_image_check?scid=d242a116-31c1-c224-4978-a0ce61c5567f&cid=32983614

https://mc.yandex.com/metrika/advert.gif?t=gdpr(14)ti(4)

https://mc.yandex.com/sync_cookie_image_decide?cid=32983614&scid=d242a116-31c1-c224-4978-a0ce61c5567f&token=11082.P6l56foEZev7uvT7_nXKrQ9hU0LVUgXk8I3DcvsZzof1mQgPCKWL-_IcpvkcI_R62PzYP0_o3b1owBDhKmHdEl

https://mc.yandex.com/watch/32983614?wmode=7&page-url=https%3A%2F%2Fkwork.ru%2F&charset=utf-8&uah=chm%0A%3F0&browser-info=pv%3A1%3Avf%3Apupr1nz2sms3kwcrit195g1k99ckb%3Afu%3A0%3Aen%3Autf-8%3Ala%3Aen-US

https://mc.yandex.com/watch/32983614/1?wmode=7&page-url=https%3A%2F%2Fkwork.ru%2F&charset=utf-8&uah=chm%0A%3F0&browser-info=pv%3A1%3Avf%3Apupr1nz2sms3kwcrit195g1k99ckb%3Afu%3A0%3Aen%3Autf-8%3Ala%3Aen-

https://mc.yandex.com/sync_cookie_image_check_secondary?scid=c88d11c3-fbde-6163-1da8-ade79bc94c44&cid=32983614

https://mc.yandex.com/sync_cookie_image_decide_secondary?cid=32983614&scid=c88d11c3-fbde-6163-1da8-ade79bc94c44&token=11082.XDtAl2uLEKPhq5qteAp1a71gxf5_2V55RXak3_ErLhus0arzReV_7Qo2ts5id_BtYTNWlmp4qFz6

mc.webvisor.org 5 Anfragen · Russian Federation (RU) · Nicht-EU
⚠ DSGVO-Problem: Dieser Server steht außerhalb der EU/des EWR. Die Übertragung personenbezogener Daten (z.B. IP-Adressen Ihrer Besucher) an diesen Server kann gegen Art. 44–49 DSGVO verstoßen. Ohne gültige Rechtsgrundlage (z.B. Einwilligung, Standardvertragsklauseln) ist diese Datenübermittlung unzulässig.

Aufgerufene URLs:

https://mc.webvisor.org/metrika/tag_ww.js

https://mc.webvisor.org/sync_cookie_image_check?scid=d242a116-31c1-c224-4978-a0ce61c5567f&cid=32983614

https://mc.webvisor.org/sync_cookie_image_decide?cid=32983614&scid=d242a116-31c1-c224-4978-a0ce61c5567f&token=11082.1VLpwTe_Ls4JflOnA5hcN_gUDD8j4OA2zu_7QUENyxAN5QvkT_OS-c3blea2lUO9bTGCPz2znfCEsupFHIWy

https://mc.webvisor.org/sync_cookie_image_check_secondary?scid=c88d11c3-fbde-6163-1da8-ade79bc94c44&cid=32983614

https://mc.webvisor.org/sync_cookie_image_decide_secondary?cid=32983614&scid=c88d11c3-fbde-6163-1da8-ade79bc94c44&token=11082.Un1YjGFQ6n-Knp1Sh2QkByRgAH5VL_LT5Wh6QMizYJmX9t7KRdLdOJt7k1f0fEQT_7CFqXkL0m

mc.yandex.ru 5 Anfragen · Russian Federation (RU) · Nicht-EU
⚠ DSGVO-Problem: Dieser Server steht außerhalb der EU/des EWR. Die Übertragung personenbezogener Daten (z.B. IP-Adressen Ihrer Besucher) an diesen Server kann gegen Art. 44–49 DSGVO verstoßen. Ohne gültige Rechtsgrundlage (z.B. Einwilligung, Standardvertragsklauseln) ist diese Datenübermittlung unzulässig.

Aufgerufene URLs:

https://mc.yandex.ru/sync_cookie_image_start?cid=32983614&redirect_domain=mc.webvisor.org&scid=d242a116-31c1-c224-4978-a0ce61c5567f&token=11082.g-WEFAAA8aQyGY73nBF0-dUhQYklbBZ3_TkwF78-klSGrYj99FAnKBk2

https://mc.yandex.ru/sync_cookie_image_start?cid=32983614&redirect_domain=mc.yandex.com&scid=d242a116-31c1-c224-4978-a0ce61c5567f&token=11082.KOuVy-Mo-C5_TioKScNDZaPM4pHpT3qcIPBTR0vfM4bpd3kA8Lenhmj9GN

https://mc.yandex.ru/sync_cookie_image_start_secondary?cid=32983614&redirect_domain=mc.webvisor.org&scid=c88d11c3-fbde-6163-1da8-ade79bc94c44&token=11082.1yLetjFGOPdT6RUJXdOGmiis7cEAS4oWQyLLTrKjY0hJAi

https://mc.yandex.ru/sync_cookie_image_start_secondary?cid=32983614&redirect_domain=mc.yandex.com&scid=c88d11c3-fbde-6163-1da8-ade79bc94c44&token=11082.ZpMULwqfr54c2XC5WT8kbLmO1l1VkB1IHpbCveEvN9JOhEr-

https://mc.yandex.ru/sync_cookie_image_finish_secondary?cid=32983614&redirect_domain=mc.yandex.com&scid=c88d11c3-fbde-6163-1da8-ade79bc94c44&token=11082.TIwFgphO7NniBR0rNu3PZ_mqMij2C9WuHDPTWqraFmSVstB

smartcaptcha.yandexcloud.net 3 Anfragen · Russian Federation (RU) · Nicht-EU
⚠ DSGVO-Problem: Dieser Server steht außerhalb der EU/des EWR. Die Übertragung personenbezogener Daten (z.B. IP-Adressen Ihrer Besucher) an diesen Server kann gegen Art. 44–49 DSGVO verstoßen. Ohne gültige Rechtsgrundlage (z.B. Einwilligung, Standardvertragsklauseln) ist diese Datenübermittlung unzulässig.

Aufgerufene URLs:

https://smartcaptcha.yandexcloud.net/captcha.js?render=onload

https://smartcaptcha.yandexcloud.net/vendors.ed4b113f68d9e68992da.chunk.js

https://smartcaptcha.yandexcloud.net/shield.99cae02f31149fbbaa53.chunk.js

counter.yadro.ru 1 Anfragen · Russian Federation (RU) · Nicht-EU
⚠ DSGVO-Problem: Dieser Server steht außerhalb der EU/des EWR. Die Übertragung personenbezogener Daten (z.B. IP-Adressen Ihrer Besucher) an diesen Server kann gegen Art. 44–49 DSGVO verstoßen. Ohne gültige Rechtsgrundlage (z.B. Einwilligung, Standardvertragsklauseln) ist diese Datenübermittlung unzulässig.

Aufgerufene URLs:

https://counter.yadro.ru/hit?r;s800*600*24;uhttps%3A//kwork.ru/;0.6982302538844278

60 Tracker-Erkennung

2 bekannte(r) Tracker erkannt! Diese verfolgen Besucher über verschiedene Websites.

☛ Handlungsbedarf: DSGVO-VERSTOSS: Tracker verfolgen Ihre Besucher über verschiedene Websites hinweg. Das erfordert eine ausdrückliche Einwilligung VOR dem Laden der Tracker. Lösungen: (1) Entfernen Sie alle nicht notwendigen Tracker. (2) Wechseln Sie zu datenschutzfreundlichen Alternativen (z.B. Matomo, Plausible, Fathom statt Google Analytics). (3) Für unverzichtbare Tracker: Implementieren Sie einen Consent-Banner, der Tracker erst NACH Zustimmung lädt.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

Tracker (Google Analytics, Facebook Pixel, …) erfassen Besucher und verfolgen sie über mehrere Websites. Nach § 25 TDDDG und Art. 6 Abs. 1 DSGVO erforderlich: ausdrückliche Einwilligung VOR dem Laden des Trackers. „Weiter scrollen = Zustimmung" ist NICHT zulässig.

WordPress Spezial für WordPress: so tragen Sie es ein

WordPress-Plugin: Consent-Plugins, die Tracker korrekt blockieren bis zur Einwilligung: „Complianz" (kostenlos, sehr gut), „Real Cookie Banner", „Borlabs Cookie" (kostenpflichtig, am gründlichsten). Prinzip nach Einrichtung: Tracker-Snippet (z.B. GA-Script) NICHT direkt im Theme einbauen, sondern dem Consent-Plugin übergeben, das schaltet sie erst nach „Zustimmen" frei. Datenschutzfreundliche Tracker-Alternativen: Matomo (Cookieless-Modus → braucht u.U. kein Consent), Plausible (EU, anonym, kein Consent nötig laut Anbieter — Rechtsberatung empfohlen).

✓ So prüfen Sie, ob es funktioniert: Inkognito-Browser, Seite laden — VOR „Zustimmen": F12 → Netzwerk → keine Anfragen an google-analytics.com, facebook.com/tr usw. NACH „Zustimmen" dann ja.

Yandex (FingerprintingInvasive): smartcaptcha.yandexcloud.net

Yandex (Advertising): mc.yandex.com, mc.yandex.ru

0 Externe Ressourcen-Integrität (SRI)

0 von 2 externen Ressource(n) nutzen Integritätsprüfung (SRI).

☛ Handlungsbedarf: Nicht alle externen Ressourcen haben eine Integritätsprüfung. Fügen Sie SRI-Hashes für die fehlenden Ressourcen hinzu.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

Nur ein Teil Ihrer externen Ressourcen (0 von 2) ist mit SRI gesichert. Ergänzen Sie integrity-Attribute auch bei den restlichen.

WordPress Spezial für WordPress: so tragen Sie es ein

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.

☛ Handlungsbedarf: Fügen Sie Subresource Integrity (SRI) für alle externen Skripte und Stylesheets hinzu. Damit erkennt der Browser, wenn eine externe Datei manipuliert wurde. Ihr Webentwickler kann die integrity-Attribute einfach generieren.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

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 Spezial für WordPress: so tragen Sie es ein

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.

65 DNS-Sicherheit

Keine CAA-Einträge. Jede Zertifizierungsstelle könnte ein Zertifikat für diese Domain ausstellen.

☛ Handlungsbedarf: Erstellen Sie CAA-DNS-Einträge, um festzulegen, welche Zertifizierungsstellen Zertifikate für Ihre Domain ausstellen dürfen. Das verhindert, dass unbefugte Zertifikate ausgestellt werden.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

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.

☞ Konkrete CAA-Werte für die zehn häufigsten Hoster (DACH-Raum)

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.

#HosterVerwendete CA(s)CAA-Wert(e) — Tag issue
1Hetzner Webhosting (Basic-Zertifikat, kostenlos im Paket)DigiCert (Programm „Encryption Everywhere")digicert.com
1Hetzner Webhosting (Let’s Encrypt, kostenlos)Let’s Encrypt (ISRG)letsencrypt.org
2All-InklLet’s Encrypt + Sectigo (Pro)letsencrypt.org
sectigo.com
3IONOS (1&1)DigiCert (GeoTrust) + Let’s Encryptdigicert.com
letsencrypt.org
4STRATOSectigo + Let’s Encryptsectigo.com
letsencrypt.org
5Cloudflare (Universal SSL)Google Trust Services + DigiCert + Let’s Encryptpki.goog
digicert.com
letsencrypt.org
6AWS (ACM / CloudFront)Amazon Trust Servicesamazon.com
amazontrust.com
awstrust.com
amazonaws.com
7MittwaldLet’s Encrypt + Sectigoletsencrypt.org
sectigo.com
8WebgoLet’s Encrypt + Sectigoletsencrypt.org
sectigo.com
9raidboxes (Managed WordPress)Let’s Encryptletsencrypt.org
10Host Europe / DomainFactorySectigo + Let’s Encryptsectigo.com
letsencrypt.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 Spezial für WordPress: so tragen Sie es ein

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).

☛ Handlungsbedarf: Aktivieren Sie IPv6-Unterstützung (AAAA-Einträge) für Ihre Domain. Immer mehr Nutzer verwenden IPv6.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

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 Spezial für WordPress: so tragen Sie es ein

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 a mx ip4:93.171.200.18 ip4:93.171.201.10 ip4:93.171.201.20 ip4:93.171.201.31 ip4:93.171.201.36 ip4:93.171.201.46 — schützt vor E-Mail-Spoofing.

DMARC-Eintrag vorhanden: v=DMARC1;p=reject;aspf=s;rua=mailto:dmarc@kwork.ru;sp=reject — E-Mail-Authentifizierung aktiv.

0 Sicherheitskontakt (security.txt)

Keine security.txt-Datei gefunden (RFC 9116). Sicherheitsforscher wissen nicht, wie sie Schwachstellen melden können.

☛ Handlungsbedarf: Erstellen Sie eine security.txt-Datei unter /.well-known/security.txt. Diese ermöglicht es Sicherheitsforschern, Schwachstellen verantwortungsvoll zu melden. Pflichtfelder: Contact (E-Mail oder URL) und Expires (Ablaufdatum).
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

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.

Apache-Server (klassisches Hosting bei den meisten Anbietern)

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.

WordPress Spezial für WordPress: so tragen Sie es ein

Weg 1: per .htaccess (empfohlen — kein Theme bearbeiten)

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).

100 Externe Reporting-Endpunkte

Keine externen Reporting-Endpunkte erkannt.

0 Cookie-Einwilligung (Consent)

Kein Cookie-Consent-Banner erkannt — obwohl Tracker oder Drittanbieter-Cookies vorhanden sind! Ohne vorherige Einwilligung ein DSGVO-Verstoß.

☛ Handlungsbedarf: DSGVO-VERSTOSS: Sie laden Tracker und/oder setzen Drittanbieter-Cookies, aber haben kein Einwilligungssystem. Implementieren Sie sofort ein Cookie-Consent-Banner (z.B. Cookiebot, Usercentrics, Borlabs Cookie). Wichtig: Tracker dürfen erst NACH Einwilligung geladen werden.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

DSGVO-/TDDDG-Verstoß: Ihre Seite lädt Tracker oder Drittanbieter-Cookies, aber zeigt KEIN Consent-Banner. Nach § 25 TDDDG (umgesetzt durch BGH-Urteil 2020 „Cookie II") ist die Einwilligung ZWINGEND und VORHER nötig. Ein einfacher Hinweis „Diese Seite nutzt Cookies — OK" reicht nicht (nicht freiwillig, nicht informiert, nicht granular).

WordPress Spezial für WordPress: so tragen Sie es ein

WordPress-Plugin: Empfehlung nach Erfahrung: „Complianz" (kostenlos, DSGVO-fokussiert, sehr gründliche Wizard-Konfiguration) ODER „Real Cookie Banner" (kostenlos, deutsch, kennt sehr viele Dienste automatisch) ODER „Borlabs Cookie" (kostenpflichtig, professionellster Funktionsumfang). WICHTIG bei der Einrichtung: 1) Wizard durchgehen und alle genutzten Dienste konfigurieren, 2) Modus „Skripte werden VOR Einwilligung NICHT geladen" aktivieren, 3) Banner muss enthalten: gleichwertigen „Ablehnen"-Button neben „Zustimmen", granular pro Kategorie (Statistik/Marketing), Link zur Datenschutzerklärung.

✓ So prüfen Sie, ob es funktioniert: Inkognito-Browser → Seite öffnen → Banner erscheint sofort (vor jeglicher Tracker-Aktivität). F12 → Netzwerk → VOR Klick auf „Zustimmen": keine Anfragen an google-analytics.com, facebook.com etc. → NACH Klick auf „Zustimmen": dann ja.

0 Datenschutzerklärung & Impressum

Keine Datenschutzerklärung gefunden! Pflicht nach Art. 13 DSGVO.

☛ Handlungsbedarf: Erstellen Sie eine Datenschutzerklärung und verlinken Sie diese gut sichtbar auf jeder Seite (z.B. im Footer). Pflichtinhalte nach Art. 13 DSGVO: Verantwortlicher, Kontaktdaten, Zweck und Rechtsgrundlage der Verarbeitung, Empfänger, Speicherdauer, Betroffenenrechte.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

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 Spezial für WordPress: so tragen Sie es ein

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).

☛ Handlungsbedarf: Erstellen Sie ein Impressum und verlinken Sie es gut sichtbar. Pflicht nach § 5 DDG für geschäftsmäßige Websites. Pflichtangaben: Name, Anschrift, E-Mail, ggf. Handelsregister und USt-IdNr.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

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 Spezial für WordPress: so tragen Sie es ein

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.

⚙ Ihre fertige Security-htaccess

Alle fehlenden Security-Header zu einem einzigen Block kombiniert. Diesen Block ans Ende Ihrer .htaccess hängen — fertig. 6 Header werden gesetzt.

⚠ Warum diese Empfehlung KEINEN 100%-Score gibt — und warum das mit WordPress so ist

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):

  • Plugin „WP Content Security Policy & Headers" — fügt automatisch Nonces zu inline-Scripts hinzu (mittlerer Aufwand, sauberste WP-Lösung).
  • Hash-basierte CSP — jedes inline-Script per SHA-256 in der CSP whitelisten (fragil, bricht bei Updates).
  • Inline-Scripts externalisieren — Theme/Plugins so umbauen, dass kein inline-JS mehr ausgegeben wird (großer Aufwand, oft unmöglich).

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.

⚠ Wichtig bei Hetzner-Konsoleh-Webhosting (Managed-Hosting / Shared-Hosting)

Bei Hetzner-Konsoleh-Webhosting (und vergleichbaren Shared-Hostern wie All-Inkl, IONOS, Strato, 1blu, …) wirft Apache einen HTTP 500 Internal Server Error, sobald Header always edit Set-Cookie … expr=… in der .htaccess steht. Der Apache-Error-Log nennt es so:

Can't parse envclause/expression: syntax error, unexpected T_OP_STR_EQ, expecting $end

Das ist keine WebForensik-Fehlfunktion und kein Tippfehler — der Shared-Hoster hat das mod_headers-expr=-Subset per AllowOverride-Limit gesperrt (aus Sicherheitsgründen, weil Header edit auch Cookies anderer Anwender manipulieren könnte).

☛ Für Hetzner-Konsoleh-Nutzer: nehmen Sie unten die Variante mit dem roten „Hetzner / Shared"-Badge. Sie besteht aus zwei Dateien (.htaccess + wp-config.php) statt einer, vermeidet aber den 500-Fehler garantiert. Die Cookie-Flags landen dort in der wp-config.php, nicht in der .htaccess.

Apache Standard-Apache (für alle Hoster, ohne WordPress)

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 Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), interest-cohort=(), browsing-topics=()"

    # Fehlende Cookie-Flags konditional ergänzen (nur wenn nicht schon gesetzt)
    Header always edit Set-Cookie "^(.*)$" "$1; HttpOnly" "expr=!(resp('Set-Cookie') -strmatch '*HttpOnly*')"
    Header always edit Set-Cookie "^(.*)$" "$1; SameSite=Lax" "expr=!(resp('Set-Cookie') -strmatch '*SameSite*')"
</IfModule>

Hetzner / Shared Hetzner-Konsoleh / Managed-Hosting (zwei Dateien)

Diese Variante verhindert den 500 Internal Server Error auf Hetzner-Konsoleh und vergleichbaren Shared-Hostern (All-Inkl, IONOS, Strato, 1blu …): die .htaccess enthält NUR die Header-Direktiven (kein „Header edit"), die Cookie-Flags wandern in die wp-config.php. Zwei Dateien zu editieren statt einer, dafür garantiert lauffähig.

1. Datei: .htaccess im WordPress-Root
# 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 Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), interest-cohort=(), browsing-topics=()"
</IfModule>
# END WebForensik Security
2. Datei: wp-config.php im WordPress-Root

OBERHALB der Zeile „/* That's all, stop editing! */" einfügen. Vorher Backup von wp-config.php anlegen!

// === WebForensik: Cookie-Hardening (Hetzner-Konsoleh-tauglich) ===
// Bitte OBERHALB der Zeile "/* That's all, stop editing! */" einfügen.
// Wirkt auf PHP-Session- und WordPress-Login-Cookies.
// Plugin-eigene Cookies (z.B. WooCommerce, Cookie-Banner) müssen in den
// Plugin-Einstellungen separat auf "Secure" gestellt werden.
@ini_set('session.cookie_httponly', '1');
@ini_set('session.cookie_samesite', 'Lax');

WordPress WordPress: .htaccess im WP-Root

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 Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), interest-cohort=(), browsing-topics=()"

    # Fehlende Cookie-Flags konditional ergänzen
    Header always edit Set-Cookie "^(.*)$" "$1; HttpOnly" "expr=!(resp('Set-Cookie') -strmatch '*HttpOnly*')"
    Header always edit Set-Cookie "^(.*)$" "$1; SameSite=Lax" "expr=!(resp('Set-Cookie') -strmatch '*SameSite*')"
</IfModule>
# END WebForensik Security

WordPress Alternative für WordPress: functions.php im Child-Theme

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("Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), interest-cohort=(), browsing-topics=()");
});

// Cookie-Flags für PHP-Session-Cookies — wirkt nur auf $_SESSION,
// NICHT auf von Plugins/Themes per setcookie() gesetzte Cookies.
// Für umfassende Cookie-Absicherung die .htaccess-Variante oben verwenden.
add_action('init', function () {
    if (headers_sent()) return;
    @ini_set('session.cookie_httponly', '1');
    @ini_set('session.cookie_samesite', 'Lax');
}, 1);
Trockenübung — wir laden Ihre Seite nochmal mit den vorgeschlagenen Headern und zeigen, welche Ressourcen geblockt würden. Dauert ca. 30 Sekunden.
HTTP Response Headers
HeaderWert
cache-control no-cache, private
connection keep-alive
content-encoding gzip
content-security-policy frame-ancestors 'self' https://webvisor.com https://awards.ratingruneta.ru
content-type text/html; charset=UTF-8
date Sat, 04 Jul 2026 09:29:27 GMT
keep-alive timeout=15
server QRATOR
strict-transport-security max-age=15552000
transfer-encoding chunked
vary Accept-Encoding, User-Agent
x-content-type-options nosniff

Neue Analyse · Vergleichen

Bewertung auf Ihrer Website einbetten

Zeigen Sie Ihren WebForensik-Score öffentlich. Das Badge ist ein leichtes SVG, lädt schnell und respektiert die Privatsphäre Ihrer Besucher (kein Tracking).

WebForensik Score Badge

HTML-Code zum Einbetten (dieser konkrete Scan)

<a href="https://webforensik.de/results.php?id=338" target="_blank" rel="noopener">
  <img src="https://webforensik.de/badge.php?id=338" alt="WebForensik Score" width="174" height="28">
</a>

Oder dynamisch — zeigt immer den jüngsten Scan dieser Domain

<a href="https://webforensik.de/?url=https://kwork.ru" target="_blank" rel="noopener">
  <img src="https://webforensik.de/badge.php?domain=kwork.ru" alt="WebForensik Score" width="174" height="28">
</a>