Is my website secure? How do I check?
What you can verify yourself in twenty minutes, what needs tooling, and what "secure" does and does not mean.
Check that HTTPS is enforced everywhere, that the core security headers are present, that no credentials appear in your page source, that no admin or backup paths are publicly readable, and that your software is updated. Those five cover most of what is checkable from outside.
What "secure" means here
Worth being precise, because the word covers several unrelated things. From outside a site you can check its configuration — transport, headers, exposure. You cannot check whether the application has a logic flaw, whether the database is properly permissioned, or whether someone is already inside. An external audit answering "yes" means the visible configuration is sound, not that the system is safe.
The checks worth running
- HTTPS everywhere. Visit
http://yoursite.comand confirm it redirects to HTTPS. Check for mixed content — a single asset over HTTP breaks the guarantee for the whole page. - Security headers. Run
curl -sI https://yoursite.comand look for the handful described below. - Secrets in source. View source and search for
api_key,secret,token,password. API keys in client-side JavaScript are extremely common and often genuinely dangerous. - Exposed paths. Try
/.git/config,/.env,/backup.zip,/phpinfo.php,/wp-config.php.bak. Each should be a 404. - Version disclosure. Check whether headers or meta tags announce your exact CMS and version. That turns a general vulnerability announcement into a targeted list.
- Certificate validity. Confirm the certificate matches the hostname, is not near expiry, and chains correctly.
Reading the headers
| Header | What it does |
|---|---|
Strict-Transport-Security | Forces HTTPS for future visits, closing the gap on the first insecure request. |
Content-Security-Policy | Restricts where scripts may load from. The strongest defence against cross-site scripting. |
X-Content-Type-Options: nosniff | Stops browsers guessing a file's type and executing something they should not. |
Referrer-Policy | Controls how much of your URL leaks to other sites. |
X-Frame-Options or CSP frame-ancestors | Prevents your page being framed for clickjacking. |
Permissions-Policy | Disables camera, microphone and geolocation access you do not use. |
The exposures that actually cause incidents
- A readable
.gitdirectory. Someone can reconstruct your entire source tree, including whatever credentials were once committed and later removed — history keeps them. - An exposed
.env. Database passwords, API keys, signing secrets, in one file. - Backup archives in the web root.
site-backup.zipis guessable, and is routinely guessed. - Secrets in client JavaScript. Anything the browser receives is public. If a key must be in the browser, it must be scoped so that being public is acceptable.
- Directory listing enabled. Turns any unindexed folder into a browsable file tree.
A reasonable baseline
- HTTPS enforced with HSTS, no mixed content.
- The six headers above present and correct.
- No secrets in client-side code.
- No sensitive paths publicly readable, directory listing off.
- Software and dependencies updated on a schedule you actually keep.
- A
/.well-known/security.txtso someone who finds a problem can tell you.
What our audit reports about this
Every item below is measured directly, not inferred. Run it against your own site and the result names the exact rule or header responsible.
- Every security header, present or missing, with what each one would have prevented.
- HTTPS enforcement, mixed content, and TLS certificate validity, issuer and expiry.
- Credential-shaped strings in page source, reported redacted rather than in full.
- Conventional sensitive paths probed and reported as reachable or not.
- Server and framework version disclosure in headers and markup.
For agents and scripts, the same measurement is at
/api/v1/security?url=yoursite.com —
see the API documentation.
Related questions
Does an SSL certificate make my site secure?
It secures data in transit and nothing else. A site with a valid certificate can still expose its database credentials, run vulnerable software and leak data. The padlock means the connection is encrypted, not that the site is safe.
How often should I check?
After every significant deployment, and on a schedule — monthly is reasonable. Configuration drifts, and the common way security regresses is a change nobody thought was security-relevant.
Is a scan enough?
For configuration, it covers a lot. It cannot find application logic flaws, authorisation mistakes or compromised credentials. If you handle sensitive data, an external scan is a starting point rather than a conclusion.
Read next
What are security headers and which do I need?
Six headers, what each actually prevents, and a configuration you can paste and adjust.
ReadI found an API key in my HTML. What now?
Rotate first, investigate second. Then work out whether the key ever needed to be in the browser at all.
ReadWhat is a Content Security Policy?
A list of where your page is allowed to load things from. The strongest defence against script injection, and the easiest header to get wrong.
ReadHow do I check if my SSL certificate is valid?
Five things to verify, how to check each from the command line, and the failure that only shows up on mobile.
Read