Deutsch | English Header-Test API Über WebForensik

WebForensik

Ergebnisse für https://hi-reg.de/

Analysezeitpunkt: 2026-05-25 16:03:29

86

Gesamtbewertung

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

DSGVO-Zusammenfassung

✔ Diese Website erfüllt grundlegende Datenschutzanforderungen.

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

Starke Verschlüsselungsmethode (TLS_AES_256_GCM_SHA384, 256 Bit).

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

HSTS-Preload ist aktiviert — Browser kennen die Verschlüsselung schon vor dem ersten Besuch.

60 Content Security Policy (CSP)

Content Security Policy vorhanden (via HTTP-Header).

Inline-Skripte erlaubt (unsafe-inline). Schwächt den XSS-Schutz für inline-Code; die anderen CSP-Direktiven schützen weiter.⚠ Bei Einsatz von WORDPRESS unumgänglich durch Vorgaben von Wordpress selbst.

☛ Handlungsbedarf: Entfernen Sie 'unsafe-inline' aus Ihrer CSP und verwenden Sie stattdessen Nonces oder Hashes für Ihre Inline-Skripte. Ihr Webentwickler kann das umsetzen.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

Ihre CSP erlaubt „unsafe-inline" für Skripte — damit hebeln Sie den XSS-Schutz weitgehend aus. Lösung: Inline-Skripte mit einer „Nonce" oder einem Hash signieren, statt sie pauschal zu erlauben. Das ist technisch anspruchsvoller — eine Aufgabe für den Webentwickler.

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

WordPress-Plugin: WordPress-Themes haben oft Inline-Skripte, die durch wp_localize_script() oder Plugin-Output entstehen. Pragmatischer Zwischenschritt: „unsafe-inline" vorerst belassen, dafür Inline-Skripte schrittweise nach extern auslagern (eigene .js-Dateien). Profi-Lösung: Plugin „WP Content Security Policy & Headers" mit Nonce-Support.

✓ So prüfen Sie, ob es funktioniert: Wenn Nonce-basierte CSP aktiv: F12 → Konsole — keine Meldung „Refused to execute inline script because it violates …" mehr.

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

Gute Grundregel: Nur eigene Inhalte sind standardmäßig erlaubt (default-src: self).

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

Referrer-Policy: strict-origin-when-cross-origin (via HTTP-Header).

Sichere Einstellung „strict-origin-when-cross-origin" — kein Pfad-Leak, kein HTTP-Downgrade-Leak. Bestmöglich.

100 MIME-Typ-Schutz

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

100 Clickjacking-Schutz

Clickjacking-Schutz aktiv über CSP frame-ancestors.

100 Berechtigungen (Kamera, Mikrofon etc.)

Permissions-Policy ist konfiguriert — Zugriff auf sensible Geräte-APIs wird kontrolliert.

4 von 6 sensiblen APIs eingeschränkt — sehr gut.

85 Cookies

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

2 von 2 Cookie(s) ohne Secure-Flag — werden auch über unverschlüsselte Verbindungen gesendet.

☛ Handlungsbedarf: Setzen Sie das Secure-Flag für alle Cookies. Ohne dieses Flag werden Cookies auch über unverschlüsselte HTTP-Verbindungen gesendet und können abgefangen werden. Ihr Webentwickler kann das in der Cookie-Konfiguration ändern.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

Cookies ohne „Secure"-Flag werden auch über unverschlüsselte HTTP-Verbindungen gesendet — und können dort von jedem im selben WLAN abgefangen werden. Bei reinen HTTPS-Sites gibt es keinen Grund, das Flag wegzulassen.

Apache-Server (klassisches Hosting bei den meisten Anbietern)

Datei: .htaccess im Web-Root

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

⚠ Dieser Header hängt „; Secure" an Cookies an, die es noch nicht haben. Funktioniert ab Apache 2.4. Saubere Alternative: das setzende Skript korrigieren (PHP: session.cookie_secure=1 in php.ini, bzw. setcookie()-Parameter „secure" auf true).

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

add_filter('secure_logged_in_cookie', '__return_true');
add_action('init', function () {
    if (!headers_sent()) {
        @ini_set('session.cookie_secure', '1');
        @ini_set('session.cookie_httponly', '1');
        @ini_set('session.cookie_samesite', 'Lax');
    }
});

⚠ Setzt Secure-Flag für WordPress-Login-Cookies und PHP-Session-Cookies. Bei Plugins, die eigene Cookies setzen, muss man dort separat ansetzen (Plugin-Einstellungen prüfen).

WordPress-Plugin: Plugins, die Cookies setzen (Cache, Anti-Spam, A/B-Test), haben oft in den Einstellungen Schalter wie „Secure Cookies" oder „nur über HTTPS".

