WebForensik
Ergebnisse für https://itsua.com/
Analysezeitpunkt: 2026-10-09 09:36:59
Gesamtbewertung
Veränderung seit dem letzten Scan +9 verbessert
Vergleich mit Scan vom 09.10.2026 09:03 (Score 79 → 88) · Kompletten Verlauf ansehen
⚠ Weggefallene Schutzmaßnahmen: xfo_set, tp_none, sri_no_external
✓ Neue Schutzmaßnahmen: csp_found, csp_frame_ancestors, csp_default_self, xfo_csp, permpol_good, tp_eu, sri_summary, dns_caa_yes, sectxt_found, sectxt_contact_yes, sectxt_expires_yes, sectxt_languages
Score-Verlauf für diese Domain Kompletten Verlauf ansehen →
✔ 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-14).
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.
▸ 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).
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.
Keine Cookies gesetzt — vorbildlich für den Datenschutz.
Kein lokaler Speicher (Web Storage) genutzt — kein Tracking-Risiko.
1 Anfrage(n) an 1 verschiedene Drittanbieter-Server.
1 Drittanbieter-Server innerhalb der EU/des EWR.
Aufgerufene URLs:
https://static.cloudflareinsights.com/beacon.min.js/v4bc70e2c01a94c73b74392e4234840661791215815920
Keine bekannten Tracker erkannt.
1 von 1 externen Ressource(n) nutzen Integritätsprüfung (SRI).
CAA-Einträge vorhanden: ssl.com, comodoca.com, digicert.com; cansignhttpexchanges=yes, letsencrypt.org, pki.goog; cansignhttpexchanges=yes, ssl.com, mailto:privacy@itsua.com, comodoca.com, digicert.com; cansignhttpexchanges=yes, letsencrypt.org, pki.goog; cansignhttpexchanges=yes — nur bestimmte Zertifizierungsstellen dürfen Zertifikate ausstellen.
2 Nameserver vorhanden — gute Redundanz.
IPv6-Unterstützung vorhanden (AAAA-Einträge).
SPF-Eintrag vorhanden: v=spf1 include:_spf.google.com include:relay.mailchannels.net ~all — schützt vor E-Mail-Spoofing.
DMARC-Eintrag vorhanden: v=DMARC1; p=reject; pct=100; adkim=s; aspf=s — E-Mail-Authentifizierung aktiv.
security.txt gefunden: https://itsua.com/.well-known/security.txt
Kontaktfeld vorhanden (Pflichtfeld) — Sicherheitsforscher können Schwachstellen melden.
Ablaufdatum vorhanden (Pflichtfeld).
Bevorzugte Sprachen angegeben.
Network Error Logging (NEL) aktiv — Netzwerkfehler werden an einen externen Dienst gemeldet.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung
Network Error Logging (NEL) meldet Netzwerkfehler an einen externen Server. Wie bei externem Reporting: in Datenschutzerklärung erwähnen und prüfen, ob der Empfänger DSGVO-konform arbeitet.
Apache-Server (klassisches Hosting bei den meisten Anbietern)
Datei: .htaccess im Web-Root
<IfModule mod_headers.c>
Header always unset NEL
Header always unset Report-To
</IfModule>⚠ Wenn Sie NEL nicht aktiv brauchen: diese zwei Zeilen entfernen beide Reporting-Header. Wenn doch: in der Datenschutzerklärung dokumentieren.
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 unset NEL
Header always unset Report-To
</IfModule>⚠ Falls die Header von einem Plugin gesetzt werden, das Plugin selbst konfigurieren.
✓ So prüfen Sie, ob es funktioniert: F12 → Netzwerk → erste Anfrage → Response Header: KEINE Einträge „nel" und „report-to" mehr (oder bewusst dokumentiert).
Daten werden an externen Dienst gemeldet: Report-To: a.nel.cloudflare.com
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung
Ihre Website sendet Fehler- oder CSP-Berichte an einen externen Dienst (Report-To: a.nel.cloudflare.com). DSGVO-relevant: dabei werden mindestens IP-Adresse und URL übertragen. Prüfen Sie, ob (a) der Empfänger DSGVO-konform arbeitet, (b) die Übermittlung in Ihrer Datenschutzerklärung erwähnt ist, (c) ein Auftragsverarbeitungsvertrag (AVV) besteht.
WordPress Spezial für WordPress: so tragen Sie es ein
WordPress-Plugin: Wenn Sie den Reporting-Empfänger nicht selbst eingerichtet haben, kommt er meist aus einem Plugin (z.B. Sentry, Rollbar, Datadog). Im Plugin-Konfigurationsbereich prüfen — entweder deaktivieren, durch EU-Anbieter ersetzen oder konsent-pflichtig stellen.
✓ So prüfen Sie, ob es funktioniert: Datenschutzerklärung enthält Eintrag zu Fehler-Reporting + AVV liegt vor. Im Inkognito-Modus: F12 → Netzwerk → keine ungewollten Berichts-Anfragen.
Kein Consent-Banner nötig — keine Tracker oder Drittanbieter-Cookies erkannt.
Datenschutzerklärung verlinkt: „PRIVACY" (/privacy/).
Kein Impressum gefunden — Pflicht nach § 5 DDG (ehemals TMG).
▸ 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. 1 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"
</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"
</IfModule>
# END WebForensik SecurityWordPress 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 | Wert |
|---|---|
| alt-svc | h3=":443"; ma=86400 |
| cache-control | public, max-age=0, must-revalidate |
| cf-cache-status | HIT |
| cf-ray | a47bb7924d6a5038-CDG |
| content-encoding | zstd |
| content-security-policy | default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com https://www.googleadservices.com https://googleads.g.doubleclick.net https://www.google.com https://challenges.cloudflare.com https://app.cal.com https://static.cloudflareinsights.com; style-src 'self' 'unsafe-inl |
| content-type | text/html |
| date | Fri, 09 Oct 2026 07:36:55 GMT |
| link | </llms.txt>; rel="describedby"; type="text/plain", </sitemap-index.xml>; rel="sitemap" |
| nel | {"report_to":"cf-nel","success_fraction":0.0,"max_age":604800} |
| permissions-policy | camera=(), microphone=(), geolocation=(), payment=(), usb=() |
| priority | u=0,i |
| referrer-policy | strict-origin-when-cross-origin |
| report-to | {"group":"cf-nel","max_age":604800,"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v4?s=VffQ6D7sXOjOK11rIK9MPkzOnVX8QaU1xejEvFUeSwgjBfi92oWyXRJNpsGCuoBL9ysPfDfzFSDhTtE%2BKby3PgNZQuF5LIHldqAyRfb5VdoBmZwfWPws65FDi68l32rjF732K3wKQjI%3D"}]} |
| server | cloudflare |
| server-timing | cfCacheStatus;desc="HIT" cfEdge;dur=16,cfOrigin;dur=0,cfWorker;dur=22 cfExtPri |
| strict-transport-security | max-age=31536000 |
| x-content-type-options | nosniff |
| x-frame-options | SAMEORIGIN |
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).
HTML-Code zum Einbetten (dieser konkrete Scan)
<a href="https://webforensik.de/results.php?id=2724" target="_blank" rel="noopener">
<img src="https://webforensik.de/badge.php?id=2724" 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://itsua.com" target="_blank" rel="noopener">
<img src="https://webforensik.de/badge.php?domain=itsua.com" alt="WebForensik Score" width="174" height="28">
</a>