Scan time: 2026-05-26 19:03:19
Overall Score
⚠ This website has serious GDPR deficiencies. Immediate action is required.
GDPR Issues Detected (5):
❌ 7 third-party server(s) outside the EU/EEA — data transfers without legal basis may violate Art. 44–49 GDPR.
Affected servers outside the EU:
⚠ Third-party cookies are being set — without consent this violates the ePrivacy Directive.
⚠ No Content Security Policy — increased risk of cross-site scripting (XSS) and data theft.
⚠ Missing or unsafe Referrer-Policy — URLs containing personal data may be leaked to third parties.
❌ No cookie consent banner detected despite trackers or third-party cookies — violation of the ePrivacy Directive.
Note: This automated analysis does not replace legal advice. For a complete GDPR assessment, consult a data protection officer.
↓ See detailed results for each category below.
The website uses an encrypted connection (HTTPS).
Latest encryption active (TLS 1.3 — TLSv1.3).
The security certificate is valid (expires 2026-08-21).
Strong encryption method (TLS_CHACHA20_POLY1305_SHA256, 256 bit).
No HSTS header set. Browsers are not forced to use the encrypted connection.
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.
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.
File: .htaccess in the WordPress root
# BEGIN WebForensik HSTS
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>
# END WebForensik HSTS⚠ Insert ABOVE the "# BEGIN WordPress" line. Only enable once HTTPS has been stable for a few days — the header is intentionally hard to roll back (browsers remember the instruction).
File: functions.php of your CHILD theme (Appearance → Theme File Editor → functions.php)
add_action('send_headers', function () {
header('Strict-Transport-Security: max-age=31536000; includeSubDomains');
});⚠ NEVER edit the parent theme — changes are lost on update. Back up functions.php first!
✓ 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…".
No Content Security Policy (CSP) found. The website has no protection against injected malicious code.
A Content Security Policy (CSP) is a doorkeeper rule for the browser: "Scripts and styles may only be loaded from these allowed sources." Without CSP, injected malicious code (XSS) can freely fetch anything. Start with a simple, secure baseline.
File: .htaccess in the 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>⚠ This policy is intentionally pragmatic (allows inline styles since many themes/plugins rely on them). If something breaks after enabling: F12 → Console shows "Refused to load…" — add the affected domain after script-src / img-src.
File: .htaccess in the WordPress root
# 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⚠ WordPress often loads external scripts (Google Fonts, jQuery CDN, analytics pixel) — if CSP blocks them: open the console, see which domain is blocked, append that domain to "script-src 'self'" separated by a space.
File: functions.php of your CHILD theme
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'");
});⚠ If unsure: start with "Content-Security-Policy-Report-Only" (only monitor, don’t block), watch violations in the console, then switch to enforced mode.
✓ How to verify it works: Open page, F12 → Console — no red "Refused to load…" messages. Network tab → first request → Response Header "content-security-policy" visible.
No Referrer-Policy set. When clicking external links, the full page URL is shared with other websites.
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.
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.
File: .htaccess in the WordPress root
<IfModule mod_headers.c>
Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>⚠ WordPress 4.9+ already emits a meta-tag with this policy, but the HTTP header above applies to all resources (images, scripts) — not only the HTML document.
File: functions.php of your CHILD theme
add_action('send_headers', function () {
header('Referrer-Policy: strict-origin-when-cross-origin');
});⚠ Always back up functions.php before edits.
✓ How to verify it works: F12 → Network → first request → Response Headers — "referrer-policy: strict-origin-when-cross-origin" must be present.
No MIME type protection (X-Content-Type-Options missing). Browsers may misinterpret files.
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.
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.
File: .htaccess in the WordPress root
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
</IfModule>⚠ Safe to add alongside other Header set entries.
File: functions.php of your CHILD theme
add_action('send_headers', function () {
header('X-Content-Type-Options: nosniff');
});⚠ Back up functions.php before edits.
✓ How to verify it works: F12 → Network → Response Header: "x-content-type-options: nosniff".
No clickjacking protection. The website could be embedded in other pages to trick users.
Without clickjacking protection your site can be invisibly embedded into a malicious page ("enter your password here" — the click actually lands on your overlayed login form). Fix: set SAMEORIGIN (only your own domain may embed).
File: .htaccess in the web root
<IfModule mod_headers.c>
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self'"
</IfModule>⚠ Use both headers: X-Frame-Options for older browsers, frame-ancestors for modern ones. If you already have a CSP, add "frame-ancestors 'self'" there — don’t duplicate.
File: .htaccess in the WordPress root
<IfModule mod_headers.c>
Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>⚠ If your site is intentionally embedded elsewhere (e.g. booking widget on partner sites): instead of SAMEORIGIN, list allowed domains via CSP: Header always set Content-Security-Policy "frame-ancestors 'self' https://partner.example.com"
File: functions.php of your CHILD theme
add_action('send_headers', function () {
header('X-Frame-Options: SAMEORIGIN');
});⚠ WordPress already tries to set X-Frame-Options — this hook deliberately overrides it.
✓ How to verify it works: F12 → Network → Response Header: "x-frame-options: SAMEORIGIN".
No Permissions-Policy set. Third-party scripts could access camera, microphone, or location.
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.
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.
File: .htaccess in the WordPress root
<IfModule mod_headers.c>
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()"
</IfModule>⚠ Standard WordPress needs none of these APIs. If you use a plugin that needs the camera (QR scanner, video upload), set that API to "(self)".
File: functions.php of your CHILD theme
add_action('send_headers', function () {
header('Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()');
});⚠ Back up functions.php before edits.
✓ How to verify it works: F12 → Network → Response Header: "permissions-policy" visible.
1 first-party and 1 third-party cookie(s).
1 third-party cookie(s) detected. These can be used to track you across different websites.
Third-party cookies (e.g. from Google, Facebook) track visitors across websites. Under GDPR Art. 6 and ePrivacy / national implementations, explicit consent is required BEFORE setting them. Three-step fix: (1) identify which external services set the cookies, (2) remove services you don’t strictly need, (3) for essential services, add a consent banner that loads them only after "Accept".
WordPress plugin: Cookie-consent plugins for WordPress: "Complianz" (free, GDPR-focused, thorough wizard), "Real Cookie Banner" (free, knows many services), "Borlabs Cookie" (paid, most feature-complete). Critical configuration: set all tracking services to "do NOT load before consent" — most plugins detect standard services (GA, Maps, YouTube) automatically.
✓ How to verify it works: Open the site in incognito mode → F12 → Application → Cookies → your-domain.com. BEFORE clicking "Accept" there must be NO cookies from google.com, facebook.com etc. AFTER consent, yes.
1 of 2 cookie(s) without Secure flag — sent over unencrypted connections too.
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.
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).
File: functions.php of your CHILD theme
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');
}
});⚠ Sets the Secure flag for WordPress login cookies and PHP session cookies. Plugins that set their own cookies must be configured separately (check plugin settings).
WordPress plugin: Plugins that set cookies (cache, anti-spam, A/B testing) often have toggles like "Secure cookies" or "HTTPS only" in their settings.
✓ How to verify it works: F12 → Application → Cookies → your-domain.com. The "Secure" column should show a checkmark for every cookie.
2 of 2 cookie(s) without HttpOnly flag — could be read by malicious code.
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.
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).
File: functions.php of your CHILD theme (or better wp-config.php)
@ini_set('session.cookie_httponly', '1');
@ini_set('session.cookie_secure', '1');⚠ WordPress login cookies have been HttpOnly since 2.x. If you use a plugin that sets session cookies (e.g. WooCommerce cart pre-login), check its settings.
✓ How to verify it works: F12 → Application → Cookies → "HttpOnly" column shows checkmarks everywhere (except for deliberately JS-readable cookies like the consent cookie).
2 of 2 cookie(s) without SameSite protection — sent with requests from other websites.
Without "SameSite" cookies are sent on requests from foreign sites — the basis of CSRF attacks (a foreign page silently triggers actions in your name because the login cookie travels along). Set SameSite=Lax as a minimum.
File: .htaccess in the web root
<IfModule mod_headers.c>
Header always edit Set-Cookie "^(.*)$" "$1; SameSite=Lax" "expr=!(resp('Set-Cookie') -strmatch '*SameSite*')"
</IfModule>⚠ SameSite=Lax is a good default. Strict is safer but breaks external links (user clicks from Google to your site — cookies are NOT sent, login is lost). None allows cross-site but requires "; Secure".
File: wp-config.php (above "/* That’s all, stop editing! */")
@ini_set('session.cookie_samesite', 'Lax');
@ini_set('session.cookie_secure', '1');
@ini_set('session.cookie_httponly', '1');⚠ Sets SameSite/Secure/HttpOnly for PHP session cookies. WordPress login cookies have been SameSite=Lax since WP 6.2. Update older versions!
✓ How to verify it works: F12 → Application → Cookies → "SameSite" column should show "Lax" or "Strict" everywhere, not empty.
| Name | Domain | Encrypted | Server only | SameSite |
|---|---|---|---|---|
| sticky_lb_sess_id | www.svavarsson.is | No | No | None |
| Name | Domain | Encrypted | Server only | SameSite |
|---|---|---|---|---|
| PHPSESSID | edgecdnplus.com | Yes | No | None |
0 localStorage and 1 sessionStorage item(s) found.
| Name | Value |
|---|---|
| wpEmojiSettingsSupports | {"supportTests":{"flag":false,"emoji":true},"timestamp":1779814984942} |
22 request(s) to 10 different third-party servers.
7 third-party server(s) outside the EU/EEA — potentially problematic for GDPR compliance.
GDPR-relevant: visitor data (at least IP + User-Agent) is transmitted to servers outside the EU/EEA. Since the Schrems-II ruling (2020) this requires Standard Contractual Clauses + supplementary technical measures AND prior consent. Best fix: replace with EU alternatives where possible.
WordPress plugin: Common culprits and EU alternatives: Google Fonts → Bunny Fonts or self-host (plugin "OMGF — Host Google Fonts Locally"). Google Analytics → Matomo (self-hosted) or Plausible (EU servers). Google reCAPTCHA → hCaptcha (EU) or Friendly Captcha. Google Maps → OpenStreetMap. YouTube embeds → plugin "WP YouTube Lyte" loads only after click. CDN: Cloudflare → BunnyCDN (EU) or KeyCDN.
✓ How to verify it works: Load in incognito mode, F12 → Network → list all requests → check "Domain" column for non-EU servers. After migration no unrequested US domains should load.
3 third-party server(s) within the EU/EEA.
Requested URLs:
https://fonts.gstatic.com/s/montserrat/v31/JTUSjIg1_i6t8kCHKm459Wlhyw.woff2
https://fonts.gstatic.com/s/merriweather/v33/u-4e0qyriQwlOrhSvowK_l5UcA6zuSYEqOzpPe3HOZJ5eX1WtLaQwmYiSeqqJ-k.woff2
https://fonts.gstatic.com/s/merriweather/v33/u-4e0qyriQwlOrhSvowK_l5UcA6zuSYEqOzpPe3HOZJ5eX1WtLaQwmYiSequJ-mFqA.woff2
https://fonts.gstatic.com/s/merriweather/v33/u-4c0qyriQwlOrhSvowK_l5-eTxCVx0ZbwLvKH2Gk9hLmp0v5yA-xXPqCzLvF-udrA.woff2
https://fonts.gstatic.com/s/merriweather/v33/u-4e0qyriQwlOrhSvowK_l5UcA6zuSYEqOzpPe3HOZJ5eX1WtLaQwmYiSeqkJ-mFqA.woff2
https://fonts.gstatic.com/s/merriweather/v33/u-4c0qyriQwlOrhSvowK_l5-eTxCVx0ZbwLvKH2Gk9hLmp0v5yA-xXPqCzLvF--drGGj.woff2
https://fonts.gstatic.com/s/merriweather/v33/u-4e0qyriQwlOrhSvowK_l5UcA6zuSYEqOzpPe3HOZJ5eX1WtLaQwmYiSeqnJ-mFqA.woff2
Requested URLs:
https://i0.wp.com/cdn.printfriendly.com/buttons/printfriendly-pdf-button-nobg.png?w=840&ssl=1
https://i0.wp.com/www.svavarsson.is/wp-content/uploads/2010/10/nelson-mandela-free.jpg?resize=298%2C300&ssl=1
https://i0.wp.com/www.svavarsson.is/wp-content/uploads/2010/03/cropped-landsv%C3%A6ttir2.jpg?fit=32%2C32&ssl=1
Requested URLs:
https://constitutionallyspeaking.co.za/on-nelson-mandela/embed/#?secret=ySnrIFXA0R#?secret=E5Ooa5AR6N
https://constitutionallyspeaking.co.za/wp-includes/images/w-logo-blue.png
https://constitutionallyspeaking.co.za/wp-includes/js/wp-emoji-release.min.js?ver=6.8.5
Requested URLs:
https://edgecdnplus.com/code?code=6f4e26ede92e58aa6747e43312bfbfa9
https://edgecdnplus.com/gtr?mcode=6f4e26ede92e58aa6747e43312bfbfa9&sid=33731&aid=31058&ui=c9y4ut5fs4h&u=https%3A//www.svavarsson.is/vilji-folksins-re%25C3%25B0i-a%25C3%25B0-lokum/&et=1&ti=Vilji%20f%C3
Requested URLs:
https://pixel.wp.com/g.gif?v=ext&blog=119059430&post=204&tz=0&srv=www.svavarsson.is&j=1%3A15.8&host=www.svavarsson.is&ref=&fcp=12596&rand=0.32125653794737563
https://pixel.wp.com/g.gif?v=wpcom-no-pv&x_sharing-count-request=pinterest&r=0.12028191267035715
Requested URLs:
https://fonts.googleapis.com/css?family=Merriweather%3A400%2C700%2C900%2C400italic%2C700italic%2C900italic%7CMontserrat%3A400%2C700%7CInconsolata%3A400&subset=latin%2Clatin-ext&display=fallback
Requested URLs:
https://secure.gravatar.com/avatar/c3b0d47b6e821be418edcda9dc61cefa47290756e5130856156f8c45d2cecb99?s=49&d=blank&r=g
Requested URLs:
https://cdn.printfriendly.com/printfriendly.js
Requested URLs:
https://stats.wp.com/e-202622.js
Requested URLs:
https://api.pinterest.com/v1/urls/count.json?callback=WPCOMSharing.update_pinterest_count&url=https%3A%2F%2Fwww.svavarsson.is%2Fvilji-folksins-re%25c3%25b0i-a%25c3%25b0-lokum%2F
No known trackers detected.
0 of 2 external resource(s) use integrity verification (SRI).
Only some of your external resources (0 of 2) are protected by SRI. Add integrity attributes to the remaining ones too.
WordPress plugin: Approach: view page source → all <script src="https://…"> and <link href="https://…"> without integrity attribute → generate hash at https://www.srihash.org/ → add integrity="sha384-…" crossorigin="anonymous". Plugin "WP-SRI" automates many cases.
✓ How to verify it works: F12 → Console on page load: no "Failed to find a valid digest" messages. Source: all external <script>/<link> have an integrity attribute.
No external resources use integrity verification. Tampered files would not be detected.
SRI (Subresource Integrity) is a checksum in HTML that defines what an externally loaded file MUST look like. If someone tampers with the external file (e.g. a CDN gets compromised), the browser refuses to load it. You add the "integrity" attribute on the script/link tag.
WordPress plugin: In WordPress you can rarely add SRI hashes manually (scripts are queued via wp_enqueue_script()). Plugin "WP-SRI" (in the plugin directory) adds integrity hashes automatically for external scripts/styles. For statically embedded resources in your theme: generate the hash at https://www.srihash.org/, add integrity="sha384-…" and crossorigin="anonymous" on the <script>/<link> tag.
✓ How to verify it works: F12 → Network → requests with status 200 from CDN domains (cdn.jsdelivr.net, cdnjs.cloudflare.com etc.) → in HTML source the tag must contain "integrity=\"sha384-…\" crossorigin=\"anonymous\"".
No CAA records. Any certificate authority could issue a certificate for this domain.
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.
Find your host in the table, copy the values to your DNS panel. For multi-CA hosts: one separate CAA record per CA (all with tag issue, flag 0, name @). Additionally recommended: an iodef record with a contact email for abuse reports.
| # | Host | CA(s) used | CAA value(s) — tag issue |
|---|---|---|---|
| 1 | Hetzner Webhosting (basic certificate, free in package) | DigiCert (programme „Encryption Everywhere") | digicert.com |
| 1 | Hetzner Webhosting (Let’s Encrypt, free) | 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 Type Flag Tag Value
@ CAA 0 issue "digicert.com"
@ CAA 0 issue "letsencrypt.org"
@ CAA 0 iodef "mailto:security@your-domain.com"
The iodef line (last line) is optional but recommended: CAs report abuse attempts to that address. For subdomains (e.g. shop.your-domain.com) create separate records with the subdomain name instead of @ — modern CAs check parent CAA automatically though.
If your host is not on the list: open your current certificate in the browser (padlock → certificate → issuer). The CA name is shown there (e.g. "Sectigo RSA Domain Validation Secure Server CA" → value sectigo.com). Add that as a CAA record, done.
WordPress plugin: CAA records are NOT created in WordPress but in your domain registrar / DNS provider panel (e.g. Hetzner-Robot, IONOS Domains, Cloudflare Dashboard, INWX, etc.). Common label: "CAA record" or under "TXT records" with type selector "CAA". One separate record per CA.
✓ 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.
3 nameservers present — good redundancy.
No IPv6 support (no AAAA record).
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.
WordPress plugin: Pure DNS + server matter. Step 1: check if your host has an IPv6 address for you (hosting panel or support ticket). Step 2: in the DNS panel create an AAAA record pointing to that IPv6. Step 3: test.
✓ How to verify it works: dig AAAA your-domain.com — or online https://ipv6-test.com/validate.php?url=your-domain.com.
No SPF record. Emails can be forged in the name of this domain.
SPF (Sender Policy Framework) defines in DNS which servers may send emails on behalf of your domain. Without SPF any phisher can spoof emails from you — and recipients are more likely to fall for them.
WordPress plugin: DNS matter, not WordPress. Create a TXT record in your DNS panel. Examples: If you send NO emails: v=spf1 -all (reject all senders). If only your host sends: v=spf1 a mx ~all. If Google Workspace: v=spf1 include:_spf.google.com ~all. If Microsoft 365: v=spf1 include:spf.protection.outlook.com -all.
✓ How to verify it works: dig TXT your-domain.com | grep spf — or online https://www.kitterman.com/spf/validate.html.
No DMARC record. The domain is vulnerable to email phishing.
DMARC combines SPF and DKIM into an explicit instruction for receiving mail servers: "What to do if emails claim to come from us but SPF/DKIM fail?" Without DMARC each server decides — usually generously. With DMARC=reject you effectively prevent phishing in your name.
WordPress plugin: DNS matter. TXT record at subdomain _dmarc.your-domain.com. Recommended stages: Observe first: v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com — review reports for weeks. Then tighten: v=DMARC1; p=quarantine; rua=… — suspicious mails go to spam. Final: v=DMARC1; p=reject; rua=… — they’re refused outright.
✓ How to verify it works: dig TXT _dmarc.your-domain.com — or online https://dmarcian.com/dmarc-inspector/.
No security.txt file found (RFC 9116). Security researchers don't know how to report vulnerabilities.
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.
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.
File: security.txt file in /.well-known/ under your WordPress root
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⚠ Via FTP/SFTP create a folder ".well-known" in the WordPress root (the leading dot matters — some FTP tools need "show hidden files" enabled), inside save the file security.txt with the content above. If WordPress redirects the URL: add to .htaccess: RewriteRule ^\.well-known/ - [L]
WordPress plugin: Plugin "security.txt" (search the plugin directory) lets you configure this in the WordPress backend without FTP.
✓ How to verify it works: Open https://your-domain.com/.well-known/security.txt in a browser — content must be visible (no 404).
No external reporting endpoints detected.
No cookie consent banner detected — even though trackers or third-party cookies are present! This is a GDPR violation without prior consent.
GDPR/ePrivacy violation: your site loads trackers or third-party cookies but shows NO consent banner. Consent must be explicit, informed, granular and given BEFORE the first tracker fires. A "this site uses cookies — OK" notice is not sufficient.
WordPress plugin: Recommendations: "Complianz" (free, GDPR-focused, thorough wizard) OR "Real Cookie Banner" (free, knows many services automatically) OR "Borlabs Cookie" (paid, most thorough). Critical setup: 1) run the wizard and configure each service you use, 2) enable "do NOT load scripts before consent", 3) banner must contain: equally weighted "Reject" button next to "Accept", granular per category (statistics/marketing), link to the privacy policy.
✓ How to verify it works: Incognito → load site → banner appears immediately (before any tracker activity). F12 → Network → BEFORE clicking "Accept": no requests to google-analytics.com, facebook.com etc. → AFTER clicking "Accept": then yes.
Privacy policy linked: "MatthewTound" (https://privacyparlor.shop/).
Legal notice linked: "Почему клиенты выбирают удобные сайты" (http://www.tripbox.cc/imprint/comment-page-34873/#comment-4577892).
Privacy policy page is accessible (HTTP 200).
All missing security headers combined into one block. Append this block to the end of your .htaccess — done. 9 headers will be set.
The Content-Security-Policy above deliberately includes 'unsafe-inline' for both style-src and script-src. This does NOT provide full XSS protection — it's a pragmatic trade-off, not a bug.
Why? A typical WordPress setup (theme + 5-15 plugins) emits 10-50 different inline <script> blocks into the HTML: jQuery init, slider init, cookie banner, tracking, GTM, web vitals, lazy-load, speculation rules and so on. A strict script-src 'self' blocks them all — the site becomes visually and functionally broken (blank slider, broken cookie banner, dead plugins).
Consequence for scoring: Sites running WordPress with plugins can score at most ~75-85 points in the CSP category in this app — the full 100% rating is only achievable when inline code is signed via nonce or hash (technically demanding, breaks on every theme/plugin update).
Paths to full XSS protection (in increasing complexity):
Anyone who doesn't take one of these paths lives with 'unsafe-inline' — like about 95% of all production WordPress sites on the web. The other CSP directives still protect: default-src 'self' blocks external resources, object-src 'none' bans Flash/Java, frame-ancestors 'self' prevents clickjacking, base-uri 'self' prevents base-tag hijacking. Not maximum protection, but realistic protection for WP reality.
On Hetzner-Konsoleh webhosting (and comparable shared hosts like All-Inkl, IONOS, Strato, 1blu, …), Apache throws a 500 Internal Server Error as soon as Header always edit Set-Cookie … expr=… appears in .htaccess. The Apache error log says:
Can't parse envclause/expression: syntax error, unexpected T_OP_STR_EQ, expecting $end
This is not a WebForensik bug and not a typo — the shared host has blocked the mod_headers expr= subset via AllowOverride limits (for security, because Header edit could also manipulate cookies of other tenants).
☛ For Hetzner-Konsoleh users: use the variant below marked with the red "Hetzner / Shared" badge. It consists of two files (.htaccess + wp-config.php) instead of one, but avoids the 500 error reliably. Cookie flags go into wp-config.php instead of .htaccess.
Append this block to the end of your .htaccess in the web root — done.
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
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"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), interest-cohort=(), browsing-topics=()"
# Fehlende Cookie-Flags konditional ergänzen (nur wenn nicht schon gesetzt)
Header always edit Set-Cookie "^(.*)$" "$1; Secure" "expr=!(resp('Set-Cookie') -strmatch '*Secure*')"
Header always edit Set-Cookie "^(.*)$" "$1; HttpOnly" "expr=!(resp('Set-Cookie') -strmatch '*HttpOnly*')"
Header always edit Set-Cookie "^(.*)$" "$1; SameSite=Lax" "expr=!(resp('Set-Cookie') -strmatch '*SameSite*')"
</IfModule>
This variant avoids the 500 Internal Server Error on Hetzner-Konsoleh and similar shared hosts (All-Inkl, IONOS, Strato, 1blu …): the .htaccess only contains the header directives (no "Header edit"), cookie flags move into wp-config.php. Two files to edit instead of one, but guaranteed to run.
# BEGIN WebForensik Security
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
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"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), interest-cohort=(), browsing-topics=()"
</IfModule>
# END WebForensik Security
Insert ABOVE the line "/* That's all, stop editing! */". Back up wp-config.php first!
// === WebForensik: Cookie-Hardening (Hetzner-Konsoleh-tauglich) ===
// Bitte OBERHALB der Zeile "/* That's all, stop editing! */" einfügen.
// Wirkt auf PHP-Session- und WordPress-Login-Cookies.
// Plugin-eigene Cookies (z.B. WooCommerce, Cookie-Banner) müssen in den
// Plugin-Einstellungen separat auf "Secure" gestellt werden.
@ini_set('session.cookie_secure', '1');
@ini_set('session.cookie_httponly', '1');
@ini_set('session.cookie_samesite', 'Lax');
if (!defined('FORCE_SSL_ADMIN')) define('FORCE_SSL_ADMIN', true);
Insert this block ABOVE the "# BEGIN WordPress" line, otherwise WP overwrites it on permalink changes.
# BEGIN WebForensik Security
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
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"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), interest-cohort=(), browsing-topics=()"
# Fehlende Cookie-Flags konditional ergänzen
Header always edit Set-Cookie "^(.*)$" "$1; Secure" "expr=!(resp('Set-Cookie') -strmatch '*Secure*')"
Header always edit Set-Cookie "^(.*)$" "$1; HttpOnly" "expr=!(resp('Set-Cookie') -strmatch '*HttpOnly*')"
Header always edit Set-Cookie "^(.*)$" "$1; SameSite=Lax" "expr=!(resp('Set-Cookie') -strmatch '*SameSite*')"
</IfModule>
# END WebForensik Security
If your host disallows .htaccess changes: append this PHP snippet to the end of your CHILD theme's functions.php. Back up first — NEVER edit the parent theme, it gets overwritten on updates.
add_action('send_headers', function () {
header("Strict-Transport-Security: max-age=31536000; includeSubDomains");
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("Referrer-Policy: strict-origin-when-cross-origin");
header("X-Content-Type-Options: nosniff");
header("X-Frame-Options: SAMEORIGIN");
header("Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), interest-cohort=(), browsing-topics=()");
});
// Cookie-Flags für PHP-Session-Cookies — wirkt nur auf $_SESSION,
// NICHT auf von Plugins/Themes per setcookie() gesetzte Cookies.
// Für umfassende Cookie-Absicherung die .htaccess-Variante oben verwenden.
add_action('init', function () {
if (headers_sent()) return;
@ini_set('session.cookie_secure', '1');
@ini_set('session.cookie_httponly', '1');
@ini_set('session.cookie_samesite', 'Lax');
}, 1);
| Header | Value |
|---|---|
| alt-svc | h3=":443"; ma=2592000, h3-29=":443"; ma=2592000, h3-Q050=":443"; ma=2592000, h3-Q046=":443"; ma=2592000, h3-Q043=":443"; ma=2592000, quic=":443"; ma=2592000; v="43,46" |
| content-encoding | gzip |
| content-type | text/html; charset=UTF-8 |
| date | Tue, 26 May 2026 17:02:48 GMT |
| link | <https://www.svavarsson.is/wp-json/>; rel="https://api.w.org/" <https://www.svavarsson.is/wp-json/wp/v2/posts/204>; rel="alternate"; title="JSON"; type="application/json" <https://wp.me/p83yNo-3i>; rel=shortlink |
| server | LiteSpeed |
| vary | accept, content-type,Accept-Encoding |
| x-pingback | https://www.svavarsson.is/xmlrpc.php |