A free scanner that checks the SSL certificate and HTTP headers gives a false impression of coverage. The OWASP Top 10:2025 ranks Security Misconfiguration in second place and introduces Software Supply Chain Failures as a standalone category. Testing the security of a website online requires understanding what these tools actually capture, and especially what they overlook.
Supply Chain and Exceptional Conditions: the Blind Spots of Free Scanners
Most tools available without registration analyze the exposed surface: validity of the TLS certificate, presence of Content-Security-Policy headers, X-Frame-Options, DNS configuration. This is a useful foundation, but it does not cover the software dependency chain or application error handling.
The OWASP Top 10:2025 has formalized these two risks under the categories Software Supply Chain Failures and Mishandling of Exceptional Conditions. A JavaScript component imported via npm, a Docker image built on an unmaintained base, a CI/CD pipeline with exposed secrets: no anonymous external scan detects these flaws.
We recommend treating the online scan as a first filter, not as an audit. It identifies configuration errors visible from the outside. For the software chain, a Software Composition Analysis tool (Snyk Open Source, OWASP Dependency-Check) should be run in the code repository.
Before launching a scan, it is helpful to test the security of a website online by precisely understanding the scope covered by each tool, in order to avoid confusing a clean report with a truly reduced attack surface.
Security Misconfiguration: What HTTP Header Scans Really Detect
The rise of Security Misconfiguration to second place in the OWASP ranking is not anecdotal. It reflects the multiplication of configuration surfaces: public cloud buckets, accessible administration endpoints, verbose error pages that expose stack traces, cookies without Secure or SameSite attributes.
Free scanners cover part of this scope. They typically check:
- The presence and value of HTTP security headers (Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy)
- The TLS configuration (protocol version, cipher suites, certificate expiration)
- The exposure of server information in response headers (Server, X-Powered-By)
- The CORS policy and allowed origins
On the other hand, an external scan does not test internal configurations: IAM rules of an S3 bucket, access to an administration console protected by an obscure URL, or environment variables injected in plain text in client-side source code. These checks require authenticated access or an audit of the deployed code.
Interpreting a Security Score Without Overestimating It
A report displaying a high score (A or A+) on HTTP headers does not mean the application is secure. It means that the transport layer and browser directives are correctly configured. We regularly observe sites rated A+ whose administration panel is accessible via /admin without IP restrictions or two-factor authentication.
The score is an indicator of maturity over a specific scope. It does not cover business logic or application access controls.
Broken Access Control and Authenticated Testing: The Structural Limit of Anonymous Scans
The risk ranked number one by OWASP in 2025 remains Broken Access Control, which now includes SSRF (Server-Side Request Forgery). This type of vulnerability requires test accounts with multiple privilege levels and concrete business scenarios: a standard user attempting to access a resource reserved for an administrator, an API request that modifies an object’s identifier to access another user’s data (IDOR).
No anonymous external scanner can validate access controls without having at least two authenticated sessions with different roles. A tool like OWASP ZAP allows configuring authentication contexts and replaying scenarios, but this goes beyond the scope of a simple online test.
Combined Approach for a Realistic Audit Without Budget
To cover an acceptable scope without financial investment, we recommend combining three layers:
- An HTTP header and TLS configuration scan via a free online tool (Mozilla Observatory, SecurityHeaders.com) for the network and transport perimeter
- A local interception proxy (OWASP ZAP in standard mode) to manually test access controls and form injections, with authenticated sessions
- A dependency analysis (npm audit, pip-audit, OWASP Dependency-Check) directly in the build pipeline to cover the software chain
This combination covers three of the top five risks in the OWASP 2025 ranking. It does not replace a professional pentest, but it significantly raises the detection level compared to a single HTTP header scan.
CORS, Cookies, and Content-Security-Policy: Settings to Check as a Priority
Among the testable elements for free, three configurations concentrate a disproportionate share of exploitable errors.
Misconfigured CORS policy remains common. An Access-Control-Allow-Origin set to * with Access-Control-Allow-Credentials set to true exposes session cookies to any third-party domain. Free scanners flag this combination but do not test the application consequences.
Cookie attributes deserve special attention. A session cookie without Secure, without HttpOnly, and without SameSite=Strict (or Lax) is vulnerable to theft via XSS or inclusion in cross-site requests. Recent browsers mitigate some scenarios, but explicit configuration remains the only reliable server-side protection.
Finally, a permissive Content-Security-Policy nullifies protection against XSS injections. A script-src directive containing ‘unsafe-inline’ or ‘unsafe-eval’ renders the CSP cosmetic. Online scanning tools detect these directives, making it one of the few application controls accessible without authentication.
The free nature of a testing tool is not a problem in itself. What creates a false sense of security is treating the report as exhaustive when it only covers a fraction of the actual attack surface. A clean scan on HTTP headers remains a good starting point, provided it is followed by the layers that the tool cannot reach.
