WebForensik

Eine Content Security Policy (CSP) ist wie eine Türsteher-Regel für den Browser: „Skripte und Stile dürfen nur aus diesen erlaubten Quellen geladen werden." Ohne CSP kann eingeschleuster Schadcode (XSS) ungehindert nachladen, was er will. Starten Sie mit einer einfachen, sicheren Grundregel.

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>

⚠ Diese Policy ist bewusst pragmatisch (erlaubt Inline-Styles, weil viele Themes/Plugins sie brauchen). Wenn nach dem Aktivieren etwas nicht funktioniert: F12 → Konsole zeigt „Refused to load…" — dann die jeweilige Domain hinter script-src bzw. img-src ergänzen.

# BEGIN WebForensik CSP
<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>
# END WebForensik CSP

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'");
});

✓ So prüfen Sie, ob es funktioniert: Seite öffnen, F12 → Konsole — keine roten „Refused to load…"-Meldungen. Tab „Netzwerk" → erste Anfrage → Response Header „content-security-policy" sichtbar.

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.

<IfModule mod_headers.c>
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

add_action('send_headers', function () {
    header('Referrer-Policy: strict-origin-when-cross-origin');
});

✓ So prüfen Sie, ob es funktioniert: F12 → Netzwerk → erste Anfrage → Response Headers — „referrer-policy: strict-origin-when-cross-origin" muss sichtbar sein.

Ohne den Header „X-Content-Type-Options: nosniff" rät der Browser den Dateityp aus dem Inhalt — was Angreifer ausnutzen können (z.B. eine als .jpg getarnte HTML-Datei wird als HTML ausgeführt). Der Fix ist eine einzige Zeile.

Apache-Server (klassisches Hosting bei den meisten Anbietern)

Datei: .htaccess im Web-Root

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
</IfModule>

⚠ Keinerlei Nebenwirkungen zu erwarten — gilt als sicherer Standard und ist seit Jahren best practice.

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
</IfModule>

add_action('send_headers', function () {
    header('X-Content-Type-Options: nosniff');
});

✓ So prüfen Sie, ob es funktioniert: F12 → Netzwerk → Response Header: „x-content-type-options: nosniff".

Ohne Clickjacking-Schutz kann Ihre Website unsichtbar in eine fremde, betrügerische Seite eingebettet werden („Geben Sie hier Ihr Passwort ein" — der Klick landet aber auf Ihrer eingeblendeten Login-Seite). Lösung: SAMEORIGIN setzen (Einbettung nur durch Ihre eigene Domain).

Apache-Server (klassisches Hosting bei den meisten Anbietern)

Datei: .htaccess im Web-Root

<IfModule mod_headers.c>
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Content-Security-Policy "frame-ancestors 'self'"
</IfModule>

⚠ Beide Header parallel setzen: X-Frame-Options für ältere Browser, frame-ancestors für moderne. Wenn Sie eine CSP haben, ergänzen Sie „frame-ancestors 'self'" dort — nicht doppelt setzen.

<IfModule mod_headers.c>
    Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>

add_action('send_headers', function () {
    header('X-Frame-Options: SAMEORIGIN');
});

✓ So prüfen Sie, ob es funktioniert: F12 → Netzwerk → Response Header: „x-frame-options: SAMEORIGIN".

Drittanbieter-Cookies (z.B. von Google, Facebook) verfolgen Besucher über Websites hinweg. Nach § 25 TDDDG und Art. 6 DSGVO ist VOR dem Setzen eine ausdrückliche Einwilligung Pflicht. Lösung in drei Schritten: (1) prüfen, welche externen Dienste die Cookies setzen, (2) nicht zwingend nötige Dienste entfernen, (3) für unverzichtbare Dienste ein Consent-Banner einbauen, das die Cookies erst nach „Zustimmen" lädt.

✓ So prüfen Sie, ob es funktioniert: Browser im Inkognito-Modus öffnen, F12 → Tab „Application" → „Cookies" → ihre-domain.de. VOR dem Klick auf „Zustimmen" dürfen dort KEINE Cookies von google.com, facebook.com etc. stehen. NACH Zustimmung dann ja.

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

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');
    }
});

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

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

