How to know if your website is secure (practical guide, 2026)

When someone asks "how do I know my website is secure?", the honest answer is: you never get absolute certainty — but you can eliminate most of the common risk by checking five layers that are observable from the outside, with nothing to install and no access to the code.

Worth separating up front: what is externally verifiable and what isn't. Conflating the two is the expensive mistake — it produces a feeling of approval without covering where leaks actually happen.

The 5 layers you can check from outside

1. HTTPS and the TLS certificate

The padlock in the browser says the connection is encrypted — and nothing more. What matters beyond it: is the certificate close to expiring? Does the site still accept old protocols (TLS 1.0/1.1)? And above all: does http:// redirect to https://? A site that answers on both is a site where the first visit can be intercepted.

2. HTTP security headers

The most neglected layer and the cheapest to fix — these are configuration lines, not refactoring. The ones that change the game:

• HSTS (Strict-Transport-Security) — forces the browser to speak only https to your domain, closing the window from the previous item.
• CSP (Content-Security-Policy) — the core defense against XSS: it declares where scripts may load from. The hardest to get right and the one that protects most.
• X-Frame-Options / frame-ancestors — stops your site from being embedded in someone else's iframe (clickjacking).
• X-Content-Type-Options: nosniff — stops the browser from guessing a file's type.

3. DNS

Home to a problem almost nobody looks for: the dangling subdomain. You pointed blog.yoursite.com at a service, cancelled the service, and forgot the DNS record. Whoever claims that address on the service now serves content on your domain. Also worth checking: DNSSEC and the CAA record, which limits which authorities may issue certificates for you.

4. Email authentication (SPF, DKIM, DMARC)

This doesn't protect the site — it protects your name. Without those three records, anyone can send email that appears to come from your domain. For anyone running a product with users, that's a direct phishing vector aimed at your own base. It's DNS configuration; an afternoon's work.

5. Accidental exposure

Files and paths that shipped by mistake: .env, .git/, indexed admin panels, and private paths listed in your own robots.txt — which is public, and often becomes a map of exactly what you meant to hide.

The 2 layers an external scan does NOT see

Here's the honest limit of any tool that only looks at a URL:

• Authorization logic. If user A can read user B's order by changing an id in the URL, that's invisible from outside — it only surfaces by testing with two real accounts and the owner's permission. It's the most common flaw in AI-built apps, because the generator writes the endpoint and forgets the "is this record yours?" check.
• Secrets in code and in the database. An API key committed, a credential in Git history, a table with no access rule. That needs repository access.

Anyone promising a "100% secure site" while looking only at the URL is selling the first list as if it were both.

The shortest path

You can do all of this by hand, one tool per layer. Or run it in one shot: ecoa's free scan checks all five layers from the URL, with no signup and nothing to install, and returns a score with problems ranked by severity.

If you work with an AI assistant (Claude, Cursor, ChatGPT), you can connect ecoa as an MCP server and simply ask "check whether my site is secure" — the AI runs the check and reads the result inside the conversation, without you going anywhere.