Deutsch | English Header-Test API Über WebForensik

WebForensik

Ergebnisse für https://relined.eu/

Analysezeitpunkt: 2026-08-04 22:50:35

61

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

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

  • www.googletagmanager.com (United States)

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

Erkannte Tracker:

  • Volentio JSD (Content)

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

Anzeigen:
100 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-09).

Starke Verschlüsselungsmethode (TLS_AES_256_GCM_SHA384, 256 Bit).

90 Erzwungene Verschlüsselung (HSTS)

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

HSTS-Dauer: 63072000 Sekunden (mindestens 1 Jahr) — sehr gut.

HSTS gilt auch für alle Subdomains (includeSubDomains).

0 Content Security Policy (CSP)

Keine Content Security Policy (CSP) gefunden. Die Website hat keinen Schutz gegen eingeschleusten Schadcode.

☛ Handlungsbedarf: Richten Sie eine Content Security Policy ein. Diese schützt Ihre Besucher vor eingeschleustem Schadcode (Cross-Site-Scripting/XSS). Beginnen Sie mit einer einfachen Richtlinie: Content-Security-Policy: default-src 'self'. Ihr Webentwickler oder Hoster kann Ihnen dabei helfen.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

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.

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>

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

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

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

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.

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

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

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

0 Clickjacking-Schutz

Kein Clickjacking-Schutz. Die Website könnte in andere Seiten eingebettet werden, um Nutzer zu täuschen.

☛ Handlungsbedarf: Fügen Sie einen Clickjacking-Schutz hinzu. Ohne diesen Schutz könnte Ihre Website unsichtbar in eine betrügerische Seite eingebettet werden. Setzen Sie: X-Frame-Options: SAMEORIGIN oder besser eine CSP mit frame-ancestors.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

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

Apache-Server (klassisches Hosting bei den meisten Anbietern)

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.

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 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"

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

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

↓ KOMPLETT-LÖSUNG ANZEIGEN Alle fehlenden Security-Header zusammen am Ende des Reports — fertig zum Kopieren.
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.
95 Cookies

1 Erstanbieter- und 0 Drittanbieter-Cookie(s).

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

Erstanbieter

Name Domain Verschlüsselt Nur Server SameSite
pll_language .relined.eu Ja Nein Lax
↓ KOMPLETT-LÖSUNG ANZEIGEN Alle fehlenden Security-Header zusammen am Ende des Reports — fertig zum Kopieren.
100 Lokaler Speicher (Web Storage)

Kein lokaler Speicher (Web Storage) genutzt — kein Tracking-Risiko.

40 Drittanbieter-Anfragen

19 Anfrage(n) an 7 verschiedene Drittanbieter-Server.

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

6 Drittanbieter-Server innerhalb der EU/des EWR.

static.mailplus.nl 5 Anfragen · Netherlands (NL) · EU/EWR

Aufgerufene URLs:

https://static.mailplus.nl/jq/ui/jquery-ui-1.12.1.custom.min.css?ver=7.0.2

https://static.mailplus.nl/jq/jquery.validate.1.19.3.min.js?ver=1.0

https://static.mailplus.nl/jq/ui/jquery-ui-1.12.1.custom.min.js?ver=1.0

... und 2 weitere Anfrage(n)

cdn.jsdelivr.net 3 Anfragen · Canada (CA) · EU/EWR

Aufgerufene URLs:

https://cdn.jsdelivr.net/npm/cookieconsent@3/build/cookieconsent.min.css

https://cdn.jsdelivr.net/npm/slick-carousel@1.8.1/slick/slick.min.js?ver=1.8.1

... und 1 weitere Anfrage(n)

consentcdn.cookiebot.com 3 Anfragen · Germany (DE) · EU/EWR

Aufgerufene URLs:

https://consentcdn.cookiebot.com/consentconfig/4779e160-1f00-420b-8fa0-7045b8339dd3/settings.json

https://consentcdn.cookiebot.com/consentconfig/4779e160-1f00-420b-8fa0-7045b8339dd3/relined.eu/configuration.js

https://consentcdn.cookiebot.com/sdk/bc-v4.min.html

m19.mailplus.nl 3 Anfragen · Netherlands (NL) · EU/EWR

Aufgerufene URLs:

https://m19.mailplus.nl/genericservice/code/servlet/React?command=getFormJs&uid=111212&feid=hAEgMeWM4y2gVEtfy9ry&p=https&om=t&of=x&c=1&jq=3&ver=1.0

https://m19.mailplus.nl/genericservice/code/servlet/React?callback=jQuery331046428479722236515_1785876630728&command=getFormHtml&uid=111212&feid=hAEgMeWM4y2gVEtfy9ry&p=https&om=t&of=h&_=1785876630729

... und 1 weitere Anfrage(n)

consent.cookiebot.com 2 Anfragen · Germany (DE) · EU/EWR

Aufgerufene URLs:

https://consent.cookiebot.com/uc.js

https://consent.cookiebot.com/4779e160-1f00-420b-8fa0-7045b8339dd3/cc.js?renew=false&referer=relined.eu&dnt=false&init=false&culture=NL

cdnjs.cloudflare.com 2 Anfragen · Canada (CA) · EU/EWR

Aufgerufene URLs:

https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js?ver=7.0.2

... und 1 weitere Anfrage(n)

