I hear this one from founders more than almost any other line: "we're secure, we use HTTPS." It's said with real confidence, usually because a browser shows a little padlock icon and that icon feels like a stamp of approval. It's not wrong exactly. It's just answering a completely different question than the one that actually matters.
What HTTPS actually does
HTTPS encrypts the connection between someone's browser and your server. That's it. It stops a third party sitting on the same coffee shop WiFi from reading the raw traffic between you and your visitor, or quietly swapping in different content along the way. That's genuinely useful. Nobody should ship a public app without it.
But encrypting the pipe says nothing about what's flowing through it, or who's allowed to ask for what. HTTPS protects data in transit. It has no opinion at all about data at rest, about who can query your database, or about whether an endpoint checks who's asking before handing back an answer.
Where the confusion actually costs people
A locked, encrypted connection to a wide-open database is still a wide-open database. If your app has no row-level security or equivalent access rules, HTTPS will faithfully and securely deliver every other user's private data straight to whoever asks for it, over a perfectly encrypted connection. The padlock icon has nothing to say about that, and neither does the person who told you HTTPS was the whole job.
Same story with authentication. HTTPS doesn't check whether a login form actually gates anything, whether an admin route requires a real session, or whether the API underneath a protected page enforces the same rule the page does. All of that logic lives entirely in your application code and your database configuration. Encryption in transit and access control are two completely separate layers, and only one of them is handled for you by default.
A quick way to tell the two apart
Ask yourself: if someone sat directly between me and my server and intercepted every packet, could they read anything useful? That's the question HTTPS answers, and for most modern hosting it's already handled. Now ask a second, unrelated question: if someone simply asked my server for data they shouldn't have, with no interception involved at all, would my server say no? That's an access control question, and it's the one that actually decides whether your app is safe. HTTPS has no vote in that answer.
Both matter. Only one of them comes free with a hosting checkbox. The other one is a set of decisions you, or whoever built your backend, actually has to make on purpose, table by table, route by route.