Analysezeitpunkt: 2026-08-31 06:49:44
Gesamtbewertung
✔ 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.
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-11-02).
Starke Verschlüsselungsmethode (TLS_AES_256_GCM_SHA384, 256 Bit).
HSTS ist aktiviert — der Browser wird angewiesen, immer die verschlüsselte Verbindung zu nutzen.
HSTS-Dauer: 31536000 Sekunden (mindestens 1 Jahr) — sehr gut.
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.
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-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).
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.
MIME-Typ-Schutz aktiv (nosniff) — Browser interpretieren Dateien nicht falsch.
Clickjacking-Schutz aktiv über CSP frame-ancestors.
Keine Permissions-Policy gesetzt. Drittanbieter-Skripte könnten auf Kamera, Mikrofon oder Standort zugreifen.
Die Permissions-Policy kontrolliert, ob Skripte (auch von Drittanbietern) auf Kamera, Mikrofon, Standort, Bewegungssensoren etc. zugreifen dürfen. DSGVO-relevant, weil sensible Geräte-APIs sonst unbemerkt angesprochen werden können.
Datei: .htaccess im Web-Root
<IfModule mod_headers.c>
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), interest-cohort=()"
</IfModule>⚠ „()" am Ende heißt: kein Aufrufer (auch nicht Ihre eigene Seite) darf diese API nutzen. Falls Sie z.B. eine Karten-Funktion mit Geolokalisierung haben: geolocation=(self) statt geolocation=(). „interest-cohort=()" deaktiviert Googles FLoC-Tracking.
Datei: .htaccess im WordPress-Root
<IfModule mod_headers.c>
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()"
</IfModule>⚠ Standard-WordPress braucht keine dieser APIs. Wenn Sie ein Plugin nutzen, das z.B. die Kamera braucht (QR-Scanner, Video-Upload): die entsprechende API auf „(self)" setzen.
Datei: functions.php Ihres CHILD-Themes
add_action('send_headers', function () {
header('Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()');
});⚠ Backup vor jeder Änderung an functions.php.
✓ So prüfen Sie, ob es funktioniert: F12 → Netzwerk → Response Header: „permissions-policy" sichtbar.
2 Erstanbieter- und 0 Drittanbieter-Cookie(s).
2 von 2 Cookie(s) ohne Secure-Flag — werden auch über unverschlüsselte Verbindungen gesendet.
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.
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).
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.
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.
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).
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).
| 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 |
1 localStorage- und 0 sessionStorage-Einträge gefunden.
| Name | Wert |
|---|---|
| readabler | {} |
Keine Drittanbieter-Anfragen erkannt — alle Inhalte kommen vom eigenen Server.
Keine bekannten Tracker erkannt.
Keine externen Skripte oder Stylesheets geladen.
Keine CAA-Einträge. Jede Zertifizierungsstelle könnte ein Zertifikat für diese Domain ausstellen.
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.
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.
| # | Hoster | Verwendete CA(s) | CAA-Wert(e) — Tag issue |
|---|---|---|---|
| 1 | Hetzner Webhosting (Basic-Zertifikat, kostenlos im Paket) | DigiCert (Programm „Encryption Everywhere") | digicert.com |
| 1 | Hetzner Webhosting (Let’s Encrypt, kostenlos) | Let’s Encrypt (ISRG) | letsencrypt.org |
| 2 | All-Inkl | Let’s Encrypt + Sectigo (Pro) | letsencrypt.orgsectigo.com |
| 3 | IONOS (1&1) | DigiCert (GeoTrust) + Let’s Encrypt | digicert.comletsencrypt.org |
| 4 | STRATO | Sectigo + Let’s Encrypt | sectigo.comletsencrypt.org |
| 5 | Cloudflare (Universal SSL) | Google Trust Services + DigiCert + Let’s Encrypt | pki.googdigicert.comletsencrypt.org |
| 6 | AWS (ACM / CloudFront) | Amazon Trust Services | amazon.comamazontrust.comawstrust.comamazonaws.com |
| 7 | Mittwald | Let’s Encrypt + Sectigo | letsencrypt.orgsectigo.com |
| 8 | Webgo | Let’s Encrypt + Sectigo | letsencrypt.orgsectigo.com |
| 9 | raidboxes (Managed WordPress) | Let’s Encrypt | letsencrypt.org |
| 10 | Host Europe / DomainFactory | Sectigo + Let’s Encrypt | sectigo.comletsencrypt.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-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.
IPv6-Unterstützung vorhanden (AAAA-Einträge).
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.
security.txt gefunden: https://hi-reg.de/.well-known/security.txt
Kontaktfeld vorhanden (Pflichtfeld) — Sicherheitsforscher können Schwachstellen melden.
Ablaufdatum vorhanden (Pflichtfeld).
Keine externen Reporting-Endpunkte erkannt.
Cookie-Einwilligungssystem erkannt: Borlabs Cookie, borlabs.
Consent-System erkannt, aber Banner scheint nicht sichtbar zu sein.
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-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.
Datenschutzerklärung verlinkt: „DATENSCHUTZ" (/datenschutz/).
Impressum verlinkt: „IMPRESSUM" (/impressum/).
Link zur Datenschutzerklärung ist fehlerhaft: HTTP/1.1 301 Moved Permanently.
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-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.
Alle fehlenden Security-Header zu einem einzigen Block kombiniert. Diesen Block ans Ende Ihrer .htaccess hängen — fertig. 4 Header werden gesetzt.
Die Content-Security-Policy oben enthält bewusst 'unsafe-inline' sowohl für style-src als auch für script-src. Damit ist KEIN vollständiger XSS-Schutz möglich — das ist eine pragmatische Entscheidung, kein Bug.
Warum? Ein typisches WordPress-Setup (Theme + 5-15 Plugins) schreibt 10-50 verschiedene Inline-<script>-Blocks ins HTML: jQuery-Init, Slider-Initialisierung, Cookie-Banner, Tracking, GTM, Web Vitals, Lazy-Load, Speculation Rules usw. Wenn die strikte CSP script-src 'self' diese alle blockt, ist die Site optisch und funktional kaputt (Slider weiß, Cookie-Banner zerschossen, Plugins tot). Genau dieses Problem hatten Sie soeben mit Ihrer Slider-Seite.
Konsequenz fürs Scoring: Sites, die WordPress mit Plugins einsetzen, können in dieser App maximal ~75-85 Punkte in der CSP-Kategorie erreichen — das volle 100%-Rating ist erst möglich, wenn der inline-Code per Nonce oder Hash signiert wird (technisch anspruchsvoll, bricht bei jedem Theme/Plugin-Update).
Wege zum vollen XSS-Schutz (in steigender Komplexität):
Wer keinen dieser Wege geht, lebt mit 'unsafe-inline' — wie ca. 95% aller produktiven WordPress-Sites im Web. Die anderen CSP-Direktiven schützen weiterhin: default-src 'self' blockt externe Ressourcen, object-src 'none' verbietet Flash/Java, frame-ancestors 'self' verhindert Clickjacking, base-uri 'self' verhindert Base-Tag-Hijacking. Es ist kein Maximalschutz, aber realistischer Schutz für die WP-Praxis.
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.
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 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; Secure" "expr=!(resp('Set-Cookie') -strmatch '*Secure*')"
Header always edit Set-Cookie "^(.*)$" "$1; HttpOnly" "expr=!(resp('Set-Cookie') -strmatch '*HttpOnly*')"
</IfModule>
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.
# 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 Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), interest-cohort=(), browsing-topics=()"
</IfModule>
# END WebForensik Security
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);
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 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; Secure" "expr=!(resp('Set-Cookie') -strmatch '*Secure*')"
Header always edit Set-Cookie "^(.*)$" "$1; HttpOnly" "expr=!(resp('Set-Cookie') -strmatch '*HttpOnly*')"
</IfModule>
# END WebForensik Security
Falls Ihr Hoster .htaccess-Änderungen nicht erlaubt: dieses PHP-Snippet ans Ende der functions.php Ihres CHILD-Themes hängen. Vorher Backup machen — NIE das Haupt-Theme bearbeiten, das wird bei Updates überschrieben.
add_action('send_headers', function () {
header("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("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_secure', '1');
@ini_set('session.cookie_httponly', '1');
}, 1);
| Header | Wert |
|---|---|
| content-security-policy | default-src 'self'; img-src 'self' data: blob: https:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; font-src 'self' data:; object-src 'none'; frame-ancestors 'self'; base-uri 'self'; upgrade-insecure-requests |
| content-type | text/html; charset=UTF-8 |
| date | Mon, 31 Aug 2026 04:49:38 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 |
| referrer-policy | strict-origin-when-cross-origin |
| server | Apache |
| strict-transport-security | max-age=31536000 |
| x-content-type-options | nosniff |
| x-frame-options | SAMEORIGIN |
| 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 |