Is my website secure? How to check in 5 minutes.

What "secure" actually means

Nobody's website is perfectly secure, and anyone who tells you otherwise is selling something. What you can actually verify in five minutes is posture: is the public-facing surface configured the way a careful operator would configure it in 2026? That's a narrower, answerable question than "can a skilled, motivated attacker eventually break in" - and it's the question that matters for the vast majority of sites, because most compromises exploit basic misconfiguration, not zero-day exploits against hardened targets.

A posture check tells you whether the doors and windows are shut. A penetration test tells you whether someone can still pick the lock. Start with the first - it's free, it's fast, and it closes the gaps that get exploited automatically by bots scanning the entire internet, which is the overwhelming majority of real-world attacks against small sites.

The six checks, in order

Each of these takes under a minute and needs nothing more than a browser, and most need nothing at all beyond typing a URL.

1. Transport - is the connection actually encrypted?

Type your domain into a browser without the https:// prefix. You should land on an HTTPS page automatically, with a valid certificate (no warning icon) and no "not fully secure" indicator from mixed content - images, scripts, or stylesheets still loading over plain HTTP on an HTTPS page. If you see any of those, transport is your first fix; nothing else on this list matters if traffic isn't encrypted end to end.

2. Headers - are browser protections switched on?

Open your browser's developer tools, go to the Network tab, reload the page, and inspect the response headers on the main document. Look for Strict-Transport-Security, a Content-Security-Policy or frame-ancestors directive, X-Content-Type-Options: nosniff, and a Referrer-Policy. These headers switch on protections your browser already ships - they cost nothing to add and stop entire classes of attack outright.

3. Exposure - is anything sensitive publicly reachable?

Try appending a handful of predictable paths to your domain: /.env, /.git/HEAD, /backup.zip, /phpinfo.php, /wp-config.php.bak. None of these should return a real file. If one does, you likely have a misconfigured deploy pipeline serving files that were never meant to be public - this is one of the single most common causes of real breaches at small companies, because it hands over credentials directly.

4. Mail authentication - can someone spoof your domain?

Run a DNS lookup for your domain's TXT records (or use a free tool like MXToolbox) and confirm you have SPF, DKIM, and DMARC records. Without them, anyone can send email that appears to come from your domain, which is a favorite vector for phishing your own customers and staff.

5. Integrity - do you trust what you're loading?

List the third-party scripts your site actually loads - analytics, chat widgets, ad tags, fonts. Every one of those is code running with your site's authority in your visitors' browsers. Where you can, pin them with Subresource Integrity so a compromised CDN can't silently swap in malicious code.

6. Disclosure - can a researcher warn you before going public?

Check whether /.well-known/security.txt exists on your domain. If a security researcher finds a real issue, this two-minute file is the difference between a private email to your team and a public tweet.

Reading what you find

Not every finding carries the same weight. A missing Referrer-Policy header is a minor hygiene gap; an exposed .env file with live database credentials is an active emergency. Prioritize in this rough order: anything that exposes credentials or private data first, transport and header gaps second, disclosure and integrity hygiene third. Fix the top of the list before worrying about the bottom - a perfect Referrer-Policy on a site leaking its database password is not progress.

Do it automatically next time

Running these six checks by hand teaches you the map, which is worth doing once. After that, a passive automated scan checks the same surface - plus a longer tail of configuration detail no one checks by hand every week - and returns a shareable, graded report with a fix for each finding. Run it after every deploy that touches config, DNS, or dependencies, since posture drifts quietly and often.

Five minutes by hand teaches you the map. A free automated scan keeps checking it for you.