Website Security in Italy in 2026: HTTPS Is Not Enough

The padlock next to a website address has become almost invisible. We take it for granted: the site uses HTTPS, the browser shows no warning, and so we instinctively assume the website is secure.

But HTTPS mainly protects the communication between browser and server. It does not tell us whether security headers are configured correctly, whether cookies are protected, whether the domain is configured against email spoofing, or whether a Content Security Policy can actually mitigate specific classes of attacks.

So how secure is the Italian web, when we look at security configuration that can be observed from the outside?

In July 2026, the Italian Web Security Study (IWSS) analyzed 10,022 .it domains, corresponding to the full set of Italian domains included in the Tranco top-1M list used for the research. The study, published as Measuring the Security Configuration of the Italian Web: A Large-Scale Passive Measurement Study, provides an interesting picture: TLS is now mature, while several other basic security measures remain surprisingly uncommon.

Readers who want to explore the charts, data and methodology directly can consult the full interactive IWSS analysis on f-hack.

10,022 domains analyzed, without attacking anyone

Before looking at the results, it is important to understand what the study actually measures.

IWSS is not a vulnerability scan and does not attempt to determine whether a website can be compromised.

The data collection process was designed as a passive measurement study: standard HTTP requests, TLS handshakes, DNS queries and requests to public resources such as robots.txt, sitemap.xml and security.txt. No exploitation, brute forcing, fuzzing or authentication attempts were performed.

Out of 10,020 completed scans, 8,829 domains successfully responded to a normal HTTP request, equal to 88.1% of the total. The remaining cases include DNS failures, timeouts, refused connections, invalid responses and TLS errors.

There is also an important methodological distinction: 10,022 domains do not represent every existing .it domain. They are the entire .it subset contained in the Tranco top-1M list dated July 8, 2026. The study therefore captures a large and relevant portion of the Italian web, but it does not claim to be a complete census of the .it registry.

That caution matters because, in cybersecurity, percentages are meaningful only when the way they were obtained is clear.

Security headers are still far from universal

One of the clearest findings concerns HTTP security headers.

These are instructions sent by the server to the browser together with the page and can enforce restrictions on browser behavior. They can help mitigate classes of attacks such as clickjacking, content-type sniffing and some forms of cross-site scripting.

Across the 8,829 reachable websites, none of the analyzed headers exceeds 42% adoption.

The important point is not simply that "some headers are missing".

It is that mature protections, documented for years and often deployable directly at web server or reverse proxy level, are still absent from most of the websites observed.

HSTS, for example, tells the browser to use HTTPS for future connections to the domain and reduces the risk of downgrade to HTTP. Yet it appears on only 32.8% of the websites analyzed.

Content Security Policy is even less common: 18.7%.

And it is precisely when looking more closely at CSP that one of the most interesting findings emerges.

Having a CSP does not necessarily mean having a good CSP

Content Security Policy allows a website to declare which sources the browser may use to load scripts, stylesheets, images, iframes and other resources.

When configured correctly, it can provide an important defensive layer against cross-site scripting.

But a CSP may technically exist without being particularly restrictive.

IWSS analyzed 1,646 CSP policies in detail. Only 11, equal to 0.7%, met the study's restrictive-policy criteria: presence of default-src or script-src, no unsafe-inline, no unsafe-eval, and no wildcard sources.

By contrast, 45.4% of the observed CSP policies used unsafe-inline, while 11.1% allowed at least one wildcard source.

This result needs to be interpreted carefully.

It does not mean that 99.3% of websites with a CSP are "vulnerable". The security of a web application cannot be reduced to a single HTTP header.

It does mean that the mere presence of Content-Security-Policy is not enough to assess the quality of the configuration.

That lesson applies well beyond CSP: in automated tools, a boolean "present / missing" check is often only the first level of analysis.

Cookies also leave room for improvement

The study observed a total of 7,240 cookies.

SameSite was missing from 51.8% of them. HttpOnly was also missing from 51.8%. The Secure attribute was missing from 47.5%.

These three attributes serve different purposes.

Secure prevents the browser from sending the cookie over unencrypted HTTP connections. HttpOnly normally prevents JavaScript running in the browser from accessing the cookie. SameSite controls whether the cookie is sent in cross-site requests and can be used as one of the defenses against certain CSRF scenarios.

Again, overly simple conclusions should be avoided.

The dataset does not classify every cookie by distinguishing, for example, an authentication cookie from an analytics cookie. The absence of HttpOnly on a tracking cookie does not have the same security meaning as the absence of the same attribute on a cookie containing a session identifier.

The percentages therefore describe attribute adoption, not the percentage of vulnerable user sessions.

That distinction may appear subtle, but it is exactly what separates a technical measurement from an alarmist headline.

TLS is the good news

If headers and cookies show substantial room for improvement, the picture changes dramatically when transport encryption is examined.

Out of 8,864 completed handshakes, 87.3% negotiated TLS 1.3, while the remaining 12.7% used TLS 1.2.

No weak cipher suites based on RC4, DES, MD5 or EXPORT algorithms were observed in the analyzed connections.

From this perspective, the web ecosystem has made enormous progress.

In only a few years, HTTPS has moved from something that had to be deliberately deployed and maintained to something hosting providers, CDNs, browsers and automated certificate systems have made almost transparent.

