Website Security Scanner: what can an outsider see?

It is passive and read only: it does what a browser or a search crawler already does. In about a minute you get a score out of 100 across seven areas, the evidence behind every finding, and a plan sorted into do now, do next and nice to have. The most common result is not a hack. It is a site quietly telling strangers more about itself than it needs to.

What the result means

“Public .env or .git found.” Stop and fix this first. It can expose database passwords, API keys and your entire source history. Remove the file from the webroot and rotate every credential in it. If the site is one nobody maintains, rebuilds and rescues is the path out.

“Platform and version disclosed” on a WordPress, Joomla, Drupal or Magento site. Version numbers turn an attacker’s guess into a lookup, and automated scanners match live installs against known-vulnerable versions continuously. Short term, hide the version, close user enumeration and the xmlrpc endpoint, and keep every component current. Longer term, a statically served site has no plugin supply chain and no public login to attack, which is what rebuilds and rescues does.

“No enforcing DMARC record.” Without SPF and DMARC, anyone can send email that appears to come from your domain, which is how invoice fraud usually reaches your customers. These are DNS records, not website changes, and they are included in hosting and care. You can confirm what is published today with DNS Lookup.

“Security headers missing.” A handful of response headers stop whole classes of attack and most of them are a one line change at the server or the edge. This is the highest value to effort ratio on the whole report.

“Cookies set without Secure, HttpOnly or SameSite.” That is the difference between a session an attacker can steal and one they cannot. Usually fixed in the platform or plugin that sets the cookie.

“Certificate expiring” or a TLS warning. The certificate is read as one of the seven sections. SSL Checker goes deeper on the chain and the protocol versions, and Stack Detector tells you what the site is built on if you inherited it and nobody documented it.

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 insecure http:// 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, HttpOnly and SameSite flags, the difference between a session cookie an attacker can steal and one they cannot.
• Information disclosure. Version numbers in the Server and X-Powered-By headers and the meta generator tag are a gift to an attacker, they turn a guess into a lookup. The scanner checks a public .git repository and a public .env file, 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.php is 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 it safe to run this on my own site, or on someone else's?

Yes. It is read only and passive. It fetches the page, reads the response headers and requests a few well known public paths, which is the same thing a search crawler does every day. It never logs in and never tries to exploit anything.

My site is on WordPress. Am I going to fail automatically?

No. A well hardened WordPress site scores as high as anything else. The one point it cannot fully recover is that a real install inherently advertises itself. The platform note you see is separate from the score.

There are 30 findings. What do I do on Monday morning?

Work the "do now" list only, top to bottom. It is sorted by impact against effort. Everything below it can wait a month without anything bad happening.

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.

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.