What Security Signals Are Visible Across Magento Sites?

Research date: September 3, 2026
Dataset: BuiltWith live Magento exports dated August 24, 2026
Status: Research brief for a future Magebean article
Method: Passive observation of public homepages only

The short answer

A public homepage can reveal whether a store sends several common browser security controls. It cannot tell us whether the store is secure.

In a deliberately varied pilot sample of 100 domains from the BuiltWith Magento data, 85 returned an HTTP response during one measurement run. Among those 85 responses:

These figures describe this pilot sample and this measurement moment. They are not estimates for all Magento stores.

The more useful finding is the unevenness. The 25-domain higher-signal group, selected using BuiltWith technology-spend and Tranco fields, sent HSTS, CSP, X-Content-Type-Options, and X-Frame-Options much more often than the general-not-Magento-2 and long-tail groups. This suggests that public security posture is more consistently maintained in some parts of the Magento market than others. It does not prove why.

The story worth telling

The original idea was simple: use the BuiltWith list to see how secure Magento looks from the outside.

The data made that question less simple, and more useful.

Almost every responding site ended on HTTPS. That sounds reassuring. But fewer than half sent HSTS, which tells a browser to keep using HTTPS in future visits. About one quarter sent a Content Security Policy. Other controls appeared at very different rates. Some sites exposed server or framework labels, while others did not.

Then the sample split into very different groups. The higher-signal stores had a visibly more consistent set of browser protections. The long tail and the group not present in the separate Magento 2 export had fewer of several controls. The pattern is not a vulnerability report. It is evidence that maintenance practices are uneven across the ecosystem.

That is the honest article: the public web does not let us count “insecure Magento stores,” but it does show a market where basic, visible security hygiene is far from uniform.

Research question

What security-related signals can be observed from the public homepages of domains in the BuiltWith Magento dataset?

This wording is intentional. It keeps the study within what the evidence can support.

The study does not answer:

• How many Magento stores contain a known vulnerability?
• How many are compromised?
• How many run an unpatched Magento version?
• Whether checkout, account, admin, API, or payment flows are secure.
• Whether a missing header can be exploited.

Those questions require different evidence, and in many cases authorization from the store owner.

Sample design

The source export contains 151,428 unique root domains. A deterministic random seed (8008) was used to draw 100 domains across four 25-domain strata:

The strata are analytical groups, not natural market segments. BuiltWith fields are third-party observations, and absence from the Magento 2 export does not prove that a site runs Magento 1.

The domain-level sample is stored locally in rn-008-sample.csv. Merchant names should not be included in the public article because the study is about aggregate patterns, not calling out individual businesses.

Passive measurement method

The measurement sent one request to https://<root-domain> and followed normal redirects. It used a descriptive research user agent, read no more than 65,536 response bytes, and recorded:

• HTTP response status and final URL scheme;
• HSTS;
• Content Security Policy;
• X-Content-Type-Options;
• Referrer-Policy;
• Permissions-Policy;
• X-Frame-Options;
• Server and X-Powered-By;
• attributes on cookies set by that single response.

There were no login attempts, form submissions, payloads, admin-path requests, directory checks, port scans, vulnerability tests, or attempts to bypass access controls.

Response quality

The 15 non-responses included DNS failures, certificate-validation problems, TLS connection problems, and timeouts. They were excluded from the header denominator. Treating them as missing security controls would bias the result.

A 403 response can reflect bot protection or an access rule. It is not evidence of an outage or vulnerability. Likewise, the response status seen in one run is not evidence of a permanent condition.

One responding domain finished on plain HTTP after the request redirected. This observation is useful for follow-up, but a single domain in a purposive sample cannot support a market-wide claim.

Results by stratum

Percentages below use the number of responding domains in each stratum, not the 25 sampled domains.

“Content type protection” means the response included X-Content-Type-Options. “Frame protection” means it included X-Frame-Options; this table does not yet parse frame-ancestors inside CSP, so it may understate modern frame controls.

