Website Security is a 27-point scan of a live site you own or may test. It checks TLS and certificates, security headers, exposed files, server information leaks and public vulnerability signals, and gives an A+ to F grade with a fix for each finding. Run it at vigilbase.com/tools/website-security.
Why you verify your email first
Because the scan is intrusive, you must verify a work email before it runs. The email domain must match the site: to scan app.example.com or example.com, use an address at example.com. Personal and free mailbox providers are refused.
Verification limits abuse and confirms you can read that mailbox. It does not prove you own the site or have permission to test it.
Run a scan
Enter the URL and your work email. Use an email address on the site's domain.
Complete the security check and send the request. Vigilbase emails you a 6-digit code.
Enter the code. The scan starts and shows its progress.
Read the result. It is also emailed to you with a link to the saved run at
https://vigilbase.com/tools/run/<id>.
What it checks
The scan fetches the URL you submit, then runs its checks against that response and a fixed list of well-known paths on the same host. Certificate details come from public Certificate Transparency logs.
| Group | Checks |
|---|---|
| Encryption | Certificate validity, expiry and hostname coverage; HTTP-to-HTTPS redirect; mixed content on HTTPS pages; Secure, HttpOnly and SameSite flags on session cookies; forms that submit to HTTP URLs |
| Browser security headers | Strict-Transport-Security max-age, includeSubDomains and preload; Content-Security-Policy without unsafe-inline, unsafe-eval or wildcards; clickjacking protection (X-Frame-Options or frame-ancestors); X-Content-Type-Options: nosniff; Referrer-Policy; Permissions-Policy; CORS wildcard and null origins |
| Information exposure | .env, configuration, database dump and dependency files; backup copies (.bak, .old, .orig, .swp and similar); public JavaScript source maps; Git, SVN, Mercurial and Bazaar metadata; server and technology version disclosure; sensitive paths listed in robots.txt |
| Server configuration | Directory listing; reachable admin and login panels; debug, status and metrics endpoints; TRACE, PUT and DELETE methods |
| Known vulnerability signals | React Server Components (React2Shell) response signals; open redirects through common redirect parameters; stack traces and framework details on error pages |
| Security practices | security.txt with Contact and Expires fields; Subresource Integrity on CDN scripts and stylesheets |
How the grade is calculated
Scoring starts at 100. Each check that fails or warns deducts points by severity:
| Severity | Failed check | Warning |
|---|---|---|
| Critical | 25 | 15 |
| High | 15 | 10 |
| Medium | 10 | 5 |
| Low | 5 | 2 |
Checks that could not complete and informational findings do not change the score.
| Grade | Score |
|---|---|
| A+ | 90 or more |
| A | 80-89 |
| B | 65-79 |
| C | 50-64 |
| D | 35-49 |
| F | Below 35 |
The status is Vulnerable when a critical check fails or the grade is F. It is Warnings when a high-severity check fails, the grade is C or D, or any check did not finish: a check that did not finish might have failed, so the scan never reports Secure in that case.
What each result means
| Result | Meaning |
|---|---|
| Pass | The control is present or configured in a way that meets the scanner's baseline. |
| Warning | The control exists but is incomplete, weak or too permissive. |
| Fail | A control is missing or risky and should be fixed. |
| Error | The check could not complete reliably, usually because the target blocked the request, timed out or returned an unexpected response. |
Fix critical and high-severity failures first, because they move the grade most.
Fix common findings
Missing HSTS
Serve all traffic over HTTPS first, then send Strict-Transport-Security with a long max-age (at least 31536000) and includeSubDomains once every subdomain serves HTTPS. Check it with the HSTS checker.
Weak or missing Content-Security-Policy
Start with a Content-Security-Policy-Report-Only policy, remove inline scripts where you can, then enforce a strict policy. Build one with the CSP generator.
Clickjacking exposure
Add frame-ancestors to your CSP, or X-Frame-Options: DENY or SAMEORIGIN, on pages that should never be embedded.
Exposed environment or backup files
Remove the files, rotate any secrets they contained, and block dotfiles and backup extensions at the web server or edge.
Version disclosure
Remove or shorten Server and X-Powered-By headers so they do not reveal software versions.
Show your grade with a badge
After a successful scan, the result offers a badge you can add to your site. It shows the grade of the latest verified Website Security scan for the domain. See Security badges.
What the scan does not check
A clean result means these public checks passed at scan time. It does not cover:
- authenticated pages, logged-in journeys and business logic;
- pages beyond the submitted URL and the fixed list of well-known paths;
- TLS protocol versions and cipher suites;
- installed software versions against vulnerability databases, apart from the React2Shell signals;
- injection, brute-force or denial-of-service testing;
- malware, blocklist and reputation status;
- DNS and email authentication records, which Email security covers.
It is not a replacement for a penetration test.
From the CLI
Website Security runs through Vigilbase One, so the CLI needs a sign-in:
vigilbase login
vigilbase run website-security example.com
It is not available on the anonymous Agent API.