WebForensik

HSTS (HTTP Strict Transport Security) tells the browser: "Always use HTTPS for this domain — no matter what." This prevents attackers on the same WLAN from intercepting the first, unprotected request. Prerequisite: your site is already stable on HTTPS.

Apache server (classic hosting at most providers)

File: .htaccess in the web root

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

⚠ max-age=31536000 equals 1 year (in seconds). includeSubDomains also covers blog.your-domain.com, shop.your-domain.com etc. — only enable if ALL subdomains support HTTPS, otherwise they become unreachable.

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

✓ How to verify it works: DevTools (F12) → Network tab → reload page → click the first request → "Response Headers" — must contain "strict-transport-security: max-age=31536000…".

Your CSP allows "unsafe-inline" for scripts — this largely defeats XSS protection. Solution: sign inline scripts with a nonce or hash instead of allowing them wholesale. This is technically demanding — a job for your web developer.

✓ How to verify it works: Once nonce-based CSP is active: F12 → Console — no more "Refused to execute inline script…" messages.

Without a Referrer-Policy the browser sends the full URL of your current page (incl. search terms, usernames in URL params) on every click to the destination site. Privacy-relevant per Art. 5 GDPR. Recommended safe setting: strict-origin-when-cross-origin.

Apache server (classic hosting at most providers)

File: .htaccess in the web root

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

⚠ "strict-origin-when-cross-origin" is the modern standard: on cross-domain clicks only your origin (no path/params) is sent — internal clicks include the full URL. Stricter is "no-referrer" (send nothing) but it breaks some analytics 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');
});

✓ How to verify it works: F12 → Network → first request → Response Headers — "referrer-policy: strict-origin-when-cross-origin" must be present.

Without the "X-Content-Type-Options: nosniff" header the browser guesses file types from content — which attackers can exploit (e.g. a HTML file disguised as .jpg is executed as HTML). The fix is one single line.

Apache server (classic hosting at most providers)

File: .htaccess in the web root

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

⚠ No side effects expected — considered a safe standard and best practice for years.

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

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

✓ How to verify it works: F12 → Network → Response Header: "x-content-type-options: nosniff".

Permissions-Policy controls whether scripts (including third-party) may access camera, microphone, location, motion sensors etc. GDPR-relevant because sensitive device APIs can otherwise be reached unnoticed.

Apache server (classic hosting at most providers)

File: .htaccess in the web root

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

⚠ "()" at the end means: no caller (not even your own page) may use this API. If you need geolocation (e.g. a map feature): use geolocation=(self) instead of geolocation=(). "interest-cohort=()" disables Google’s 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=()');
});

✓ How to verify it works: F12 → Network → Response Header: "permissions-policy" visible.

Cookies without the "Secure" flag are also sent over unencrypted HTTP — and can be intercepted by anyone on the same WLAN. There’s no reason to omit Secure on HTTPS-only sites.

Apache server (classic hosting at most providers)

File: .htaccess in the web root

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

⚠ This header appends "; Secure" to cookies that don’t have it yet. Requires Apache 2.4+. The cleaner fix is to correct the code that sets the cookie (PHP: session.cookie_secure=1 in php.ini, or setcookie() with "secure" => 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');
    }
});

✓ How to verify it works: F12 → Application → Cookies → your-domain.com. The "Secure" column should show a checkmark for every cookie.

Cookies without the "HttpOnly" flag can be read by JavaScript — an XSS attacker can steal session cookies and impersonate the logged-in user. Set HttpOnly for all cookies JavaScript doesn’t actively need.

Apache server (classic hosting at most providers)

File: .htaccess in the web root

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

⚠ Cleaner: set cookies with HttpOnly directly (PHP: setcookie(..., [..., 'httponly'=>true])). Exception: cookies that JS actively reads (e.g. some consent cookies).

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

✓ How to verify it works: F12 → Application → Cookies → "HttpOnly" column shows checkmarks everywhere (except for deliberately JS-readable cookies like the consent cookie).

CAA records (Certification Authority Authorization) define in DNS which Certificate Authorities are allowed to issue certificates for your domain. Without a CAA record an attacker could request a fraudulent certificate for your domain at any CA. CAA is pure DNS configuration — set in your registrar/DNS-panel, NOT in WordPress.

Name   Type   Flag   Tag      Value
@      CAA    0      issue    "digicert.com"
@      CAA    0      issue    "letsencrypt.org"
@      CAA    0      iodef    "mailto:security@your-domain.com"

✓ How to verify it works: On https://www.ssllabs.com/ssltest/analyze.html?d=your-domain.com → "DNS CAA" section → all your CAs should be listed. Or via dig: dig CAA your-domain.com.

Your domain has no IPv6 address (AAAA record). Over 40% of users (especially mobile) reach the internet via IPv6 — they must take the slower IPv4 gateway detour.

✓ How to verify it works: dig AAAA your-domain.com — or online https://ipv6-test.com/validate.php?url=your-domain.com.

A security.txt (RFC 9116) tells security researchers how to responsibly report vulnerabilities to you. Without it, reports may go to spam or never be sent. A plain text file at the correct path is enough.

Apache server (classic hosting at most providers)

File: /.well-known/security.txt (create the folder if it doesn’t exist)

Contact: mailto:security@your-domain.com
Expires: 2027-12-31T23:59:59.000Z
Preferred-Languages: en, de
Canonical: https://your-domain.com/.well-known/security.txt

⚠ Replace "security@your-domain.com" with your actual security contact (or a generic info@). "Expires" must be a future date and should be renewed regularly. The file is plain .txt, not PHP.

Contact: mailto:security@your-domain.com
Expires: 2027-12-31T23:59:59.000Z
Preferred-Languages: en, de
Canonical: https://your-domain.com/.well-known/security.txt

✓ How to verify it works: Open https://your-domain.com/.well-known/security.txt in a browser — content must be visible (no 404).

Your consent system is wired up but the banner doesn’t appear visibly — perhaps hidden by another plugin or custom CSS. Risk: without a visible banner, no consent is given.

✓ How to verify it works: Incognito tab, load page, wait 5 seconds — banner visible centered/bottom, doesn’t fully block main content, is clickable.

The privacy policy link returns an error (HTTP HTTP/1.1 301 Moved Permanently). Effectively the same as no privacy policy — same legal status as missing.

✓ How to verify it works: Privacy link in footer → opens the page with status 200, content visible.