A green padlock in the address bar doesn’t guarantee much. Free SSL certificates can be obtained by any site, including phishing pages. Checking the security of a website requires going beyond this simple visual indicator, examining layers that neither the browser nor the average user sees.
API Security: The Blind Spot of a Website Audit
You visit a web page, you see text, images, a form. Behind the scenes, this page often queries multiple APIs to retrieve or send data. These programmatic interfaces have become a primary target for attackers.
Reports from 2024 confirm that attacks targeting APIs represent a growing share of incidents on web applications. The problem: most traditional checks are limited to visible pages. API endpoints, on the other hand, remain in the shadows.
An effective audit begins with a comprehensive inventory of these endpoints. Some were created for a one-time need and then forgotten. Others are documented incompletely. It is precisely these that pose problems because no one thinks to check their authentication or permissions.
Specifically, each API entry point must be tested individually. It is verified that authentication works object by object (user A should not be able to access user B’s data), that rate limits are in place, and that deprecated APIs have been properly removed. Several tools allow for the automation of part of this website security verification, but manual review remains necessary for authorization checks.
Prioritizing Vulnerabilities: Why the CVSS Score Is Not Enough
When a scanner returns a list of vulnerabilities, each is accompanied by a severity score (CVSS). The temptation is to address the highest scores first. This approach seems logical, but it misses a crucial piece of data: attackers primarily exploit known and documented vulnerabilities, not necessarily the most sophisticated ones.
The CISA maintains a catalog called Known Exploited Vulnerabilities (KEV). It lists vulnerabilities that are actively exploited in the wild. A vulnerability with a medium CVSS score but present in this catalog deserves immediate correction. Conversely, a theoretical vulnerability rated very high but never exploited can wait.
For a truly useful verification, cross-reference three criteria:
- The technical severity given by the CVSS score, which measures the potential damage of the vulnerability.
- The presence in the CISA KEV catalog, which indicates whether the vulnerability is actively exploited by attackers.
- The actual exposure of the affected component: a service accessible from the internet is more urgent than an internal tool behind a VPN.
Cross-referencing technical severity, active exploitation, and actual exposure radically changes the order of priority for fixes. Without this sorting, a company can spend weeks on a theoretical vulnerability while an exploited breach remains open.
Open Source Components and AI Models in Security Analysis
The majority of modern websites rely on open source libraries. A CMS, a JavaScript framework, a payment module: each includes third-party code with its own potential vulnerabilities.
Checking these components requires an accurate inventory, often called a Software Bill of Materials (SBOM). This document lists each dependency, its version, and its maintenance status. A component abandoned by its maintainers is a silent risk: no updates will come to fix vulnerabilities discovered after abandonment.
Features incorporating artificial intelligence pose an additional problem. An AI model exposed via an API can be manipulated by queries designed to extract training data or bypass filters. These attack vectors are still poorly covered by traditional scanners.
Checking Server Configuration and HTTP Headers
Even before looking for vulnerabilities in the code, the server configuration often reveals simple issues to fix. HTTP headers, for example, control how the browser interacts with the site.
A well-configured Content-Security-Policy header blocks the majority of XSS attacks. Conversely, some headers that were once recommended are now obsolete. X-XSS-Protection, for example, is no longer useful in modern browsers according to MDN documentation. Copying and pasting a configuration found on a 2018 forum can give a false sense of security.
Points to check on the server side:
- The HTTPS protocol is active with a valid certificate, and HTTP to HTTPS redirections work without loops.
- Sensitive files (backups, configuration files, .git directories) are not publicly accessible.
- Security headers are up to date and tailored to the site’s context, not simply copied from a generic template.
- Server error messages do not disclose technical information (software versions, file paths).
Post-Correction Verification: The Step Most Companies Skip
Detecting a vulnerability, fixing it, moving on to the next one. This cycle seems complete, but it lacks a formal step: confirming that the fix actually works.
Data from 2024 shows that known vulnerabilities remain open for extended periods, even in companies equipped with scanners. The patch was deployed in a test environment but not in production. Or the update was applied, but a vulnerable version of the component is still running on another server.
Post-correction verification must include a new scan focused on the addressed vulnerability, a manual check that the fix has not created a regression (a broken feature, a form that no longer validates inputs), and a control that vulnerable versions have been removed from all exposed environments.
This step transforms an audit report into measurable improvement. Without it, the report remains a PDF document filed away, and the vulnerability remains exploitable.
