Is Your Website Actually Secure? Here's How to Verify

"Is my website secure?" sounds like a simple question, but the answer depends on dozens of moving parts — your TLS configuration, HTTP response headers, cookie flags, DNS records, CORS policy, and the third-party scripts you've quietly accumulated over the years. A green padlock in the browser means almost nothing on its own.

Here's exactly how to check whether your website is actually secure, with real tests you can run today.

Start with the SSL/TLS layer

HTTPS is the floor, not the ceiling. A valid certificate confirms encryption is happening — it doesn't confirm it's configured well.

What to check

• Certificate validity: not expired, matches the domain (including www and any subdomains), issued by a trusted CA.
• TLS version: TLS 1.2 minimum, TLS 1.3 preferred. Disable TLS 1.0 and 1.1.
• Cipher suites: no RC4, 3DES, or export-grade ciphers.
• HSTS: the Strict-Transport-Security header is set with a max-age of at least 6 months.
• Certificate chain: intermediate certificates are served correctly (a common silent failure).

How to test it

Open your terminal and run:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Look at the certificate, chain, and protocol. For a deeper analysis, SSL Labs (ssllabs.com/ssltest) gives a graded report — anything below an A means there's work to do.

Audit your HTTP security headers

Security headers are free, fast wins. Most sites are missing at least three of them.

The headers that matter

1. Content-Security-Policy (CSP): controls which scripts, styles, and resources can load. The single most effective defence against XSS.
2. Strict-Transport-Security: forces HTTPS.
3. X-Content-Type-Options: nosniff: stops MIME-type sniffing attacks.
4. Referrer-Policy: controls what referrer information leaks to third parties.
5. Permissions-Policy: restricts access to camera, microphone, geolocation, etc.
6. X-Frame-Options or CSP's frame-ancestors: prevents clickjacking.

Quick test

Run this against your domain:

curl -I https://yourdomain.com

Scan the response. Missing headers? That's your shortlist. A tool like WebSentry will pull every header, flag what's missing, and grade your overall configuration — useful when you want a single report instead of running half a dozen curl commands.

Inspect your Content Security Policy properly

A CSP exists or it doesn't — but a bad CSP is almost as bad as none.

Red flags in a CSP

• unsafe-inline in script-src — defeats most of CSP's value.
• unsafe-eval — opens the door to script injection.
• Wildcards like * in script-src or connect-src.
• Missing frame-ancestors directive.
• No report-uri or report-to — you'll never know when something breaks.

Open your browser's DevTools, go to the Network tab, reload the page, and inspect the response headers for the document. Read the CSP carefully. If you can't justify every directive, it needs tightening.

Check your cookies

Cookies leak session tokens, CSRF tokens, and personal data when configured carelessly.

Every cookie should have

• Secure — only sent over HTTPS.
• HttpOnly — inaccessible to JavaScript (for session cookies).
• SameSite=Lax or Strict — protects against CSRF.
• A sensible Path and Domain — don't scope cookies more broadly than needed.

In DevTools, open Application → Cookies and check each one. Pay special attention to anything from analytics, chat widgets, or auth providers — third-party scripts often set cookies that don't meet your standards.

Verify your DNS configuration

DNS is the security layer most developers forget exists.

Records to verify

• SPF: a single TXT record listing authorised mail senders.
• DKIM: public keys for signing outbound mail.
• DMARC: a policy telling receivers what to do with failures. Start with p=none, move to quarantine, then reject.
• CAA: restricts which CAs can issue certificates for your domain.
• DNSSEC: cryptographically signs DNS responses (optional but valuable).

Quick DNS check:

dig TXT yourdomain.com
dig TXT _dmarc.yourdomain.com
dig CAA yourdomain.com

If your domain doesn't send email, you still need SPF and DMARC records to prevent spoofing — set SPF to v=spf1 -all.

Test your CORS policy

Misconfigured CORS can expose authenticated API endpoints to any origin on the internet.

The common mistake

Reflecting the request's Origin header back as Access-Control-Allow-Origin while also setting Access-Control-Allow-Credentials: true. That's effectively no protection at all.

How to test

curl -H "Origin: https://evil.example" -I https://yourdomain.com/api/user

If the response includes Access-Control-Allow-Origin: https://evil.example alongside Access-Control-Allow-Credentials: true, you have a problem. Allow-list specific trusted origins instead.

Look at what you're actually shipping

Open your site in an incognito window and check the Network tab. You're looking for:

• Mixed content (HTTP resources on an HTTPS page).
• Outdated libraries — jQuery 1.x, old versions of Bootstrap, abandoned plugins.
• Third-party scripts you don't recognise or no longer use.
• Inline scripts that should be moved to files and covered by CSP.

For WordPress, Drupal, or any CMS-based site, also confirm:

• Admin paths aren't publicly indexable.
• Version numbers aren't leaking in generator meta tags or asset query strings.
• File upload endpoints validate type and size.
• The /.git, /.env, and /wp-config.php.bak paths return 404, not 200.

Put it on a schedule

Security isn't a one-time check. Certificates expire, dependencies update, and someone always adds a new tracking script the week after your last audit.

A reasonable cadence:

• Weekly: automated header and SSL scan.
• Monthly: review new third-party scripts and cookies.
• Quarterly: full audit including DNS, CORS, and dependency versions.
• On every deploy: at minimum, confirm headers and CSP haven't regressed.

If you'd rather not piece this together manually, run a free scan at websentry.dev. WebSentry checks SSL, headers, CSP, cookies, DNS, and CORS in one pass and gives you an A–F grade with specific fixes for each finding — a fast way to answer "is my website secure?" with evidence rather than a guess.