Analysezeitpunkt: 2026-10-03 11:14:44
Mitgescannte Unterseiten: https://tierschutz-arnstadt.ddns.net/ · https://tierschutz-arnstadt.ddns.net/datenschutz.html · https://tierschutz-arnstadt.ddns.net/impressum.html · https://tierschutz-arnstadt.ddns.net/verein/login.php
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-12-28).
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.
HSTS gilt auch für alle Subdomains (includeSubDomains).
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.
Permissions-Policy ist konfiguriert — Zugriff auf sensible Geräte-APIs wird kontrolliert.
5 von 6 sensiblen APIs eingeschränkt — sehr gut.
1 Erstanbieter- und 0 Drittanbieter-Cookie(s).
| Name | Domain | Verschlüsselt | Nur Server | SameSite |
|---|---|---|---|---|
| PHPSESSID | tierschutz-arnstadt.ddns.net | Ja | Ja | Lax |
Kein lokaler Speicher (Web Storage) genutzt — kein Tracking-Risiko.
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.
Keine IPv6-Unterstützung (kein AAAA-Eintrag).
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-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.
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-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.
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-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/.
security.txt gefunden: https://tierschutz-arnstadt.ddns.net/.well-known/security.txt
Kontaktfeld vorhanden (Pflichtfeld) — Sicherheitsforscher können Schwachstellen melden.
Ablaufdatum vorhanden (Pflichtfeld).
Bevorzugte Sprachen angegeben.
Keine externen Reporting-Endpunkte erkannt.
Kein Consent-Banner nötig — keine Tracker oder Drittanbieter-Cookies erkannt.
Datenschutzerklärung verlinkt: „Datenschutz" (datenschutz.html).
Impressum verlinkt: „Impressum" (impressum.html).
Datenschutzerklärung ist erreichbar (HTTP 200).
Alle fehlenden Security-Header zu einem einzigen Block kombiniert. Diesen Block ans Ende Ihrer .htaccess hängen — fertig. 1 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.
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"
</IfModule>
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"
</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 | Wert |
|---|---|
| accept-ranges | bytes |
| content-length | 39843 |
| content-security-policy | default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'self'; form-action 'self'; script-src 'self' 'unsafe-inline' https://challenges.cloudflare.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://www.tierschutzverein-arnstadt.de; font-src 'self' data:; connect-src |
| content-type | text/html |
| date | Sat, 03 Oct 2026 09:14:31 GMT |
| etag | "6ac0c6c0-9ba3" |
| last-modified | Sat, 03 Oct 2026 09:11:28 GMT |
| permissions-policy | camera=(), microphone=(), geolocation=(), payment=(), usb=() |
| referrer-policy | strict-origin-when-cross-origin |
| server | nginx |
| strict-transport-security | max-age=31536000; includeSubDomains |
| x-content-type-options | nosniff |
| x-frame-options | SAMEORIGIN |