Tools › Website Security Scanner
Website Security Scanner
Paste any URL for a passive, read-only security scan. It checks HTTPS, transport and TLS certificates, security headers, cookie flags, information disclosure, hardcoded secrets, platform and CMS exposure (WordPress, Joomla, Drupal, Magento), client-side risks, and email/DNS security (SPF, DMARC, CAA), then scores the site out of 100 with a do-this-first fix plan.
What this website security scanner checks
Security is not a single switch. A site can have a valid certificate and still leak its exact software versions, hand out its admin usernames, or ship without a single protective HTTP header. This scanner looks at the whole surface an outsider can see, from one URL, and turns it into a plain-English report with a fix for every finding.
It runs seven weighted checks that add up to a score out of 100:
- HTTPS and transport. Is the site actually served over HTTPS? Does plain
http://redirect up to the secure version, or is it quietly reachable in the clear? Is HSTS set, and for long enough? Are there insecurehttp://assets on a secure page (mixed content) that browsers will block or downgrade? It also reads the TLS certificate itself, is it valid and trusted, how many days until it expires, and does the server still accept deprecated TLS 1.0/1.1. - Security headers. The small set of response headers that stop whole classes of attack, a deeply
graded Content Security Policy (not just present, but whether script-src, object-src and base-uri
are actually locked down), clickjacking protection,
nosniff, a Referrer Policy, a Permissions Policy, and whether CORS is configured safely (an arbitrary Origin reflected back with credentials allowed can leak authenticated responses cross-origin). Most sites are missing several of these, and most are a one-line fix. - Cookies. Every cookie the site sets is checked for the
Secure,HttpOnlyandSameSiteflags, the difference between a session cookie an attacker can steal and one they cannot. - Information disclosure. Version numbers in the
ServerandX-Powered-Byheaders and the meta generator tag are a gift to an attacker, they turn a guess into a lookup. The scanner checks a public.gitrepository and a public.envfile, a sweep for other exposed backup and metadata files, and whether the page publishes a security.txt contact for responsible disclosure. - Platform and CMS exposure. Which platform is this, and how much is it giving away? For WordPress
it checks version disclosure, whether
xmlrpc.phpis open, whether the REST API is handing out usernames, whether the login page is exposed, and whether a debug log or readme file is public. The same exposure model runs for Joomla, Drupal and Magento: version disclosure, admin/login area exposure, and a public metadata file. - Content and client-side. Password fields served over insecure connections, forms that post to an
http://address, end-of-life JavaScript libraries with known bugs, external links that can script your window (reverse tabnabbing), active versus passive mixed content, whether cross-origin scripts carry Subresource Integrity, and a scan for hardcoded API keys and credentials left in the page’s own JavaScript. - Email and DNS security. Can someone send email that looks like it came from you? The scanner checks SPF and DMARC (published and actually enforcing, not just present), CAA (which certificate authorities may issue for your domain), and, where a resolver surfaces it, DNSSEC.
WordPress, and why the risk is rising
If the scanner detects WordPress, it shows a platform note along with the score. It is deliberately frank, and every word of it is grounded.
WordPress runs more of the web than anything else, and that popularity is exactly what makes it the number-one target. Its core, and the tens of thousands of plugins and themes people bolt onto it, are all open-source and publicly catalogued. When a vulnerability is disclosed in any one of them, it comes with a public write-up and often a working proof-of-concept, sometimes within hours. An attacker does not need to find the hole, someone has already published it.
What has changed recently is speed and scale. Attacks used to need a person at a keyboard. Now automated and AI-assisted scanners crawl the web continuously, fingerprint every WordPress install they find, and match it against a list of known-vulnerable versions faster than any human could. A site running an outdated plugin is not waiting to be noticed, it has almost certainly already been catalogued. For a brochure, portfolio or lead-generation site, that entire attack surface buys you nothing.
This is the honest case for getting off WordPress where you can. A purpose-built, statically served site has no plugin supply chain to compromise, no public admin login to brute-force, and no sprawling codebase of third-party PHP for a scanner to fingerprint. It removes most of these vectors by design rather than by patching them one disclosure at a time. If you stay on WordPress, the fix plan this tool produces is the right place to start, harden it, hide it, and keep every component current.
How to read the report
The big number is your score out of 100 with an A to F grade, and a one-line verdict that leads with the single most urgent thing. Below it, each section shows its own score and every check with the evidence behind it and a concrete fix. At the bottom, the priority action plan sorts everything you can improve into Do now, Do next and Nice to have, ranked by how much it matters against how easy it is, the list worth screenshotting and working through.
The scan is cached briefly and rate-limited, and it is read-only, so you can safely run it on your own sites and on any site you are researching.
For AI agents
This tool exposes a plain-text endpoint designed for language models and agents:
GET https://nitrosites.com/tools/security-scanner/scan.php?url=<target>&format=agent
It returns a token-cheap digest of the same analysis shown on this page, the score and grade, the seven section scores, the platform note when one applies, and the prioritised fix plan. Soft rate limits apply; results are cached briefly. No key or login required.
Frequently asked questions
Is this security scan safe and legal to run on a site?
Yes. The scan is completely passive and read-only. It does only what an ordinary browser or search crawler already does, fetch the page, read the response headers, and request a handful of well-known public paths. It never logs in, never guesses passwords, never injects anything and never exploits a weakness. It is the same category of check as a browser opening your site.
Why does it single out WordPress?
Because WordPress powers a larger share of the web than any other platform, which makes it the most-targeted. Its core plus its tens of thousands of plugins and themes are all open-source and publicly catalogued, so a newly disclosed flaw becomes a public target within hours, and automated scanners now match live installs to known-vulnerable versions at machine speed. The scanner checks the exposures that matter most on WordPress, version disclosure, the xmlrpc endpoint, REST API user enumeration, an open login page and public debug or readme files.
Does a WordPress site automatically score badly?
No. The score is objective. A well-hardened WordPress site scores just as high as any other well-configured site. The only point it cannot fully recover is that a real WordPress install inherently advertises itself, which is a true finding. The cautionary platform note you see for WordPress sites is separate from the score.
What does the score out of 100 mean?
It is the weighted sum of seven sections, HTTPS and transport (including the TLS certificate itself), security headers, cookies, information disclosure, platform and CMS exposure, client-side signals, and email and DNS security. Each finding shows its evidence and a concrete fix, and the grade runs A to F. Checks that do not apply are dropped and the rest re-weighted, so the total is always a fair score out of 100.
What are the most important issues to fix first?
The scanner sorts every issue by impact and effort into Do now, Do next and Nice to have. In practice the highest-value fixes are usually removing any public source-control, environment or backup file, moving fully to HTTPS with HSTS, closing WordPress user enumeration and xmlrpc, adding the core security headers, publishing an enforcing DMARC record, and hiding software version numbers.
Can someone spoof email from my domain, and how would I know?
Almost certainly yes if you have not set this up, and most site owners have no idea. SPF and DMARC are DNS records that tell receiving mail servers which senders are authorised to send as your domain. Without them, anyone can forge an email that appears to come from you, a common vector for invoice fraud and phishing that uses your own brand against your customers. The scanner checks both, plus CAA (which certificate authorities are allowed to issue for you) and, where detectable, DNSSEC.