And that is probably one of the reasons why the browser padlock can no longer be considered a sufficient security indicator.

Obtaining and automatically renewing a TLS certificate is now relatively easy. Correctly configuring CSP, cookies, email authentication and application policies requires a much greater level of technical awareness.

The problem is not limited to the website: SPF, DKIM and DMARC

A domain does more than serve web pages.

It can also be used to send email, which is where SPF, DKIM and DMARC come into play.

Across a subset of 9,520 scans in the study, SPF was detected on 55.5% of domains, DMARC on 43.8%, and DKIM on 36.6%.

This does not mean that the remaining 44.5% of domains can automatically be impersonated successfully. Email security depends on several factors and on the policies that are actually configured.

The data does, however, show how incomplete the adoption of mechanisms designed to authenticate domain-associated email still is.

DMARC is particularly important because it allows a domain owner to tell receiving mail servers how to handle messages that fail authentication checks and provides reporting mechanisms that can help detect spoofing attempts.

For a company, website security and email security are technically separate concerns, but they share one central point: the domain represents the organization's digital identity.

Protecting the website while leaving email authentication completely exposed means protecting only part of that identity.

security.txt appears on only 2.4% of domains

Even rarer is the presence of security.txt.

The standard, defined by RFC 9116, allows an organization to publish information that can help someone who discovers a security issue, mainly by providing a clear way to contact the appropriate responsible party and disclose the problem responsibly.

In the IWSS dataset, the file was detected on only 2.4% of the domains analyzed in the extended subset.

Not having security.txt does not make a website technically less secure.

But its near-total absence suggests that a structured vulnerability disclosure culture is still uncommon across the Italian web.

And that is an organizational issue before it is a technological one: even when someone wants to report a vulnerability responsibly, they often do not know who to contact.

WordPress, Cloudflare or Nginx do not equal security

The study also collected information about observable technologies.

Cloudflare was detected on 3,053 websites, WordPress on 2,487, Nginx on 1,777 and Apache on 1,509.

These figures are not a ranking of the most or least secure products.

That distinction matters.

Knowing that a website uses WordPress does not allow us to determine its security without knowing the version, plugins, configuration, update status, infrastructure and many other factors. Likewise, the presence of Cloudflare does not automatically guarantee a secure application configuration.

Technology is context, not a verdict.

One of the most common mistakes in automated audits is turning a technology fingerprint into a risk assessment without having enough information to justify it.

Perhaps the most interesting result: famous websites can distort perception

During the development of the study, a small validation set of well-known domains was also examined.

The difference was significant: in that group, HSTS was present on 52.7% of websites, compared with 31.5% in the random comparison sample; CSP appeared on 31.9%, compared with 17.6%.

This was not the main research dataset and should not be used to build a ranking between "large" and "small" websites.

It does, however, demonstrate something methodologically important.

If we tried to assess the state of the Italian web by looking only at banks, major newspapers, multinational companies, universities and other high-profile platforms, we would probably obtain a picture that is more secure than the everyday reality of the wider web.

Organizations with structured IT teams have more resources to manage configuration, updates, CDNs, WAFs and security policies.

The long tail of less famous websites is exactly what makes a large-scale measurement particularly useful.

Security and SEO: avoid inventing correlations

For anyone working in technical SEO, one question naturally follows: does implementing CSP, HSTS, Permissions-Policy or DMARC improve rankings?

We do not have evidence to support that claim, and it would be incorrect to present these headers as direct SEO ranking factors.

Technical security does, however, have consequences that go far beyond rankings.

A compromised website can distribute malware, be defaced, become unavailable, expose data, generate spam or be added to browser and search engine blocklists. In those cases, the SEO impact can be immediate, but it is a consequence of a much more serious security problem.

The correct relationship is therefore less spectacular, but more important:

SEO, performance and security are all part of the same technical quality of a website, but they are not the same thing.

Optimizing a page for Google while neglecting its infrastructure means addressing only one part of the problem.

HTTPS is the starting point, not the destination

The IWSS study reveals an Italian web characterized by a strong contrast.

On one side, TLS: modern, widely updated and already dominated by TLS 1.3.

On the other, application- and browser-side security configuration is far less consistent: CSP appears on fewer than one in five websites, HSTS on roughly one in three, Permissions-Policy slightly above 11%, cookie security attributes are frequently missing, and email authentication remains incomplete.

That does not mean "the Italian web is insecure".

A passive measurement study cannot determine how many websites are actually vulnerable or exploitable.

What it does show is that many defensive measures that have been available for years have not yet become as widespread an operational standard as HTTPS.

And that may be the most useful result of the research.

The next time an audit reports a green padlock and a valid certificate, the question should not simply be "does the website use HTTPS?"

It should be:

what did we configure after HTTPS?

The complete study, including interactive charts and detailed results, is available in the Italian Web Security Study published on f-hack.

The paper Measuring the Security Configuration of the Italian Web: A Large-Scale Passive Measurement Study is also available on Zenodo with DOI 10.5281/zenodo.21322437: read the publication on Zenodo.

Want to check your website's configuration?

PerSeo Insights includes passive security checks as part of its technical audit, together with SEO, performance and other domain-level technical signals.

An automated audit does not replace a penetration test or vulnerability assessment, but it can be an excellent first step for identifying missing configuration and areas that deserve deeper investigation.