Checklist: Is This Website Connection Actually Secure?
A practical checklist to understand what HTTPS, padlocks, and certificate warnings really mean for your connection security.

You see a padlock in your browser's address bar. Does that mean the website is safe? Not quite. Let's walk through what actually makes a connection secure — and what doesn't.
This checklist covers the fundamentals of website connection security in plain language. No exploit techniques, just literacy.
✅ Check 1: Does the URL Start with HTTPS?
Look at the address bar. Does the URL begin with https:// (not http://)?
What this means:
Why it matters:
HTTPS is the baseline for secure connections. If a site asks for sensitive information over HTTP, don't trust it.
Learn more: HTTP vs HTTPS: What Actually Changes
✅ Check 2: Is There a Padlock Icon?
Most browsers show a padlock icon to the left of the URL when a site uses HTTPS.
What the padlock means:
What the padlock does NOT mean:
Key point: HTTPS secures the *connection*, not the *content* or *intentions* of the website. A scam site can have a perfectly valid padlock.
Dive deeper: What That Padlock Really Means
✅ Check 3: Does the Site Force HTTPS (HSTS)?
Some sites enforce HTTPS at the protocol level using HSTS (HTTP Strict Transport Security).
How to tell:
You usually can't tell directly without developer tools, but signs include:
What this means:
HSTS tells your browser: "Only connect to me over HTTPS. If you can't establish HTTPS, refuse the connection entirely."
This prevents downgrade attacks where an attacker forces your browser to use unencrypted HTTP. Banks and other security-sensitive sites often use HSTS.
You don't need to check this manually — it's an extra layer of protection working behind the scenes. Just know it exists and that high-security sites enable it.
Related: The Journey of a URL to understand how browsers connect to websites.
✅ Check 4: Is Everything on the Page Loaded Over HTTPS?
Even if the main page uses HTTPS, individual resources (images, scripts, stylesheets) might load over HTTP. This is called mixed content.
How to check:
What this means:
Mixed content weakens HTTPS. An attacker could tamper with unencrypted resources — injecting malicious scripts into an otherwise secure page.
What browsers do:
Your takeaway:
If you see mixed content warnings, the site's security is compromised. Be cautious entering sensitive data.
✅ Check 5: Are There Certificate Warnings?
Browsers display scary warnings when something is wrong with a site's HTTPS certificate.
Common certificate problems:
What to do:
⚠️ Do NOT ignore certificate warnings. They mean the browser cannot verify the server's identity. You could be connecting to an imposter.
When it might be okay:
When it's NOT okay:
Certificate warnings are your browser protecting you. Listen to them.
✅ Check 6: Does the Domain Look Right?
Even with HTTPS and a valid certificate, you might be on a phishing site.
Red flags:
How attackers use HTTPS:
Phishing sites often have valid HTTPS certificates. Certificate authorities verify you control a domain, not that you're trustworthy. An attacker can register paypa1.com (with a number 1) and get a legitimate certificate for it.
What to do:
Always check the domain carefully before entering sensitive information. HTTPS secures the connection but doesn't verify the site's legitimacy.
✅ The Baseline: What "Secure" Really Means
A secure website connection means:
A secure connection does NOT mean:
Security is layered. HTTPS is one layer. Verifying the domain, being cautious about what you share, and understanding the site's reputation are others.
Quick Reference Checklist
Before entering sensitive information:
If any of these fail, proceed with caution — or don't proceed at all.
The Takeaway:
HTTPS and padlocks protect your connection, not the trustworthiness of the website. Check the domain, watch for certificate warnings, and understand that encryption in transit is just one piece of security.
Related reading:
*This post is part of Hacking Bits, where we explain how everyday technology works — one bit at a time.*
Related Posts
Checklist: Do You Actually Need a CDN?
A practical checklist to understand what CDNs do, what they cache, when they help, and whether your site needs one.
Git Branch vs Commit: What's the Difference?
Branches and commits are both fundamental to git — but they work in completely different ways. Here's what each one does and why it matters.
Cookies, localStorage, and Session Storage: Which One When?
A comprehensive guide to browser storage mechanisms — understand cookies, localStorage, and sessionStorage, how they differ, when to use each, and the security implications of your choice.