How to check a website for security issues from the outside
You can check a live site's security from the outside in about fifteen minutes with free tools: one for HTTPS, one for security headers, and a look at the page source for exposed secrets. The harder skill is reading the results, because scanners flag missing hardening and real holes in the same red.
What an outside check can and can't see
Outside scanners see what any visitor's browser sees: the HTTPS connection, response headers, the HTML and the files it loads. They can't see your server code, your database permissions or who has your passwords. A clean outside report is a good sign for a brochure site, and only the start for a site with accounts or payments.
The checks, in order
- HTTPS. Run the domain through Qualys SSL Labs. You're looking for a valid certificate for every hostname you use, no old protocol versions, and an overall grade of A or better.
- Security headers. Run the site through MDN HTTP Observatory. It checks Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, frame protection, Referrer-Policy and cookie flags, and explains each result.
- Mixed content. Open the page with the browser console showing. Warnings about content loaded over
http://mean parts of the page travel unencrypted. - Secrets in the page. View the source and search for
key,token,secret,sk_live,AKIAandBearer. Also check any JavaScript files the page loads. - Forms. Inspect each
<form>and check itsactiongoes to your own site over HTTPS, not a third-party address you don't recognise. - Outdated software. If your site runs a CMS or plugins, compare their versions with the latest releases. Many compromises of small sites come through an old plugin.
Reading the results: real problems vs noise
| Finding | Usually | Why |
|---|---|---|
| A live API key or password in the page | Urgent | Anyone can copy it now. Revoke it first, then remove it |
| Expired or mismatched certificate | Urgent | Visitors get a browser warning and many leave |
| Form posting to an unknown domain | Urgent | Visitors' data may be going somewhere you don't control |
| Outdated CMS or plugin with known flaws | High | Automated attacks look for exactly this |
| No Content-Security-Policy | Medium | Doesn't cause an attack, but removes a strong defence if one happens |
| No HSTS header | Medium | First visits over plain HTTP can be intercepted |
| Missing Permissions-Policy, or a server version banner | Low | Hardening; fix when convenient |
| "Vulnerable" library with no reachable use | Often noise | Check whether the flawed function is actually used |
A letter grade is a summary, not a verdict. A site can score badly for missing headers while having nothing exploitable, and score well while leaking a key in a script the scanner didn't parse. Work from the specific findings, most urgent first.
Mistakes when acting on a scan
- Deleting a leaked key without revoking it. It's already been copied from the page or from caches. Revoke it at the provider, then remove it.
- Copying a strict policy without testing. A Content-Security-Policy that blocks your own fonts or forms breaks the site. Try it in report-only mode first, or on a copy.
- Running aggressive scanners against someone else's site. Passive checks like the ones above are fine on any public site; active vulnerability scanning needs the owner's permission.
Anticode sites publish their own report
Every site published with Anticode has a live security report at /.well-known/anticode-security, computed from the published pages each time it's requested. It shows the checks the site passes, so you, a client or anyone else can verify it without trusting a screenshot. Before publishing, Sentinel runs twelve checks on the exact HTML, covering the Content-Security-Policy, forms, links, images and anything that looks like a secret; the AI website security checklist explains each one. When you publish, the server re-runs the checks that matter for a public page.
Published pages from the design engine contain no scripts, which removes a whole class of findings. Outside scanners are still worth running once, to see your site the way an attacker's tools would.
Limits
Neither outside scanners nor Anticode's report test your accounts: whether your Anticode, domain registrar, email and payment provider logins have two-factor sign-in, and who else can use them. Those are where small sites are most often taken over. If you've exported the site to your own hosting, the report and Anticode's checks no longer cover it. If you think a site has already been compromised, see what to do if your website is hacked.
Questions people ask
Are free website security scanners safe to use?
The passive ones named here only request your pages as a browser would. Be wary of tools that ask for your login or want to install something on your server.
How often should I check?
After every significant change, and every few months otherwise. Certificates, plugins and third-party scripts change without you touching the site.
My score is an F. Am I hacked?
Not necessarily. Low header scores usually mean missing hardening, not a breach. Look for exposed secrets and unexpected form targets first.
Sources
- Qualys SSL Labs: SSL Server Test, checked
- MDN HTTP Observatory, checked
- OWASP Top 10, checked