Deutsch | English Header-Test API Über WebForensik

WebForensik

Ergebnisse für https://www.bracht-hofmeister.de/

Analysezeitpunkt: 2026-09-19 17:41:17

75

Gesamtbewertung

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

DSGVO-Zusammenfassung

⚠ Diese Website hat Verbesserungsbedarf beim Datenschutz.

DSGVO-Probleme erkannt (1):

⚠ 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-12-19).

Starke Verschlüsselungsmethode (TLS_AES_256_GCM_SHA384, 256 Bit).

80 Erzwungene Verschlüsselung (HSTS)

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

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

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.
100 Cookies

Keine Cookies gesetzt — vorbildlich für den Datenschutz.

70 Lokaler Speicher (Web Storage)

3 localStorage- und 0 sessionStorage-Einträge gefunden.

localStorage

NameWert
i18nextLng de
readabler {}
luxId qxmtkr8lt5sgzm7qohr7m03tdor67lzww
100 Drittanbieter-Anfragen

Keine Drittanbieter-Anfragen erkannt — alle Inhalte kommen vom eigenen Server.

100 Tracker-Erkennung

Keine bekannten Tracker erkannt.

100 Externe Ressourcen-Integrität (SRI)

Keine externen Skripte oder Stylesheets geladen.

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

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.

Kein SPF-Eintrag. E-Mails können im Namen dieser Domain gefälscht werden.

☛ Handlungsbedarf: Erstellen Sie einen SPF-DNS-Eintrag (TXT), um festzulegen, welche Server E-Mails im Namen Ihrer Domain versenden dürfen. Beispiel: v=spf1 include:_spf.google.com ~all
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

SPF (Sender Policy Framework) legt im DNS fest, welche Server E-Mails im Namen Ihrer Domain versenden dürfen. Ohne SPF kann jeder Phisher E-Mails so aussehen lassen, als kämen sie von Ihnen — und Empfänger werden eher reinfallen.

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

WordPress-Plugin: DNS-Sache, nicht WordPress. Im DNS-Panel einen TXT-Eintrag anlegen. Beispiele: Wenn Sie KEINE E-Mails versenden: v=spf1 -all (alle Versender ablehnen). Wenn nur Ihr Hoster versendet (z.B. All-Inkl): v=spf1 a mx ~all. Wenn Google Workspace: v=spf1 include:_spf.google.com ~all. Wenn Microsoft 365: v=spf1 include:spf.protection.outlook.com -all.

✓ So prüfen Sie, ob es funktioniert: dig TXT ihre-domain.de | grep spf — oder online https://www.kitterman.com/spf/validate.html.

Kein DMARC-Eintrag. Die Domain ist anfällig für E-Mail-Phishing.

☛ Handlungsbedarf: Erstellen Sie einen DMARC-DNS-Eintrag unter _dmarc.ihredomain.de. DMARC schützt vor Phishing und E-Mail-Spoofing. Beispiel: v=DMARC1; p=quarantine; rua=mailto:dmarc@ihredomain.de
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

DMARC kombiniert SPF und DKIM zu einer expliziten Anweisung an empfangende Mail-Server: „Was tun, wenn E-Mails behaupten von uns zu kommen, aber SPF/DKIM scheitert?" Ohne DMARC entscheidet jeder Mail-Server selbst — meist großzügig. Mit DMARC=reject verhindern Sie wirksam Phishing in Ihrem Namen.

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

WordPress-Plugin: DNS-Sache. TXT-Eintrag bei Subdomain _dmarc.ihre-domain.de. Empfohlene Stufen: Beobachten erst: v=DMARC1; p=none; rua=mailto:dmarc-reports@ihre-domain.de — mehrere Wochen Berichte ansehen. Dann verschärfen: v=DMARC1; p=quarantine; rua=… — verdächtige Mails landen im Spam. Final: v=DMARC1; p=reject; rua=… — werden ganz abgewiesen.

✓ So prüfen Sie, ob es funktioniert: dig TXT _dmarc.ihre-domain.de — oder online https://dmarcian.com/dmarc-inspector/.

100 Sicherheitskontakt (security.txt)

security.txt gefunden: https://www.bracht-hofmeister.de/.well-known/security.txt

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

Ablaufdatum vorhanden (Pflichtfeld).

Bevorzugte Sprachen angegeben.

100 Externe Reporting-Endpunkte

Keine externen Reporting-Endpunkte erkannt.

70 Cookie-Einwilligung (Consent)

Cookie-Einwilligungssystem erkannt: Klaro, klaro.

Consent-System erkannt, aber Banner scheint nicht sichtbar zu sein.

☛ Handlungsbedarf: Das Consent-System scheint nicht sichtbar zu sein. Stellen Sie sicher, dass der Cookie-Banner beim ersten Besuch angezeigt wird und nicht durch CSS oder JavaScript verborgen ist.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

Ihr Consent-System ist eingebaut, aber das Banner scheint nicht sichtbar — möglicherweise von einem anderen Plugin oder eigenen CSS-Regeln verborgen. Das ist ein Risiko: ohne sichtbares Banner gilt keine Einwilligung.

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

WordPress-Plugin: Vorgehen: 1) Browser-Cache + Cookies löschen, Inkognito-Tab nutzen. 2) Im Consent-Plugin: prüfen, ob Anzeige-Bedingungen das Banner versehentlich ausblenden (z.B. „nur für EU-Besucher" — und Sie testen vom EU-Server gerade aus). 3) Browser-Konsole F12 → Tab „Konsole" auf rote Fehler von consent-Skripten prüfen. 4) Inspektor → DOM nach „cookie", „consent" durchsuchen — Element vorhanden, aber display:none? Z-Index zu niedrig? 5) Anderes Plugin (Cookie-Notice-Konkurrent) deinstallieren.

✓ So prüfen Sie, ob es funktioniert: Inkognito-Tab, Seite laden, 5 Sekunden warten — Banner sichtbar zentral/unten, blockiert Hauptinhalt nicht komplett, ist anklickbar.

100 Datenschutzerklärung & Impressum

Datenschutzerklärung verlinkt: „Datenschutz" (/datenschutz).

Impressum verlinkt: „Impressum" (/impressum).

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

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

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 Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), interest-cohort=(), browsing-topics=()"
</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("Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), interest-cohort=(), browsing-topics=()");
});
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
accept-ranges bytes
cache-control max-age=0, no-cache
content-encoding gzip
content-language de-DE
content-length 23842
content-security-policy frame-ancestors 'self' https://www.decor-union.de
content-type text/html; charset=utf-8
date Sat, 19 Sep 2026 15:41:13 GMT
server Apache
strict-transport-security max-age=31536000
vary Accept-Encoding
x-content-type-options nosniff
x-frame-options SAMEORIGIN
x-mod-pagespeed 1.14.36.1-0
x-sfc-tags pages_9219, pages_9244, pages_9254, pages_9253, pages_9252, pages_9251, pages_9250, pages_9249, pages_9248, pages_9275, pages_9247, pages_9246, pages_9245, pages_9262, pages_9266, pages_9265, pages_9264, pages_9276, pages_9277, pages_9263, pages_9278, pages_9255, pages_9261, pages_9260, pages_9259,
x-ua-compatible IE=edge

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