# Website Security

> Run the 27-point Website Security scan on a site you own, verify your email first, and read how the A+ to F grade is calculated.

Source: https://docs.vigilbase.com/tools/website-security

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](https://vigilbase.com/tools/website-security).

> [!WARNING]
> The scan sends active requests to the site, including POST detection requests for the React2Shell check. It does not brute force logins or change the site, but it does reach production application code. Only scan sites you own or are explicitly allowed to test, and agree the timing with the owner.

## 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

:::steps
1. **Enter the URL and your work email.** Use an email address on the site's domain.
2. **Complete the security check** and send the request. Vigilbase emails you a 6-digit code.
3. **Enter the code.** The scan starts and shows its progress.
4. **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](https://docs.vigilbase.com/tools/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

:::accordion
### 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](https://docs.vigilbase.com/tools/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](https://docs.vigilbase.com/tools/csp).

### 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](https://docs.vigilbase.com/tools/developers/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](https://docs.vigilbase.com/tools/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:

```bash
vigilbase login
vigilbase run website-security example.com
```

It is not available on the anonymous [Agent API](https://docs.vigilbase.com/tools/developers/agent-api).