Security scanner
What a strangercan ask your site for
A free scan that reads a live site the way an uninvited visitor does — headers, TLS, cookies, DNS, mail records, the paths your own code names — and hands back the evidence behind every finding, not a risk rating.
- 49 security checks
- Engine 1.24.12
- Read-only by default
- Free account, no card
What the scan reads
Six places,
one pass
The scan fetches the page once and answers every check off that picture, which is why a complete run costs your server roughly a page view rather than a denial-of-service with a logo on it.
The response headers
Whether a Content-Security-Policy exists and whether it lets inline script, HSTS and its max-age, frame-ancestors, nosniff, Referrer-Policy, Permissions-Policy — and the stack banners a server leaks instead: Server, X-Powered-By, X-AspNet-Version, X-Generator.
The TLS handshake
The version a modern client can actually negotiate, how close the certificate is to expiring, and whether port 80 redirects straight to HTTPS or serves the same page over plain HTTP while nobody is watching.
What the page sets and links
Cookie names with their Secure, HttpOnly and SameSite flags — names only, values are never read. Plus http:// sub-resources on an HTTPS page, state-changing forms carrying no anti-CSRF token, and scripts pulled in without integrity attributes.
DNS, the registry and mail records
SPF, DMARC and published DKIM selectors, CAA, and from registry data whether the domain is expiring, transfer-locked, signed with DNSSEC, or served by nameservers that are not the ones it delegates to. A CNAME left pointing at a service nobody claims is a takeover, and it is checked for.
Paths a stranger could request
The well-known security file, the admin, API and debug paths your own JavaScript names, directory listings, source maps, sensitive files. Same origin, GET only, a five-second cap per request and a budget of 24 probes for the whole scan.
The stack it recognises
Which platform the site runs on and what that platform’s published configuration should say, and which framework and library versions the responses give away — reported against what has a public exploit, not against a version nobody has ever attacked.
Security · 49 checks
Every check,
grouped by what it reads
Grouped so the list is navigable; the order inside each group is the registry’s, which puts the load-bearing checks first. Five of them only run on a domain you have proved you own, and the page says which.
Response headers and what they leak
10 checks
The browser-side defences a header switch on or off — content policy, transport security, framing, MIME sniffing, referrer and permissions — plus the version banners that tell an attacker which exploits were written for your stack.
- Content-Security-Policy
- Strict-Transport-Security
- Clickjacking protection (X-Frame-Options / frame-ancestors)
- X-Content-Type-Options
- Referrer-Policy
- Permissions-Policy
- Mixed content
- Server header disclosure
- X-Powered-By disclosure
- Subresource Integrity
TLS and HTTPS
3 checks
What the connection itself is made of: the protocol a modern client can negotiate, the certificate’s remaining life, and whether plain HTTP is a redirect or a second copy of the site.
- TLS certificate expiry
- TLS protocol version
- HTTP → HTTPS redirect
Identity, sessions and injection
11 checks
The parts that decide who you are and whether your input reaches a database: cookie flags, cross-origin rules, anti-CSRF tokens, redirects that will follow an attacker’s target, tokens sitting in browser storage, JSON Web Tokens and their algorithms, and the shapes of SQL and cross-site-scripting answers. The active half of this group runs only on a verified domain.
- Cookie security flags
- CORS policy
- Anonymous access to protected pages
- CSRF protection on state-changing forms
- Open redirect through URL parameters
- SQL injection in query parameters
- Reflected cross-site scripting
- DOM-based XSS sinks fed by URL input
- Session credentials in browser storage
- JSON Web Tokens published to anonymous visitors
- JWT algorithm confusion at the site’s API
Domain, DNS and email
7 checks
The records around the site rather than in it. A lapsed domain takes the website and every mailbox on it down; an SPF or DMARC gap lets anyone send as your customers.
- SPF record
- DMARC record
- DKIM signing keys
- CAA record
- Domain registration expiry
- Domain registry state
- Subdomain takeover
Exposure and disclosure
5 checks
Things that are reachable because somebody forgot they were public: directory listings, source maps, sensitive paths, keys compiled into a bundle the browser downloads, and the absence of the one file researchers look for first.
- security.txt
- Exposed sensitive files
- Secrets in JavaScript
- Source maps
- Directory listing
APIs and backends
6 checks
Where the data actually lives: GraphQL endpoints and what they disclose, rate limiting under a small burst, upload handlers, webhook receivers and whether they verify signatures, and the row-level rules of a Supabase or Firebase project you have connected. Ownership-gated, and shaped-only — no records are extracted.
- GraphQL endpoint protection
- File upload content validation
- Webhook signature verification
- Mobile API rate limiting
- Supabase row-level security
- Firebase security rules
Platform and stack
6 checks
The hosts most sites sit behind and the configuration they should have published, the software the responses admit to running, and whether anything in front of the origin absorbs a flood at all.
- DDoS protection
- Vercel hosting security
- Netlify hosting security
- Cloudflare hosting security
- Tech stack & CVE
- Tech stack inventory
After the breach
1 check
One check, and the one most teams discover too late: whether anything in the stack is recording who did what, or whether the incident will be reconstructed from the attacker’s goodwill.
- Audit logging & monitoring exposure
What each one looks at, and the cases where it deliberately says nothing, is on the full list of every check.
Nothing here needs a zero-day. That is the point.
Why this is the big one
Sites are not breached
by genius
Most of what turns up in a post-mortem is boring. A wildcard CORS rule that also accepts credentials. An admin path that answers to a stranger because the framework ships it on. A key compiled into a bundle anyone can download. A CNAME still pointing at a service the account behind it stopped paying for. None of these set off an alert, and all of them are visible in one request to anyone who thinks to make it.
This is why the security pillar is the largest part of the scan — every other pillar is a smaller share of the same 85 checks. It is also why the report says what it abstains from. A check that could not see enough does not score you badly; it records that it could not look, and the pillar is marked provisional rather than guessed at.
And it is not a penetration test. It never logs in, never submits anything of yours, never touches a state-changing endpoint, and refuses private and metadata addresses before a byte leaves. What it does instead is read the site the way a stranger reads it, and tell you what that stranger found — with the header, the record or the status code in the finding, so you can run the same lookup and get the same answer.
See which ones
yours fails
Paste a URL and the whole security pillar runs against it, with the measured value behind every finding and one prompt that fixes them. About a minute, and a free account.
Scan your site
ScanlyFix
Security, SEO and AI-answer-engine scanning for anything you put on the internet. Paste a URL, read the evidence, run the fix.
Home