✓ So prüfen Sie, ob es funktioniert: F12 → Application → Cookies → ihre-domain.de. Spalte „Secure" sollte bei allen Cookies ein Häkchen zeigen.

2 von 2 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
_pk_id.1.50af hi-reg.de Nein Nein Lax
_pk_ses.1.50af hi-reg.de Nein Nein Lax
↓ KOMPLETT-LÖSUNG ANZEIGEN Alle fehlenden Security-Header zusammen am Ende des Reports — fertig zum Kopieren.
70 Lokaler Speicher (Web Storage)

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

localStorage

NameWert
readabler {}
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.

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.

3 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 redirect=hi-reg.de.spf.hornetdmarc.com — schützt vor E-Mail-Spoofing.

DMARC-Eintrag vorhanden: v=DMARC1; p=quarantine; pct=100; fo=0:s:d:1; rua=mailto:a.qwm448aq@reports.hornetdmarc.com — 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.

70 Cookie-Einwilligung (Consent)

Cookie-Einwilligungssystem erkannt: Borlabs Cookie, borlabs.

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.

80 Datenschutzerklärung & Impressum

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

Impressum verlinkt: „IMPRESSUM" (/impressum/).

Link zur Datenschutzerklärung ist fehlerhaft: HTTP/1.1 301 Moved Permanently.

☛ Handlungsbedarf: Der Link zur Datenschutzerklärung führt zu einem Fehler. Prüfen Sie die URL und stellen Sie sicher, dass die Seite erreichbar ist.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung

Der Link zur Datenschutzerklärung führt zu einem Fehler (HTTP HTTP/1.1 301 Moved Permanently). Das ist faktisch wie keine Datenschutzerklärung — gleicher rechtlicher Status wie fehlend.

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

WordPress-Plugin: Schritt 1: Footer-Menü prüfen (Design → Menüs → Footer-Menü → der „Datenschutz"-Eintrag verlinkt auf welche URL?). Schritt 2: Existiert die Zielseite noch? Unter Seiten → Alle Seiten suchen. Schritt 3: Falls Seite umbenannt: Link im Menü auf die neue Seite zeigen lassen. Schritt 4: Falls Seite gelöscht: neue erstellen (siehe vorheriger Eintrag). Schritt 5: bei Permalink-Problemen einmal Einstellungen → Permalinks → Speichern (ohne Änderung — neu schreiben der .htaccess).

✓ So prüfen Sie, ob es funktioniert: Datenschutz-Link im Footer → öffnet die Seite mit Status 200, Inhalt sichtbar.

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

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

    # Fehlende Cookie-Flags konditional ergänzen (nur wenn nicht schon gesetzt)
    Header always edit Set-Cookie "^(.*)$" "$1; Secure" "expr=!(resp('Set-Cookie') -strmatch '*Secure*')"
    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"
</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_secure',   '1');
@ini_set('session.cookie_httponly', '1');
if (!defined('FORCE_SSL_ADMIN')) define('FORCE_SSL_ADMIN', true);

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"

    # Fehlende Cookie-Flags konditional ergänzen
    Header always edit Set-Cookie "^(.*)$" "$1; Secure" "expr=!(resp('Set-Cookie') -strmatch '*Secure*')"
    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");
});

// 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_secure', '1');
    @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
access-control-allow-headers Content-Type, Authorization
access-control-allow-methods GET,POST
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
content-type text/html; charset=UTF-8
cross-origin-embedder-policy unsafe-none; report-to='default'
cross-origin-embedder-policy-report-only unsafe-none; report-to='default'
cross-origin-opener-policy unsafe-none
cross-origin-opener-policy-report-only unsafe-none; report-to='default'
cross-origin-resource-policy cross-origin
date Mon, 25 May 2026 14:02:48 GMT
link <https://hi-reg.de/wp-json/>; rel="https://api.w.org/", <https://hi-reg.de/wp-json/wp/v2/pages/14>; rel="alternate"; title="JSON"; type="application/json", <https://hi-reg.de/>; rel=shortlink
permissions-policy accelerometer=(), autoplay=(), camera=(), cross-origin-isolated=(), display-capture=(self), encrypted-media=(), fullscreen=*, geolocation=(self), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), payment=*, picture-in-picture=*, publickey-credentials-get=(), screen-wake-lock=()
referrer-policy strict-origin-when-cross-origin
server Apache
strict-transport-security max-age=63072000; includeSubDomains; preload
x-cache hit
x-content-security-policy default-src 'self'; img-src *; media-src * data:;
x-content-type-options nosniff
x-frame-options SAMEORIGIN
x-permitted-cross-domain-policies none
x-tec-api-origin https://hi-reg.de
x-tec-api-root https://hi-reg.de/wp-json/tribe/events/v1/
x-tec-api-version v1

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