Website check
Security
The audit establishes what your server gives away or permits by itself — it exploits none of it. The difference between "the door is open" and "I walk in" is the line this tool does not cross. That is precisely why the scan runs without a maintenance window and without a liability discussion. What this outside view cannot see — updates, backups, accounts, permissions, logs — is covered by the IT review with credentials.
What gets checked
52 individual checks, run together with privacy in a single pass
-
Credentials in shipped code
AWS keys, private keys, live Stripe keys, GitHub and Slack tokens, database passwords — anything that ends up in the frontend by accident. In practice the most common genuine find. Every hit appears masked in the report.
-
Transport encryption
HTTPS reachable, redirection from HTTP, certificate validity and remaining lifetime, outdated TLS versions, mixed content on encrypted pages.
-
Security headers
HSTS, Content-Security-Policy including an assessment of unsafe-inline and report-only mode, X-Content-Type-Options, Referrer-Policy, clickjacking protection, Permissions-Policy — plus the Secure, HttpOnly and SameSite cookie attributes.
-
CORS misconfiguration
If the server reflects any requesting origin and allows credentials at the same time, any foreign page can read a logged-in visitor’s data from inside their browser. One line of configuration, large consequences.
-
Error pages with stack traces
Detected by requesting a made-up path: Python, PHP, Java, .NET, Django, Laravel, Symfony, Rails and Node all reveal paths, versions and program structure in their default configuration.
-
Known vulnerabilities and version disclosure
Detected library versions are matched against OSV.dev and cached locally. Plus version information in headers and the generator tag, outdated JavaScript libraries, and identifiable WordPress plugins.
-
HTTP methods
TRACE enabled, writing methods offered where only reading should be possible.
-
Email and DNS configuration
SPF including an overly lax ~all, DMARC, CAA and DNSSEC. Plus dangling CNAME records as a subdomain takeover risk, and a robots.txt that serves as a signpost to non-public areas.
Only with explicit authorisation in the engagement
These checks request 29 fixed paths — no more, and nothing found is exploited. Because it is active testing, it is named explicitly in the engagement text rather than buried in the small print. Without that authorisation, only what an ordinary visitor triggers is run.
- reachable /.git/ and /.env, /.htpasswd, /.vscode/sftp.json
- database dumps, log files and backup files in the web directory
- /phpinfo.php and comparable diagnostic pages
- WordPress user list, exposed database administration (phpMyAdmin, Adminer)
- directory listing
Standards and references
- OSV.dev as the source for vulnerabilities in detected library versions
- Security headers and TLS configuration compared against current common practice
- A weighted risk score — explicitly not CVSS. It is useful for comparing runs of the same domain, not as an absolute statement
What the report contains
Each run produces two files: a self-contained HTML report for you and a JSON file as a machine-readable basis. The HTML report loads not a single resource from a foreign server — a privacy report that fetches fonts when you open it would be hard to explain. Every finding names the location, the evidence and a concrete fix.
Where the audit reaches its limit
The homepage is what gets audited. Areas behind a login are invisible to the tool. And this is not a penetration test: no fuzzing, no injected input, no login attempts, no load testing, no exploitation of what is found. That needs its own contract with its own liability terms. What the run finds is solid; what it does not find is not an acquittal.
Frequently asked questions
What prospective clients most often want to know before commissioning an audit.
Is an automated security audit the same as a penetration test?
No. An automated audit is rule-based and repeatable: it reliably finds known vulnerabilities, misconfigurations and outdated components, and it can do so daily. A penetration test is the manual work of a human who finds logic flaws, authorisation problems and chained attacks no rule set would reach. The two complement each other: automation keeps the baseline clean so the penetration test does not spend its time on the obvious.
Do you need credentials, or do we have to install software?
No. The audit runs from the outside against the publicly reachable page — the domain and a signed authorisation are enough. No agent on your servers, no access to your source code, no credentials. The flip side is stated plainly in the report: what sits behind a login is invisible to the tool as well.
Will the audit disrupt live operations?
No. The audit reads and measures, it does not attack: no exploits are executed, no load testing, no writing access. The request rate is throttled and can be tuned to your environment, and a run can be placed in a time window. If your protection system blocks the scanner anyway, that too is a usable result — the scanner source is then allowlisted so the run measures the application rather than the firewall.
How often should a security audit run?
As often as the site changes. A certificate expires, a library picks up a new vulnerability, a deployment resets a header — all of that happens between two annual audits. In practice a monthly run works well as a baseline, plus a run after every major release. Automatic comparison between two runs is in progress; today we establish what changed when reading the reports.
What drives the effort?
Scope, and which of the three profiles you need. Security and privacy run together; discoverability and accessibility each run on their own, and the extended accessibility level needs four browser passes instead of one. Add the number of domains. The effort sits in the setup and in reading the reports, not in the compute — which is exactly why regular auditing is economically viable at all.