Skip to content
Emergency helpGet started
CHECKLIST

Website security checklist

A website security check should answer a practical question: can attackers, browsers, search crawlers, or casual visitors see something your team did not intend to expose? This scanner covers the public-facing controls that often decide whether a site earns user trust or becomes an easy target.

TLS and SSL

Confirms the site serves HTTPS, redirects plain HTTP, and has a current certificate that covers the hostname.

  • HTTPS availability
  • Certificate expiry and hostname coverage
  • HTTP-to-HTTPS redirect
  • Mixed content and insecure form actions

Security headers

Reviews browser-enforced protections that reduce XSS, clickjacking, MIME sniffing, and downgrade risks.

  • Content-Security-Policy
  • Strict-Transport-Security
  • X-Frame-Options
  • Permissions-Policy

Exposure checks

Looks for public files and metadata that commonly reveal credentials, source control data, deployment details, or sensitive paths.

  • .env and backup files
  • Source control paths
  • Directory listings
  • robots.txt disclosures

Server configuration

Flags unnecessary technology disclosure and server behavior that makes targeting or exploitation easier.

  • Server header leakage
  • Error-page disclosure
  • CORS posture
  • Risky HTTP methods

Common vulnerability signals

Uses non-destructive public checks and framework-specific probes to identify obvious known-risk patterns without modifying the site.

  • Open redirect indicators
  • React Server Components (React2Shell) signals
  • Exposed debug endpoints
  • Admin panel exposure

Operational best practices

Checks the public basics that support responsible disclosure, third-party script integrity, and session safety.

  • security.txt
  • Subresource Integrity on CDN resources
  • Secure, HttpOnly and SameSite cookie flags

How the website security scan works

The scan fetches the URL you submit, then runs 27 checks against that response and a fixed list of well-known paths on the same host. Most checks send GET, HEAD or OPTIONS requests; the React2Shell check sends POST detection requests with a harmless payload. Certificate details come from public Certificate Transparency logs.

Encryption

  1. Certificate validity, expiry and hostname coverage
  2. HTTP-to-HTTPS redirect
  3. Mixed content on HTTPS pages
  4. Secure, HttpOnly and SameSite flags on session cookies
  5. Forms that submit to HTTP URLs

Browser security headers

  1. Strict-Transport-Security max-age, includeSubDomains and preload
  2. Content-Security-Policy without unsafe-inline, unsafe-eval or wildcards
  3. Clickjacking protection (X-Frame-Options or frame-ancestors)
  4. X-Content-Type-Options: nosniff
  5. Referrer-Policy
  6. Permissions-Policy
  7. CORS wildcard and null origins

Information exposure

  1. .env, configuration, database dump and dependency files
  2. Backup copies (.bak, .old, .orig, .swp and similar)
  3. Public JavaScript source maps
  4. Git, SVN, Mercurial and Bazaar metadata
  5. Server and technology version disclosure
  6. Sensitive paths listed in robots.txt

Server configuration

  1. Directory listing
  2. Reachable admin and login panels
  3. Debug, status and metrics endpoints
  4. TRACE, PUT and DELETE methods

Known vulnerability signals

  1. React Server Components (React2Shell) response signals
  2. Open redirects through common redirect parameters
  3. Stack traces and framework details on error pages

Security practices

  1. security.txt with Contact and Expires fields
  2. Subresource Integrity on CDN scripts and stylesheets

How the grade is calculated

Scoring starts at 100. A failed check deducts 25, 15, 10 or 5 points for critical, high, medium or low severity, and a warning deducts 15, 10, 5 or 2. Checks that could not complete and informational findings do not change the score. A+ is 90 or more, A is 80-89, B is 65-79, C is 50-64, D is 35-49 and F is below 35.

What this scan does not check

A clean result means these public checks passed at scan time. It is not a full security assessment, so plan separate testing for the areas below.

  • Authenticated pages, logged-in user 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 the Email Security check covers

What each result means

The A-F grade summarizes the overall public posture, but the individual check status matters more than the letter. Prioritize critical and high-severity failures first, then work through warnings that weaken browser-side protections.

