Short answer. A website security check is a layered audit: HTTPS and the certificate, security headers, Content-Security-Policy, cookie flags, malware and blacklists, open ports, and leaked files. A quick online check takes about five minutes with free scanners; a full owner's audit using the checklist below takes an hour or two. This guide walks through both scenarios step by step.
What a Website Security Check Covers
Website security is not a single score but a stack of independent layers, and each one fails on its own. A site with a flawless certificate can still serve injected scripts, and a site that looks clean to every antivirus engine can still hand out session cookies without protective flags. A meaningful check therefore walks through every layer:
- HTTPS and TLS — traffic encryption, certificate validity, modern protocol versions only.
- Security headers — HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy.
- Content-Security-Policy — the browser-side barrier against XSS and rogue third-party scripts.
- Cookies — HttpOnly, Secure and SameSite flags on everything session-related.
- Malware — injected code, hidden redirects, presence on search-engine blacklists.
- Ports and services — only 80 and 443 should face the internet, never databases or admin panels.
- Leaks — exposed .git directories, .env files, database dumps and backups sitting inside the web root.
The first five layers can be tested online in minutes. Ports and leaks require server access or careful, strictly passive manual probing.
Online Website Security Check in 5 Minutes
A quick audit of any site — your own, or one you are about to integrate with — takes five browser-based tools. No installation, no registration, no agent on the server.
- Run the security scanner at /security. It checks security headers, the HTTPS redirect and cookie flags, then assigns an overall grade from A to F. Start here: the grade instantly shows which layer is weakest and what to fix first.
- Check the certificate at /ssl. Expiry date, chain completeness, supported TLS versions. An expired or self-signed certificate is a hard stop for any site that handles logins or payments.
- Analyze the policy at /csp. The analyzer breaks Content-Security-Policy down directive by directive and highlights permissive sources that quietly undermine the whole policy.
- Inspect cookies at /cookie. See every cookie the site sets and whether HttpOnly, Secure and SameSite are actually in place.
- Scan for malware at /malware. Injected scripts, hidden redirects and blacklist status in a single pass.
If you want a second opinion from third-party tools, see our comparison of the best website security scanners.
Start with the full scanner rather than individual checks: the A–F grade immediately points to the weakest layer and saves you from diagnosing in the dark.
The Site Owner's Checklist
Online tools cover what is visible from the outside. As the owner, you need to go deeper — through the eight blocks below. Each one takes minutes to verify and closes a class of real-world attacks.
HTTPS and the Certificate
All traffic over HTTPS with an automatic redirect from HTTP. The certificate is valid, the chain is complete, and renewal is automated: Let's Encrypt certificates rotate every 60–90 days, so a broken renewal job means downtime and browser warnings. Legacy TLS 1.0 and 1.1 are disabled. Verify everything at /ssl.
Security Headers
The minimum set: Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options and Referrer-Policy. A quick terminal check:
curl -I https://example.com
A healthy response looks like this:
strict-transport-security: max-age=31536000; includeSubDomains x-content-type-options: nosniff x-frame-options: DENY referrer-policy: strict-origin-when-cross-origin content-security-policy: default-src 'self'; frame-ancestors 'none'
What each header does and how to enable it on nginx, Apache or inside your CMS is covered in the complete guide to security headers.
Content-Security-Policy
CSP is the main browser-side defense against XSS: the browser only executes scripts from sources you explicitly allow. Avoid unsafe-inline in script-src, list trusted domains explicitly, and add frame-ancestors to block clickjacking. Test your policy at /csp — the analyzer flags dangerous directives and explains why each one matters.
Cookies
Session cookies need three flags: HttpOnly (unreachable from JavaScript, which neutralizes most XSS-based session theft), Secure (sent over HTTPS only) and SameSite=Lax or Strict (CSRF protection). Audit every cookie your site sets at /cookie.
CMS and Plugin Updates
Most real-world compromises come through known vulnerabilities in outdated plugins and themes, not through exotic zero-days. Update the CMS core and extensions at least monthly, subscribe to security advisories for your stack, and fully delete unused plugins — deactivated code is still attackable code.
Passwords and 2FA
Unique passwords of 12+ characters for the admin panel, hosting account, database and FTP; a password manager instead of reuse. Two-factor authentication everywhere it is supported. Review accounts regularly: former contractors and old test users should have no access left.
Backups
Automatic copies of files and the database — daily at minimum, stored off the web server so ransomware or a disk failure cannot take the backups down with the site. Test a restore quarterly: a backup that has never been restored is a lottery ticket, not a safety net.
Logs and Monitoring
Enable access and error logs, and alert on 5xx spikes, login brute-force attempts and unexpected file changes. The earlier an anomaly becomes visible, the cheaper the incident is to contain.
How to Check Someone Else's Site Before Paying or Entering Data
Before typing card details or personal data into an unfamiliar store or service: check the domain age and HTTPS, run the address through /security and /malware, and look for a verifiable company behind the site. A domain registered weeks ago, no HTTPS on the payment form and an F grade are all reasons to close the tab. Detailed step-by-step methods are in our guides on checking a website for fraud and checking a website for malware.
Summary Table: Layer → What to Check → Tool
| Layer | What to check | Tool | Criticality |
|---|---|---|---|
| HTTPS / TLS | Certificate, chain, protocol versions | /ssl | Critical |
| Security headers | HSTS, nosniff, X-Frame-Options | /security | High |
| CSP | Directives, unsafe-inline, sources | /csp | High |
| Cookies | HttpOnly, Secure, SameSite | /cookie | High |
| Malware | Injected code, redirects, blacklists | /malware | Critical |
| CMS and plugins | Versions, known vulnerabilities | CMS dashboard | Critical |
| File leaks | .git, .env, backups in web root | Manual, curl | Critical |
| Access | Passwords, 2FA, stale accounts | Manual review | High |
Personal Data and GDPR
If your site collects even a name and an email through a form, privacy regulation applies. Under GDPR you need a lawful basis for processing, a clear privacy policy, explicit consent for marketing cookies and a way for users to request deletion of their data. Security and compliance overlap heavily: encrypted transport, restricted access and audit logs are requirements in both worlds, so most items in this checklist double as compliance groundwork.
Make it a calendar rule: after any CMS update, plugin install or web-server configuration change, re-run the scanner. Most security regressions appear right after "harmless" changes.
FAQ
How is a security check different from a malware check?
A malware check looks for an infection that has already happened: injected scripts, redirects, blacklist entries. A security check is broader — it measures how well the site is protected: certificate, headers, CSP, cookies, in other words the probability of a future breach. A site that is perfectly clean by antivirus standards can still score an F.
How often should I check my website's security?
At least monthly, and after every change: a CMS update, a new plugin, a web-server configuration edit. For sites that accept payments or store personal data — weekly, or continuous automated monitoring.
What does the A–F grade mean?
It is the overall score from the /security scanner: A means all key headers, HTTPS and cookie flags are in place; F means critical protection mechanisms are missing. The grade works well as a progress metric — fix the headers, watch the score climb.
Is it legal to check someone else's website?
Passive checks — reading headers, the certificate and public cookies — are legal: it is the same information a browser receives on a normal visit. Active actions without the owner's permission are not: vulnerability scanning, password guessing, exploiting anything you find.
The scanner found problems — what do I fix first?
Prioritize by risk: malware and leaked files first, since damage is already happening; then HTTPS and the certificate; then session cookie flags; headers and CSP last. Re-run the scanner after every fix to confirm the change landed.
Final Checklist
- HTTPS is enforced on every page and the HTTP redirect works.
- The certificate is valid, the chain is complete, renewal is automated.
- Security headers are set: HSTS, nosniff, X-Frame-Options, Referrer-Policy.
- CSP is configured with no unsafe-inline in script-src.
- Session cookies carry HttpOnly, Secure and SameSite.
- The malware scan is clean and the site is on no blacklist.
- CMS, plugins and themes are updated, unused ones deleted.
- Passwords are unique, 2FA is enabled, access has been reviewed.
- Backups run automatically, live off-server, restore is tested.
- Logs are enabled and anomaly alerts are configured.
A one-off check captures today's state only, and regressions arrive with every update — which is why it is simpler to put the site on automated security monitoring with alerts: see plans at /pricing.