An SSL scan and a Google Safe Browsing check only cover a fraction of a website’s actual attack surface. We regularly observe sites displaying an A+ score on their HTTP headers while dropping trackers before consent or exposing shared accounts without traceability. To test the security of a website in a truly useful way, it is necessary to go beyond simple technical diagnostics and integrate regulatory compliance, cookie management, and authentication policies.
Cookie and Tracker Compliance: The Test Scanners Ignore
The majority of free security analysis tools focus on the TLS certificate, HTTP headers, and the potential presence of the domain on a blacklist. None of them check the actual behavior of the cookie consent banner.
This is a costly blind spot. The CNIL continued its sanctions in 2025 against sites that drop trackers before consent, do not allow a refusal as simple as acceptance, or continue to read cookies after consent withdrawal. We recommend conducting a three-step test after each production deployment:
- Load the page in private browsing and capture network requests before any interaction with the banner. Any third-party cookie dropped at this stage constitutes non-compliance.
- Refuse trackers, continue browsing multiple pages, and then check via developer tools that the refusal is indeed respected throughout the journey.
- Accept cookies, withdraw consent via the provided link, and check that the reading of trackers actually stops. A test limited to the homepage is not sufficient.
This protocol takes less than ten minutes. Yet it covers a scope that automated scanners do not address, and which represents the primary source of CNIL sanctions on French websites.
Before launching a classic technical audit, it is relevant to test the security of a website by combining vulnerability analysis and tracker behavior verification.
Web Vulnerability Scan: What an Automated Tool Really Detects
An online security scanner (such as HTTP header analysis, SSL/TLS verification, malware detection via Google Safe Browsing) produces a useful but partial diagnosis. These tools identify known vulnerabilities: absence of Content-Security-Policy, outdated TLS version, blacklisted domain.
Logical vulnerabilities remain invisible to automated scanners. Privilege escalation via a poorly controlled URL parameter, a contact form without CSRF protection, or an API exposing user data without authentication do not trigger any alerts in a passive scan.
For an e-commerce site or an application with a client area, we recommend complementing the automated scan with a targeted manual test focused on three points:
- Attempt to access protected resources by manipulating identifiers in the URL (IDOR). If the server returns data without verifying the identity of the requester, the vulnerability is critical.
- Inject test XSS strings into all visible input fields. A form that returns content without HTML escaping exposes visitors to session theft.
- Check response headers on each API endpoint, not just on the homepage. Security policies often vary from one route to another on the same domain.
A scanner report showing a high score guarantees nothing if these manual checks have not been conducted.
Authentication Policy and Shared Accounts: A Penalized Weakness
The CNIL reported in its 2025 review that 14 organizations were sanctioned for insufficient security, particularly due to weak passwords or shared accounts among multiple users. This observation concerns both the back offices of websites and access to databases.
Testing the security of a site without auditing the password policy is like checking the lock while leaving the key under the doormat. We still observe CMSs where the administrator account uses a default password, or marketing teams sharing a unique identifier to access the analytics dashboard.
Each access must be individual and traceable. A serious audit verifies that the site enforces a minimum password length, blocks attempts after a defined number of failures, and logs connections with timestamps and IP addresses. Without these controls, detecting an intrusion becomes impossible afterward.
Tracker Walls and Dark Patterns: A Recent Regulatory Trap
“Cookie walls” (conditional access to acceptance of trackers) constitute a subject that general security guides do not address. The CNIL specifies that such a device is not automatically prohibited, but that consent must remain free, informed, and presented with balanced choices.
In practice, a brightly colored “Accept” button and a light gray “Refuse” link at the bottom of the page do not meet this requirement. A compliance test must evaluate the visual ratio between the options, the ease of navigation towards refusal, and the absence of punitive consequences (redirection, hidden content) in case of non-acceptance.
This control goes beyond the usual technical scope, but it directly relates to online data protection. A technically secure site that exerts disproportionate pressure on its visitors’ consent is exposed to the same sanctions as a poorly secured site.
The security of a website is not limited to a score displayed by a scanner. It is measured across three simultaneous axes: technical robustness, compliance with personal data processing, and the rigor of internal access policies. Neglecting any one of these axes is like leaving a door open, no matter how secure the locks on the other two may be.