Pass

The control is present or configured in a way that meets the scanner baseline.

Warning

The control exists but is incomplete, weak, overly permissive, or missing context needed for a clean pass.

Fail

The scanner found a missing or risky control that should be fixed before relying on the site for sensitive workflows.

Error

The check could not be completed reliably, usually because the target blocked the request, timed out, or returned an unexpected response.

Common vulnerabilities this catches

Most website security failures are not exotic. They are exposed files, weak browser policy, missing transport guarantees, or configuration defaults that were never revisited after launch.

Missing HSTS

Risk: Browsers may allow downgrade attacks or accidental HTTP access after a user has visited the site.

Next step: Serve all traffic over HTTPS first, then enable a long HSTS max-age with includeSubDomains when subdomains are ready.

Weak or absent Content-Security-Policy

Risk: Injected scripts have more room to execute if an XSS bug appears in the application.

Next step: Start with report-only CSP, remove unsafe inline script usage where practical, then enforce a tight production policy.

Clickjacking exposure

Risk: Attackers may be able to frame sensitive pages and trick users into taking unintended actions.

Next step: Use frame-ancestors in CSP or X-Frame-Options on pages that should never be embedded.

Exposed environment or backup files

Risk: Public configuration files can leak credentials, internal URLs, API keys, or deployment details.

Next step: Remove exposed files, rotate any leaked secrets, and block sensitive extensions and dotfiles at the edge.

Next steps after the check

If this is more than a missing header, the next step is an operator, not another scan. Connect your security tools to the Vigilbase Platform, or talk to us about Managed Cloudflare.

Get started with the Vigilbase Platform

Connect the security tools you already pay for to the cybersecurity operating system, and have the Vigil agent investigate what matters.

Open resource

Talk to us about Managed Cloudflare

If this is more than a missing header, the next step is an operator, not another scan.

Open resource

Website security check FAQ

What does the website security check test?

It checks TLS and SSL configuration, common HTTP security headers, HSTS, CSP, mixed-content risk, exposed files, server information leakage, robots.txt disclosures, and several public vulnerability signals.Results cover the public URL and signals observed during the scan. They do not cover every authenticated route, internal service or business-logic risk.HTTP Security Headers CheckerA practical website protection guide

Is the scan safe to run on a production website?

Yes, when you are authorized to test the target. The public check is non-destructive, but the verified vulnerability flow may send framework-specific probe requests, including React and Next.js probes, to confirm exposure. It does not brute force logins or modify the target website.Agree the target, permitted testing and timing with the owner first. Non-destructive probing can still reach production application code and should be considered in your testing plan.Tool access and verification requirementsReact2Shell exposure check

Why do I need to verify my email before scanning?

Verification helps prevent abuse and confirms access to the email address used for the request. It does not prove ownership of the target or permission to test it.Only submit systems you own or are explicitly authorized to test. Do not treat a completed email check as permission from a third-party system owner.Tool access and verification requirementsPrivacy and data handling

What is a good website security grade?

A or A+ means the checks scored well against this tool’s public-facing baseline at the time of the scan. Lower grades highlight findings to review and prioritize; no grade proves that the application is secure.Review the individual findings, confirm whether they apply to your deployment, and verify remediation against important user journeys. A rerun can confirm the tested change without certifying the whole application.A practical website protection guideManaged WAF operations and change control

How is the website security grade calculated?

Scoring starts at 100. Each failed check deducts 25, 15, 10 or 5 points for critical, high, medium or low severity, and each warning deducts 15, 10, 5 or 2. A score of 90 or more is an A+, 80 an A, 65 a B, 50 a C and 35 a D; anything lower is an F.Checks that could not complete and informational findings do not change the score. Fix critical and high-severity failures first, because they move the grade most.A practical website protection guideHTTP Security Headers Checker

Can this replace a penetration test?

No. This check is a fast public-facing posture review. It is useful for finding common configuration issues, but deeper application logic, authentication, and business-process risks still need expert testing.A practical website protection guideDiscuss your scope with Vigilbase
OWASP Web Security Testing Guide