ImmuniWeb® Website Security Test
Our A+ Rating – What does it mean and how did we get it?
Table of Contents
- 1. ImmuniWeb® – what is it and why does it matter?
- 2. What does the ImmuniWeb® Website Security Test examine?
- 3. The scoring system
- 4. How do websites generally perform?
- 5. What does our A+ rating mean?
- 6. Why is this rating special alongside the others?
- 7. The limitations of the Website Security Test
- 8. Summary
1. ImmuniWeb® – what is it and why does it matter?
ImmuniWeb is a Swiss cybersecurity company operating a free, no-registration test suite called ImmuniWeb® Community Edition since 2019. The suite has run over 380 million tests and performs over 100,000 tests daily. ImmuniWeb's data is also used in Verizon's globally definitive annual Data Breach Investigations Report (DBIR), which indicates the tool's professional recognition.
The Community Edition includes seven different tests covering web applications, SSL/TLS configuration, email security, mobile apps, and Dark Web exposure. Our previous article covered the Website Privacy Test; this piece introduces its counterpart, the Website Security Test, which alone has been run more than 190 million times. Since April 2025, both tests offer a PDF certificate and digital badge: anyone achieving an A grade (or higher) can download a document verifying the result.
The Security Test fundamentally asks a different question than the Privacy Test. The Privacy Test seeks to find out what the site reveals about its users to third parties – what data leaks through tracking pixels, third-party cookies, and external resources. In contrast, the Security Test examines how resilient the site itself is to attacks: whether it runs outdated or vulnerable software, whether HTTP security headers are configured correctly, whether the Content Security Policy is appropriate, whether cookies are hardened, and whether the site protects against classic attack vectors like Cross-Site Scripting (XSS), clickjacking, man-in-the-middle, or code injection.
Simply put: the Privacy Test asks, "does the site betray its users?", while the Security Test asks, "can the site be turned against its users?". The two are complementary but sharply distinct dimensions – a site can be flawless from a privacy standpoint while being severely vulnerable due to an outdated component, and vice versa.
2. What does the ImmuniWeb® Website Security Test examine?
The test covers ten testing areas that map out the entire attack surface visible from the browser. These can be organized into the following thematic groups.
2.1. Web software and vulnerabilities
The test "fingerprints" the software running on the site: it identifies the Content Management System (CMS), its components (plugins, themes), and the JavaScript libraries in use. It then cross-references every identified element against a database of publicly known vulnerabilities (CVEs). This is one of the most heavily weighted areas of the test: an outdated and vulnerable CMS alone can mean a deduction of up to 50 points.
Additionally, the test analyzes modified – and thus potentially malicious – JS libraries, and verifies the Subresource Integrity (SRI) protection of loaded external content, which guarantees via a cryptographic footprint that an external resource (e.g., a script loaded from a CDN) has not been tampered with in transit.
2.2. HTTP security headers
The test analyzes the syntax, validity, and reliability of the HTTP response headers sent by the server in detail. The most important ones are:
- Strict-Transport-Security (HSTS): mandates the browser to use HTTPS, preventing downgrade attacks.
- X-Frame-Options: defense against clickjacking by controlling whether the site can be embedded in an iframe.
- X-Content-Type-Options: prevents the browser from "guessing" the MIME type, which can be an XSS attack vector.
- Permissions-Policy: controls which browser features (camera, microphone, geolocation, etc.) the site can access.
- Information-leaking headers: the
Server,X-Powered-By, andX-AspNet-Versionheaders, which reveal the server's software version – each of these incurs a point deduction because they facilitate the preparation of targeted attacks.
2.3. Content Security Policy (CSP)
CSP is a ruleset provided to the browser specifying from which sources the site is allowed to load content. This is the most effective browser-side defense against XSS attacks. The test does not merely check for the header's presence, but deeply analyzes individual directives (default-src, script-src, frame-ancestors, object-src, etc.), evaluating whether they genuinely restrict allowed sources or are too permissive (e.g., containing wildcards). A properly configured, enforced CSP yields a significant point bonus.
2.4. Web server configuration and cookie security
The test examines the allowed HTTP methods: enabling TRACE, TRACK, CONNECT, or custom methods results in a point deduction because they can open up an attack surface. It also detects whether there is a Web Application Firewall (WAF) in front of the site, and analyzes any cookies for security flags (HttpOnly, Secure, SameSite, as well as the __Secure- and __Host- prefixes).
2.5. GDPR and PCI DSS compliance
The test does not substitute for a legal audit but performs a non-invasive, technical-level compliance check. In terms of GDPR, it checks for the presence of a privacy policy, HTTPS encryption, and cookie handling. Regarding the PCI DSS (payment card data processing) requirements 6.3 and 6.4, it looks at whether there are known vulnerabilities in the fingerprinted software and whether a WAF protects the site.
2.6. Protection against data scraping and DNSSEC
The test also measures a newer, increasingly relevant dimension: protection against AI bots. It detects whether the site restricts scraping crawlers, including the training bots of major AI companies, using robots.txt rules, meta-restrictions, or server-side User-Agent-based blocking. Finally, it verifies the implementation of DNSSEC, which guarantees the authenticity and integrity of the domain's DNS data via cryptographic signature, preventing DNS spoofing.
3. The scoring system
The Website Security Test starts with a base score of 100 points, adding or deducting points depending on the results of the examined elements. An A+ grade requires a final score above 100 points, meaning it is not enough to simply avoid penalty points: the bonus points for good configuration must also be acquired.
3.1. Grades
| Score | Grade |
|---|---|
| Over 100 | A+ |
| 90–99 | A |
| 80–89 | A− |
| 70–79 | B+ |
| 60–69 | B |
| 50–59 | B− |
| 35–49 | C+ |
| 20–34 | C |
| Under 20 | F |
3.2. Scoring details (selection)
| Examined element | Point impact |
|---|---|
| WAF is present | +20 |
| CMS is up-to-date | +20 |
| CMS is outdated AND vulnerable | −50 |
| CMS component is up-to-date / vulnerable | +15 / −30 |
| JS component is up-to-date / vulnerable | +10 / −30 |
| Content-Security-Policy header is present / missing | +20 / −20 |
CSP default-src is 'none' or 'self' | +5 |
CSP contains wildcard in default-src | −10 |
| Strict-Transport-Security is valid and enforced (HTTPS) | +25 |
| Strict-Transport-Security is missing (HTTPS) | −20 |
| X-Frame-Options is valid | +15 |
| X-Content-Type-Options is valid / missing | +15 / −10 |
| Permissions-Policy is valid | +15 |
Server / X-Powered-By header reveals software version | −5 |
Server supports TRACE/TRACK/CONNECT methods | −10 |
Cookie with Secure / SameSite=Strict flag | +5 / +5 |
Cookie lacks HttpOnly flag | −5 |
| Web server directory listing is enabled | −10 |
Important characteristic: Unlike the Privacy Test, the Security Test uses category caps and hard gates. The total points awarded or deducted for CMS cannot exceed ±50, for JS components ±20, for HTTP methods and CSP ±30, and for cookies ±10. Furthermore, there are several rules where a single element caps the grade: with vulnerable software, the site cannot receive better than a "C", with an outdated CMS no better than a "B+", and if the site loads content from a source suspected of distributing malware, the score instantly drops to zero. This stands in sharp contrast to the Privacy Test's cumulative, proportional logic, where there is no single factor that causes an outright failure.
4. How do websites generally perform?
The market picture is disappointing: the adoption of basic web security protections is still surprisingly low, while vulnerable software remains the primary entry point for compromised sites.
- According to the HTTP Archive Web Almanac's 2025 survey, Content Security Policy – the most important defense against XSS – is used by only about 21.9% of websites (compared to 18.5% in 2024). In other words, roughly four out of five sites have no CSP whatsoever.
- According to a 2024 study analyzing 3,195 popular websites (Kishnani & Das, using the Mozilla Observatory methodology), the average security header score of the examined sites was a mere 26 out of 100, and nearly one-third of the sites (32.7%) had absolutely no security headers at all.
- HSTS (forcing HTTPS) is configured on only about a quarter of all websites according to Web Almanac data – even though without it, the user is vulnerable to downgrade and man-in-the-middle attacks.
- Vulnerable software is the leading cause of hacks. According to Sucuri's 2023 Hacked Website Report, 39.1% of CMS installations on infected sites were outdated at the moment of infection. Patchstack's 2026 report registered over 11,000 new WordPress vulnerabilities in 2025, 91% of which were in plugins – and nearly half of them had no patch available at the time of disclosure.
These data clearly show that an A+ Security Test result is not merely a matter of technical configuration, but the consequence of a fundamentally different engineering mindset: the conscious, security-focused consideration of every external dependency, every software component, and every HTTP header. An A+ on this test is rare – it is typically achieved only by those who built their site on the principle of minimal attack surface from the start.
5. What does our A+ rating mean?
The A+ result verifies that our site meets the strictest security expectations in every measurable dimension of the attack surface visible from the browser. Specifically, it signifies the following:
- Full HTTP security header set: HSTS is set for one year (
max-age=31536000) withincludeSubDomainsandpreloadoptions; X-Frame-Options isDENY; X-Content-Type-Options isnosniff; Permissions-Policy strictly locks down camera, microphone, geolocation, payment, and USB access; Referrer-Policy isno-referrer; and supplementary headers (X-Permitted-Cross-Domain-Policies, Cross-Origin-Resource-Policy, Cross-Origin-Opener-Policy) are also properly configured. - Strict, enforced Content Security Policy: the site uses a
default-src 'none'based CSP built on a narrow allowlist, which by default permits scripts, styles, and resources exclusively from its own origin ('self'), and setsobject-srcandframe-ancestorsto'none'. - No vulnerable or outdated software: the test did not identify a single CMS or third-party software component on the site. Because we do not operate a CMS, this entire attack surface – which otherwise carries the largest penalty points – is absent by design.
- No cookies: the site does not send a single cookie, so cookie-based security risks do not even arise.
- No external content: the site does not load resources from external domains, meaning there is no SRI or third-party risk.
- No information leakage: the server does not reveal its software version (
Serversignature: N/A, noX-Powered-By), complicating the preparation of targeted attacks. - Only secure HTTP methods: exclusively
GET,HEAD, andOPTIONSare allowed; risky methods likeTRACE/TRACK/CONNECTare not. - WAF protection: a custom Web Application Firewall operates in front of the site, which the test also approved regarding PCI DSS requirement 6.4.
- Fully validated DNSSEC: the domain's DNS data is protected against DNS spoofing with a cryptographic signature (ECDSAP256SHA256).
- Clean GDPR and PCI DSS compliance: the test found no obvious compliance issues related to either GDPR or PCI DSS.
- Active protection against AI data scraping: the server rejects several aggressive crawlers (including the training bots of multiple large AI companies) with server-side, User-Agent-based blocking, returning a 403 response.
At the time of the test (June 12, 2026, 15:57 GMT+0), ImmuniWeb localized our server to Germany (IP: 178.105.168.4, reverse DNS: ...clients.your-server.de), which is consistent with our Hetzner VPS placement in Nuremberg. (The city-level accuracy of GeoIP databases for hosting IPs is notoriously unreliable – the robust, verifiable fact is that processing takes place within the EU, in Germany, on Hetzner's infrastructure, which is a fundamental pillar of GDPR compliance.)
6. Why is this rating special alongside the others?
Our five achieved ratings – MDN Observatory's 130/100 A+, Qualys SSL Labs' A+, Internet.nl's 100%, ImmuniWeb Privacy Test's A+, and the ImmuniWeb Security Test's A+ – cover complementary, distinct dimensions. None replaces the other:
- MDN Observatory: measures the configuration of the server's HTTP response headers – what the server tells the browser about how to behave.
- SSL Labs: measures the cryptographic quality of TLS encryption – how strong and modern the data channel is.
- Internet.nl: measures the infrastructure as a whole – IPv6, DNSSEC, DANE, RPKI, i.e., the entire layer stack of the server's internet connection.
- ImmuniWeb Privacy Test: measures what leaks from the user's browser to third parties – tracking pixels, third-party cookies, external resources.
- ImmuniWeb Security Test: measures how resilient the site itself is to attacks – vulnerable software, HTTP headers, CSP, cookie security, WAF, DNSSEC, compliance, and scraping protection combined.
For the sake of honesty, it is worth noting that the Security Test's header check partially overlaps with the MDN Observatory – both look at HTTP security headers. However, the Security Test goes much further: beyond the headers, it integrates software vulnerabilities, deep CSP analysis, cookie security, WAF presence, DNSSEC, GDPR/PCI DSS compliance, and AI bot protection into a single, coherent picture. Thus, the two results do not repeat, but rather reinforce and complement each other.
There is, however, one attribute that makes all five ratings particularly valuable, and which deserves special emphasis: these results can be independently verified by anyone, at any time. These are not internal, self-proclaimed statements, but results that anyone can re-run on the respective test's public website (observatory.mozilla.org, ssllabs.com, internet.nl, immuniweb.com) and see with their own eyes. Moreover, our Security Test report provides a permanent, public link to the result. This verifiability is what distinguishes meaningful engineering security from mere marketing promises.
7. The limitations of the Website Security Test
For the sake of objectivity, it is important to point out that the Website Security Test is an automated, one-time snapshot that has its own limitations:
- Static, non-invasive analysis: the test passively examines the homepage and the resources directly connected to it. It does not replace a real penetration test – as ImmuniWeb itself emphasizes, meaningful penetration testing is what their enterprise (AI Platform) products are for. The Community Edition is a solid baseline assessment, not a deep security audit.
- Does not examine post-login content or business logic: authenticated interfaces, dynamically loaded elements, and internal logic flaws of the application fall outside its scope.
- Does not examine back-end data processing: it only sees what is visible from the browser. The handling of data stored on the server, the log retention period, and data processing agreements with third parties cannot be measured automatically.
- Snapshot: the result reflects the configuration valid at that specific point in time; continuous security requires regular re-runs and monitoring.
It is worth adding: even with an A+ result, the test provides fine-tuning suggestions – for example, our report suggests at an informational level adding an experimental directive (require-trusted-types-for, i.e., Trusted Types) to the CSP to further narrow DOM-based XSS attacks. This is not a failure, but rather demonstrates the depth of the test and the potential for continuous improvement. An A+ does not mean "there is nothing more to do", but rather that the technical implementation operates with the smallest possible attack surface.
8. Summary
The ImmuniWeb® Website Security Test is one of the most reliable, freely available tools for measuring the actual security posture of a website: it dynamically analyzes software vulnerabilities, HTTP security headers, Content Security Policy, cookie security, WAF presence, DNSSEC, and compliance.
Our A+ rating – achieved on the test run on June 12, 2026, for our site hosted in Nuremberg (Hetzner, Germany) – verifies that:
- there is not a single vulnerable or outdated software component on the site (and no CMS to provide an attack surface);
- a full HTTP security header set and a strict, enforced CSP protect users against XSS, clickjacking, and downgrade attacks;
- the site does not leak information about its software versions, and only allows secure HTTP methods;
- the infrastructure is protected by a WAF and fully validated DNSSEC;
- data processing takes place exclusively on infrastructure within the EU, in Germany;
- and the site actively protects against AI data scraping.
Our five achieved ratings together – MDN Observatory, Qualys SSL Labs, Internet.nl, ImmuniWeb Privacy Test, and ImmuniWeb Security Test – provide the most comprehensive, independent, and publicly verifiable technical proof available that our website and infrastructure meet the strictest security and privacy expectations in every measurable dimension.
Source: ImmuniWeb® Community Edition – immuniweb.com/websec · Scoring methodology: immuniweb.com/websec/scoring
Test date: June 12, 2026, 15:57 GMT+0 · Grade: A+ · Server IP: 178.105.168.4 · Location: Germany (Hetzner, Nuremberg)