WebForensik

HSTS (HTTP Strict Transport Security) sagt dem Browser: „Diese Domain IMMER über HTTPS aufrufen — egal was passiert." Das verhindert, dass ein Angreifer im WLAN die erste, ungeschützte Verbindung abfängt. Voraussetzung: Ihre Website läuft schon stabil über HTTPS.

Apache-Server (klassisches Hosting bei den meisten Anbietern)

Datei: .htaccess im Web-Root

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

⚠ max-age=31536000 sind 1 Jahr (in Sekunden). includeSubDomains gilt für blog.ihre-domain.de, shop.ihre-domain.de usw. — nur einbauen, wenn ALLE Subdomains HTTPS können, sonst sind die unerreichbar.

# BEGIN WebForensik HSTS
<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>
# END WebForensik HSTS

add_action('send_headers', function () {
    header('Strict-Transport-Security: max-age=31536000; includeSubDomains');
});

✓ So prüfen Sie, ob es funktioniert: Browser-Konsole F12 → Tab „Netzwerk" → Seite neu laden → erste Anfrage anklicken → „Response Headers" — dort muss „strict-transport-security: max-age=31536000…" stehen.

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

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.

Apache-Server (klassisches Hosting bei den meisten Anbietern)

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.

<IfModule mod_headers.c>
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()"
</IfModule>

add_action('send_headers', function () {
    header('Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()');
});

✓ So prüfen Sie, ob es funktioniert: F12 → Netzwerk → Response Header: „permissions-policy" sichtbar.

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.

Nur ein Teil Ihrer externen Ressourcen (0 von 2) 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.

SRI (Subresource Integrity) ist eine Prüfsumme, die im HTML-Code angibt, wie eine extern geladene Datei aussehen MUSS. Manipuliert jemand die externe Datei (z.B. wenn ein CDN gehackt wird), lädt der Browser sie nicht aus. Sie ergänzen das Attribut „integrity" am script/link-Tag.

✓ So prüfen Sie, ob es funktioniert: F12 → Netzwerk → Anfragen mit Code 200 von CDN-Domains (cdn.jsdelivr.net, cdnjs.cloudflare.com etc.) → im HTML-Quelltext muss der Tag „integrity=\"sha384-…\" crossorigin=\"anonymous\"" enthalten.

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.

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.

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

DSGVO-/TDDDG-Verstoß: Ihre Seite lädt Tracker oder Drittanbieter-Cookies, aber zeigt KEIN Consent-Banner. Nach § 25 TDDDG (umgesetzt durch BGH-Urteil 2020 „Cookie II") ist die Einwilligung ZWINGEND und VORHER nötig. Ein einfacher Hinweis „Diese Seite nutzt Cookies — OK" reicht nicht (nicht freiwillig, nicht informiert, nicht granular).

✓ So prüfen Sie, ob es funktioniert: Inkognito-Browser → Seite öffnen → Banner erscheint sofort (vor jeglicher Tracker-Aktivität). F12 → Netzwerk → VOR Klick auf „Zustimmen": keine Anfragen an google-analytics.com, facebook.com etc. → NACH Klick auf „Zustimmen": dann ja.