The clearest pattern is the higher-signal group. It sent the four listed controls more consistently than the general and long-tail groups. Possible explanations include larger maintenance budgets, more mature hosting, agency retainers, managed platforms, or CDN defaults. This study cannot separate those causes.

The OpenMage group shows why a single score would be misleading. It had high rates for X-Frame-Options and X-Content-Type-Options, but much lower rates for CSP and HSTS. That is a configuration profile, not a verdict that the sites are safe or unsafe.

Cookies observed on the homepage response

Forty-one responses set at least one cookie. Across those responses, the run observed 67 Set-Cookie values:

These are counts of cookies created during one homepage response. They do not represent every cookie used by the site, and they do not identify which cookies are authentication or session cookies. A cookie without HttpOnly may intentionally need JavaScript access. A cookie without an explicit SameSite attribute may also receive a browser default. Therefore, these counts should be reported as observed configuration, not as exploitable weaknesses.

MDN explains that Secure limits a cookie to HTTPS requests, HttpOnly blocks access through JavaScript cookie APIs, and SameSite controls whether the cookie is sent with cross-site requests. Each attribute addresses a different part of browser behavior (MDN: Set-Cookie).

What the headers mean, and what they do not mean

• HSTS tells a supporting browser to use HTTPS for future access to the domain. It reduces downgrade and certificate-click-through risks after the browser knows the policy. Deployment still needs care because a long-lived policy can make certificate or subdomain mistakes disruptive (OWASP HSTS Cheat Sheet).
• CSP limits the sources from which a page may load scripts and other content. It can reduce the impact of cross-site scripting and injection, but it is an added layer rather than a substitute for secure code. A weak or overly broad policy can be present without providing strong protection (OWASP CSP Cheat Sheet).
• X-Content-Type-Options: nosniff tells browsers to respect declared MIME types instead of guessing them (OWASP HTTP Headers Cheat Sheet).
• Frame controls reduce unwanted embedding and clickjacking risk. Modern sites can use CSP frame-ancestors, which is more flexible than X-Frame-Options. Counting only the older header does not capture every protected site (MDN: CSP frame-ancestors).
• Referrer-Policy controls how much referring URL information the browser sends. Modern browsers have a protective default, so an absent explicit header is not the same as sending every URL detail.
• Permissions-Policy controls access to selected browser features. Its relevance depends on the features and integrations a storefront uses.
• Server and X-Powered-By can expose product labels, but the value may describe a CDN, proxy, framework, or deliberately altered response. Presence is an information signal; it is not a vulnerability by itself.

Presence is not proof of correct configuration. Absence is not proof of exploitability. The page may also deliver related controls in another way, use a report-only CSP, vary headers by route, or add controls after an edge or application change.

What can responsibly be claimed

The data supports these statements:

1. Publicly visible browser security controls were uneven in this 100-domain Magento pilot.
2. HTTPS was nearly universal among domains that responded, while explicit HSTS and CSP were much less common.
3. The higher-signal group showed more consistent use of several common response headers than the other constructed groups.
4. A meaningful passive assessment needs several controls, correct denominators, and configuration review. One header cannot serve as a security grade.
5. The public web can identify questions for a merchant or agency to investigate. It cannot establish that a Magento installation is patched or free from vulnerabilities.

The data does not support headlines such as “74% of Magento stores have no CSP” or “most Magento stores are insecure.” The sample was purposive, only 85 domains responded, and header presence is not equivalent to security.

Recommended follow-up

For a stronger public study, repeat the measurement on a larger probability-based sample and on at least two different days. Add careful parsing of CSP directives, including frame-ancestors, and distinguish enforced CSP from report-only CSP. Measure HTTP-to-HTTPS redirect behavior separately. Keep failures as their own outcome.

Any deeper work should happen with merchant authorization. That phase could verify Magento and PHP support status, Adobe security patches, extension inventory, administrative exposure, TLS configuration, checkout and account response headers, cookie roles, logging, backup restoration, and incident procedures.