@ini_set('session.cookie_httponly', '1');
@ini_set('session.cookie_secure', '1');

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

Ohne „SameSite"-Attribut werden Cookies bei Anfragen von fremden Websites an Sie mitgesendet — Grundlage für CSRF-Angriffe (eine fremde Seite kann im Hintergrund Aktionen in Ihrem Namen auslösen, weil das Login-Cookie mitgeschickt wird). Setzen Sie SameSite=Lax als Minimum.

Apache-Server (klassisches Hosting bei den meisten Anbietern)

Datei: .htaccess im Web-Root

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

⚠ SameSite=Lax ist ein guter Standard. Strict ist sicherer, bricht aber externe Verlinkungen (User klickt von Google auf Ihre Seite — Cookies werden NICHT gesendet, Login ist weg). None erlaubt Cross-Site, braucht zwingend „; Secure".

@ini_set('session.cookie_samesite', 'Lax');
@ini_set('session.cookie_secure', '1');
@ini_set('session.cookie_httponly', '1');

✓ So prüfen Sie, ob es funktioniert: F12 → Application → Cookies → Spalte „SameSite" — sollte überall „Lax" oder „Strict" stehen, nicht leer.

DSGVO-relevant: Daten Ihrer Besucher (mindestens IP-Adresse + User-Agent) werden an Server außerhalb der EU/des EWR übertragen. Seit dem Schrems-II-Urteil (2020) ist das nur mit Standardvertragsklauseln + zusätzlichen Schutzmaßnahmen UND vorheriger Einwilligung zulässig. Beste Lösung: durch EU-Alternativen ersetzen, wo möglich.

✓ So prüfen Sie, ob es funktioniert: Im Inkognito-Modus laden, F12 → Netzwerk → alle Anfragen auflisten → unter „Domain" auf Server außerhalb EU prüfen. Nach Umstellung sollte hier keine US-Domain mehr unaufgefordert geladen werden.

Tracker (Google Analytics, Facebook Pixel, …) erfassen Besucher und verfolgen sie über mehrere Websites. Nach § 25 TDDDG und Art. 6 Abs. 1 DSGVO erforderlich: ausdrückliche Einwilligung VOR dem Laden des Trackers. „Weiter scrollen = Zustimmung" ist NICHT zulässig.

✓ So prüfen Sie, ob es funktioniert: Inkognito-Browser, Seite laden — VOR „Zustimmen": F12 → Netzwerk → keine Anfragen an google-analytics.com, facebook.com/tr usw. NACH „Zustimmen" dann ja.

Nur ein Teil Ihrer externen Ressourcen (2 von 14) ist mit SRI gesichert. Ergänzen Sie integrity-Attribute auch bei den restlichen.

✓ So prüfen Sie, ob es funktioniert: F12 → Konsole bei Seitenladung: keine „Failed to find a valid digest"-Meldungen. Quelltext: alle externen <script>/<link> haben integrity-Attribut.

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.

Name   Typ   Flag   Tag      Wert
@      CAA   0      issue    "digicert.com"
@      CAA   0      issue    "letsencrypt.org"
@      CAA   0      iodef    "mailto:security@ihre-domain.de"

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

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.

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

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.

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

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.

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

✓ So prüfen Sie, ob es funktioniert: https://ihre-domain.de/.well-known/security.txt im Browser aufrufen — Inhalt muss sichtbar sein (kein 404).

Ihre Tracker werden geladen, bevor der Nutzer einwilligen kann („pre-consent loading"). Das ist ein häufiger Konfigurationsfehler bei Cookie-Plugins — Banner erscheint, aber zu spät: GA-Skript läuft schon. Verstößt gegen § 25 TDDDG.

✓ So prüfen Sie, ob es funktioniert: Inkognito → F12 → Netzwerk (alles löschen, dann Aufzeichnung starten) → Seite laden, NICHT auf Banner klicken, 10 Sekunden warten → es darf KEINE Anfrage an google-analytics.com, googletagmanager.com, facebook.com/tr, doubleclick.net etc. erscheinen.

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.

✓ So prüfen Sie, ob es funktioniert: Footer auf jeder Seite → Link „Impressum" sichtbar → öffnet die Impressums-Seite mit allen Pflichtangaben.