www.googletagmanager.com 1 Anfragen · United States (US) · 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://www.googletagmanager.com/gtm.js?id=GTM-WRPGS62

80 Tracker-Erkennung

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

Volentio JSD (Content): cdn.jsdelivr.net

0 Externe Ressourcen-Integrität (SRI)

0 von 11 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 11) 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.

100 DNS-Sicherheit

CAA-Einträge vorhanden: letsencrypt.org — nur bestimmte Zertifizierungsstellen dürfen Zertifikate ausstellen.

3 Nameserver vorhanden — gute Redundanz.

IPv6-Unterstützung vorhanden (AAAA-Einträge).

SPF-Eintrag vorhanden: v=spf1 include:spf.protection.outlook.com include:_spf.mailplus.nl ip4:82.94.168.233 ip4:217.67.237.163 ip4:217.67.241.2 — schützt vor E-Mail-Spoofing.

DMARC-Eintrag vorhanden: v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:it@relined.eu; ruf=mailto:it@relined.eu; rf=afrf; pct=100; ri=86400 — E-Mail-Authentifizierung aktiv.

100 Sicherheitskontakt (security.txt)

security.txt gefunden: https://relined.eu/.well-known/security.txt

Kontaktfeld vorhanden (Pflichtfeld) — Sicherheitsforscher können Schwachstellen melden.

Ablaufdatum vorhanden (Pflichtfeld).

Verschlüsselungsinformationen angegeben.

Bevorzugte Sprachen angegeben.

100 Externe Reporting-Endpunkte

Keine externen Reporting-Endpunkte erkannt.

85 Cookie-Einwilligung (Consent)

Cookie-Einwilligungssystem erkannt: Cookiebot, cookiebot.com.

Consent-Banner ist sichtbar für Besucher.

Tracker werden bereits beim Seitenaufruf geladen — möglicherweise VOR der Einwilligung.

☛ Handlungsbedarf: Tracker werden beim Seitenaufruf geladen, möglicherweise bevor der Besucher zugestimmt hat. Stellen Sie sicher, dass Ihr Consent-System Tracker erst NACH Einwilligung aktiviert (Opt-in, nicht Opt-out).
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

Ihre Tracker werden geladen, bevor der Nutzer einwilligen kann („pre-consent loading"). Das ist ein häufiger Konfigurationsfehler bei Cookie-Plugins — Banner erscheint, aber zu spät: GA-Skript läuft schon. Verstößt gegen § 25 TDDDG.

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

WordPress-Plugin: Ursache liegt fast immer im Theme oder einem Tracking-Plugin, das den Tracker-Code direkt einbettet (z.B. „Google Analytics for WordPress" mit Auto-Insert). Lösung: 1) Tracking-Code AUS dem Theme/Plugin entfernen. 2) In Consent-Plugin (Complianz/Real Cookie Banner): Tracker als „Service" anlegen, Skript-Snippet dort hinterlegen — das Plugin lädt es erst bei Einwilligung. 3) ALTERNATIV: Plugin „Pys — PixelYourSite" + Consent-Verknüpfung. KEIN „GA bevor Consent als anonymisiert laden" — ist DSGVO-rechtlich nicht abschließend geklärt und riskant.

✓ So prüfen Sie, ob es funktioniert: Inkognito → F12 → Netzwerk (alles löschen, dann Aufzeichnung starten) → Seite laden, NICHT auf Banner klicken, 10 Sekunden warten → es darf KEINE Anfrage an google-analytics.com, googletagmanager.com, facebook.com/tr, doubleclick.net etc. erscheinen.

70 Datenschutzerklärung & Impressum

Datenschutzerklärung verlinkt: „privacyverklaring" (/privacy-statement/).

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.

Datenschutzerklärung ist erreichbar (HTTP 200).

⚙ Ihre fertige Security-htaccess

Alle fehlenden Security-Header zu einem einzigen Block kombiniert. Diesen Block ans Ende Ihrer .htaccess hängen — fertig. 5 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 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-Frame-Options "SAMEORIGIN"
    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*')"
</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 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-Frame-Options "SAMEORIGIN"
    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');

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 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-Frame-Options "SAMEORIGIN"
    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*')"
</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("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-Frame-Options: SAMEORIGIN");
    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');
}, 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
content-encoding br
content-type text/html; charset=UTF-8
date Tue, 04 Aug 2026 20:50:29 GMT
link <https://relined.eu/wp-json/>; rel="https://api.w.org/", <https://relined.eu/wp-json/wp/v2/pages/10853>; rel="alternate"; title="JSON"; type="application/json", <https://relined.eu/>; rel=shortlink
server nginx
set-cookie pll_language=nl; expires=Wed, 04 Aug 2027 20:50:29 GMT; Max-Age=31536000; path=/; domain=relined.eu; secure; SameSite=Lax
strict-transport-security max-age=63072000; includeSubDomains
x-content-type-options nosniff
x-pingback https://relined.eu/xmlrpc.php
x-powered-by PHP/8.2.33 PleskLin

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=797" target="_blank" rel="noopener">
  <img src="https://webforensik.de/badge.php?id=797" 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://relined.eu" target="_blank" rel="noopener">
  <img src="https://webforensik.de/badge.php?domain=relined.eu" alt="WebForensik Score" width="174" height="28">
</a>