- What the padlock actually covers
- Seven things HTTPS leaves untouched
- How HSTS works and its caveats
- What to review after moving to HTTPS
The short answer
HTTPS protects the traffic between the browser and the server. It stops someone along the route from reading or altering what passes. What happens inside the site is out of scope. The padlock means this connection is encrypted; it does not mean this site is safe.
What the padlock does cover
Picture logging in to an order system over public Wi-Fi from a meeting room. With HTTPS, the username and password you typed and the client names on screen cannot be read en route. The certificate also lets the browser confirm which server it reached, so an attempt to steer you to an impostor is visible.
That is the boundary. How those values are handled once they arrive is a separate question entirely. Malicious input travels down an encrypted road just as comfortably as anything else.
A certificate confirms control of the domain. It says nothing about whether the operator is trustworthy. Fraudulent sites run on HTTPS too. Chrome replaced the padlock with a neutral icon in 2023; whatever the browser shows, it means only that the connection is encrypted.
What HTTPS leaves untouched
1. Software vulnerabilities
If a flaw turns up in your CMS, a plugin, or the server software, encryption is irrelevant to it. Patching is the only answer. A plugin still running on a public site after years without an update is the first thing to review.
2. Logins with real credentials
If a password was reused and has leaked from some other service, the attacker arrives with the correct username and password. The connection is encrypted and, from the server's point of view, this is the legitimate user. What helps here is multi-factor authentication and not reusing passwords.
3. Permission mistakes
A page meant for members only that opens for anyone who knows the URL. Download links numbered in a guessable sequence. The traffic is protected; you are simply showing the file to the wrong person.
4. Flaws in how input is handled
SQL injection and cross-site scripting both originate in the handling of input values. The mechanics are not covered here, but both arrive inside encrypted traffic, so HTTPS does nothing to stop them. The fix is in the application, with a WAF as the layer that holds the line in the meantime.
5. Bots and traffic volume
Automated crawling and scraping happen over HTTPS like everything else. Load is a matter for rate limiting and caching.
6. Server and cloud misconfiguration
A backup file left in a public folder. Directory listing enabled. A cloud storage share set to "anyone with the link" and forgotten. Each of these leaks information without encryption being involved at any point.
7. Both ends of the connection
If malware is running on the visitor's machine, what appears on screen and what they type is available before encryption ever applies. A password saved in a browser on a shared office PC is the same category of problem. Hardening the middle of the route does not help when the ends are soft.
Filing "we moved to HTTPS" as "security: done" tends to stop the next review for several years. HTTPS is the starting line.
A word on HSTS
Even on an HTTPS site, the very first request from someone who types http:// in the address bar travels unencrypted. HSTS (the Strict-Transport-Security header) narrows that gap: when the server sends the header, the browser remembers to use HTTPS for that site from then on.
Two caveats. First, browsers only honour the header when it arrives over HTTPS, so a visitor's genuinely first visit is still unprotected. There is a preload list that browsers ship with, but it has requirements and removal is slow. Second, the policy persists for the lifetime you set. Add the directive covering subdomains and any subdomain without a valid certificate stops loading. Start with a short lifetime, confirm nothing breaks, then extend it.
How this looks in practice
A trading company of thirty staff runs a members' area for downloading product documents. The whole site moved to HTTPS years ago. A review turned up three things.
- The PDFs could be opened by direct URL from outside the members' area.
- Two administrator accounts belonged to people who had left.
- A plugin that had not been updated in three years was still active.
The documents were moved behind authentication, the accounts were cleaned up, and the plugin was replaced. Nothing about the HTTPS configuration was touched, and yet the amount of information visible from outside dropped substantially.
In summary
HTTPS secures the route. The safety of what sits on top of it has to be built separately. Keeping software updated, tidying accounts and permissions, reviewing what is publicly reachable, and handling input properly in code will do more than checking the padlock. Add HSTS as a deliberate extra step once you understand its conditions.