How to Check if a Website Is Secure: A 10-Minute Audit
Check HTTPS, security headers, exposed files, and email spoofing protection in about ten minutes with free tools · no security background required.
By Daniel A · Kraftwire Software
· 7 min readKey Takeaway
You can verify the essentials of any website's security in about ten minutes using free browser-based checks: a valid HTTPS certificate, security headers, no exposed configuration files, and email spoofing protection. The browser padlock only proves the connection is encrypted · it says nothing about how the site handles your data once it arrives.
What the Padlock Actually Means
The padlock, or in newer browsers the absence of a "Not secure" warning, means one thing: traffic between your browser and the site is encrypted with TLS. That stops someone on the same network from reading what you send.
Here is what it does not mean:
- It does not mean the site is legitimate · phishing sites get valid certificates in minutes, for free
- It does not mean the site stores your data safely
- It does not mean the code behind the login form is secure
Since certificates became free and automatic, the padlock stopped being a trust signal and became a baseline. Its absence is disqualifying; its presence proves almost nothing. The checks below are how you actually form an opinion.
Before You Start
Everything below is passive: you are reading public configuration, the same way a browser or a mail server would. You are not attacking anything, so these checks are appropriate for a vendor's site as well as your own. Total time is about ten minutes, with no accounts and nothing to install.
Step 1 · HTTPS and the Certificate (2 minutes)
Type the site's address with http:// in front. It should immediately redirect to https://. A site that happily serves unencrypted pages in 2026 is telling you nobody is minding the store.
Then inspect the certificate itself with the SSL checker: is it valid, when does it expire, does it cover the exact domain and its www variant, and is the TLS version modern (1.2 or 1.3)?
Red flags: an expired certificate, no redirect from HTTP, or ancient TLS versions still accepted.
Step 2 · Security Headers (2 minutes)
Security headers are instructions a site sends to every browser: what content may load, whether the site can be embedded in a frame, whether plain HTTP is ever acceptable again. They are the difference between a browser actively defending you and a browser hoping for the best.
Run the domain through the security headers checker. You are looking for:
Missing headers are extremely common, and that is exactly why this check is useful: their absence tells you nobody has done a hardening pass. A site with a thoughtful Content-Security-Policy almost always has an operator who cared about the rest too.
Step 3 · Exposed Files (2 minutes)
This is the check with the highest damage potential. Development leaves artifacts, and misconfigured deployments serve them publicly: .env files full of credentials, .git directories exposing full source history, database dumps, editor backup files.
The exposed files scanner checks the common paths in one pass. If you are auditing your own site and find your .env served publicly, treat every credential in it as stolen: rotate the keys first, then fix the deployment.
An exposed environment file on a live site is a critical finding, full stop · it converts every other protection on this list into decoration.
Step 4 · Email Spoofing Protection (2 minutes)
Can an attacker send email that appears to come from this domain? Three DNS records decide: SPF says which servers may send, DKIM cryptographically signs messages, and DMARC tells receiving servers what to do when the first two fail.
Run the domain through the email security checker. A missing DMARC record, or a policy permanently stuck at p=none, means phishing emails "from" this domain will keep landing in inboxes. For a vendor, that is their users getting phished under their name. For your own domain, this is a fifteen-minute DNS fix with outsized payoff.
Step 5 · Uptime and Transparency (2 minutes)
Finally, a soft signal that is more predictive than it looks: does the operator publish a status page and communicate about incidents? Look for a status link in the footer or try the status. subdomain.
Transparency about downtime correlates strongly with operational maturity. Teams that publish incident timelines tend to be the same teams that patch quickly and monitor properly. We cover why this matters, and how to set one up for your own product, in uptime monitoring and status pages.
The Ten-Minute Scorecard
- HTTPS and certificate · a pass looks like: forced redirect, valid certificate, TLS 1.2+
- Security headers · HSTS, CSP, nosniff, and frame protection present
- Exposed files · nothing sensitive reachable at common paths
- Email protection · SPF, DKIM, and an enforcing DMARC policy
- Transparency · public status page with incident history
Three or fewer passes on a site that wants your payment details or personal data is a real signal · not proof of a breach, but proof that security is not anyone's job there.
What This Audit Does Not Catch
Ten minutes of passive checks cannot see authentication flaws, broken access control, injection vulnerabilities, or whether the database lets any signed-in user read every row. Those require either access to the source or a proper scan of the running application. Treat this audit as a screening test: it reliably detects neglect, and it cannot certify safety.
When you are ready to go deeper on your own site, the full security audit checklist covers the layers this quick pass skips, and our free security tools roundup lists single-purpose checkers for the individual questions that come up along the way.
How Often to Repeat This
Security posture drifts. Certificates expire, a deploy overwrites the headers file, a new subdomain launches without DMARC, a debugging session leaves a dump file in the web root. Every check on this list can pass in January and fail in March without anyone touching "security" directly.
A reasonable cadence:
- Your own production site: after every significant deploy, and monthly at minimum
- A vendor you depend on: before you sign, and again before any renewal
- A site you are about to give payment details to: right now, once · the ten minutes are worth it for anything meaningful
If repeating manual checks sounds like the kind of thing you will do twice and then forget, that instinct is correct for most people. Automated monitoring exists precisely because humans do not re-run checklists, and continuous checks catch the drift on the day it happens instead of the month after.
Your Own Site vs a Vendor's
For a vendor's site, passive checks are as far as you can ethically go. Combine the scorecard with direct questions: where is data stored, is there a security page, how are incidents disclosed? A vendor that fails the ten-minute basics is answering those questions for you.
For your own site, every failed check above is roughly an afternoon of fixes, and passing all five puts you ahead of most of the web. Then go beyond passive checks · you own the site, so you are allowed to scan it properly, including the parts a passerby cannot see.
If the site in question is yours, run a free security scan and get the full picture in less time than this audit took.