Everyone has HTTPS. Almost no one has CSP. The security findings from 99 Norwegian online stores

What was measured, and what wasn't?

The security tests check HTTP response headers at the sites the crawler could read, measurable for 77 of the 78, plus DNS and email setup for all 99, since DNS can be checked even when a site blocks robots.

Be clear about what kind of measurement this is: a presence check, not a penetration test. We see whether the protection is switched on, not whether it would hold up against a targeted attack. A site can have every header in place and still have vulnerabilities, and vice versa. But the headers are the industry's cheapest line of defense, and their absence is measurable.

The foundation holds: transport and hygiene

What works, works almost everywhere:

• 95% automatically redirect visitors to HTTPS. An encrypted connection is effectively standard in Norwegian e-commerce.
• 91% have a Referrer-Policy: the header that stops internal URL information from leaking to third parties.
• 86% set secure attributes on cookies, so session information can't be read by scripts or sent unencrypted.

This is the part of the picture that gives reason for calm. Norwegian e-commerce has done the work that became an industry norm five to ten years ago.

Then it gets thin, header by header

Above the foundation, the numbers drop fast:

Read that last row again: only 2 of 77 measured online stores have a Content-Security-Policy. 97% lack it.

For an online store, this isn't a theoretical gap. The best-known attack class against e-commerce is online card skimming, "formjacking", where a foreign or tampered script reads the payment form as the customer fills it in. CSP and Subresource Integrity are exactly the two mechanisms that limit which scripts are allowed to run and verify that they haven't been altered. They're the two weakest rows in the entire table.

Email: the infrastructure exists, the enforcement doesn't

Email trust is actually one of the strongest categories in the audit, with an average of 81 out of 100. Only crawlability and mobile score higher. The infrastructure is nearly complete: SPF exists for all 99, MX for 97%, DKIM for 87%.

But then comes the policy question: what should the recipient's email server do with a message that claims to come from your domain but fails the checks? That's governed by DMARC, and here's how the 99 stores split:

• 33 have `p=reject`: forged messages are rejected
• 21 have `p=quarantine`: they land in spam
• 42 have `p=none`: they're monitored but delivered as normal
• 3 lack DMARC or have a misconfigured setup

42 stores, more than have reject, are standing with a defense that looks complete in DNS but stops nothing at all. For an online store, the scenario is concrete: fake order confirmations, fake invoices and "tracking links" sent in your name, to your customers, from a domain that receiving systems have been told to treat leniently. Your customers are the ones who pay the price, and your brand is the sender they remember.

There's a good reason many stay on p=none: the road to reject requires that all legitimate outgoing mail, newsletters, order confirmations, customer service, is actually signed correctly, or you stop your own email. But none is meant as a monitoring phase measured in weeks, not a permanent state.

What this means for the score, and what it actually means

In the scoring model that applied in August, security headers weighed 6 out of 100 and email trust 5. The security category average came out at 68 out of 100, a number that hides the split between strong transport and thin header protection.

But points aren't the point here. The visibility findings in the study are about being found; the security findings are about what meets customers once they arrive. An online store lives on the trust that exists in the exact moment someone types in their card number or opens an order confirmation. That's the trust these configurations protect.

Five fixes, in the order we'd tackle them

1. Tighten DMARC. If you're on p=none today: use the reports you're already receiving to verify that all legitimate mail is signed, move to quarantine, then to reject. This is DNS changes and verification work, not development.
2. Turn on HSTS with a lifetime of at least six months. One header line in your web server or CDN. 34% lack it entirely today.
3. Set X-Frame-Options (or frame-ancestors in a CSP). One line, and the clickjacking surface is closed. Half of stores lack it.
4. Add `X-Content-Type-Options: nosniff`. The cheapest row in the table: one line, done.
5. Start CSP work, but start in reporting mode. Here we should be honest: CSP is the only one of these that's a real project. An online store typically has many third-party scripts, and an overly strict policy can break your checkout. Start with Content-Security-Policy-Report-Only, map what's actually loading, and tighten from there. Add Subresource Integrity to the third-party scripts you can lock down. That 97% lack CSP doesn't mean it's impossible: it means almost no one has started.

An honest caveat

Three things to keep in mind. First, the tests measure presence, not resilience: a passed header test is not a security guarantee. Second, the header numbers apply to the 77 measurable sites the crawler could read; the 21 stores that block robots aren't included, and we don't know how they'd have scored. Third, absolutely every measured site passes certain of our tests (CORS and CORP setup). Tests everyone passes don't distinguish between anyone, so we give them no weight here.

And as always: the numbers were measured with our own tool, August 8–10, 2026, and stand as measured.

Closing thoughts

The security picture in Norwegian e-commerce resembles the visibility picture more than we expected: last decade's work is done, this decade's work has barely begun. HTTPS everywhere, CSP almost nowhere. SPF for everyone, enforcement for a third.

The encouraging part is that four of the five fixes above are configuration lines and DNS changes: work measured in hours, not weeks. Norwegian e-commerce is one calm afternoon away from closing the most common gaps. The fifth fix, CSP, takes more, but reporting mode lets you start without risking anything at all.

Feel free to check your own store: open your browser's developer tools, look at the response headers on your homepage, and look up your DMARC record. If you find p=none there, you know where to start. Good luck!