Is This Website Safe? What a Green Padlock Doesn't Tell You

You landed on a site, or maybe you're about to send someone else to yours, and the question is simple: is this website safe? You glance at the address bar. There's a padlock icon and "https" at the front of the URL. That usually feels like enough to move on.

It isn't enough, and the reason matters more if the site in question is an app you or someone you know built. The padlock tells you one specific, narrow thing about a connection. It says nothing about whether the people running that site can see your data, sell it, or accidentally leave it open to anyone who asks.

This post covers both halves of that question: what a padlock and a typical safe website checker actually verify (useful, and worth two minutes of your time on any site), and what they can never see, especially on apps built with AI tools on a backend like Firebase. That second part is where the real damage happens, and it's checkable in about the same amount of time.

⚡ TL;DR

• The padlock (HTTPS) proves your connection to the server is encrypted and the domain holds a valid certificate. It says nothing about whether the site is trustworthy or your data is protected once it arrives.
• Free certificates are available to anyone, including scam sites, so "https" alone is not proof of safety.
• On apps built with AI tools on Firebase, the apiKey you can see in the page source is public by design. It is not the leak.
• The real risk a padlock checker never sees is permissive Firebase Security Rules and open storage buckets, and you can check both yourself in a few minutes.

Is this website safe? What the padlock actually proves

HTTPS (the "s" is for secure) means the connection between your browser and the server is encrypted using TLS (Transport Layer Security). Nobody sitting on the same coffee shop Wi-Fi can read your traffic in plain text, and the certificate confirms the domain you're connected to is the one you typed.

That's a real, useful protection. It's also all it does. HTTPS does not check:

• Whether the site is a scam.
• Whether the company behind it handles your data responsibly.
• Whether the app has a bug that lets one user see another user's data.
• Whether the developer accidentally left a database wide open behind the scenes.

Certificate authorities like Let's Encrypt issue free, automated TLS certificates to anyone who controls a domain, including someone who registered a lookalike domain yesterday specifically to phish you. A scam site with a padlock is not a contradiction. It's the normal state of the modern web.

What a safe website checker actually tests

Most tools that answer "is this site safe" (malware blocklists, phishing databases, domain age lookups, SSL checks) are testing surface signals aimed at one job: catching sites built to deceive you on first contact. That's a real and worthwhile job. It's a different job from "is this app secure."

Those checkers were built for a web where most sites were static and mostly harmless once the scam and malware filters passed. They were not built for an app where an AI coding tool wired up a live database, file storage, and user accounts behind that same padlock. A padlock checker has no way to look inside that wiring, and neither does a human glancing at the address bar.

The apiKey isn't the leak: where Firebase risk actually lives

If your app (or the one you're evaluating) runs on Firebase, a common backend for apps built with tools like Lovable, Bolt, or Cursor, you can open the page source right now and find a block that looks like this:

const firebaseConfig = {
  apiKey: "AIzaSyC...",
  authDomain: "yourapp.firebaseapp.com",
  projectId: "yourapp",
  storageBucket: "yourapp.appspot.com",
};

🐺 Not a real problem

That apiKey is not a secret. It's a project identifier, meant to travel with your app's frontend code so requests reach the right Firebase project. Google ships it in plain view on purpose. If a scanner or a worried friend flags it as "exposed," that's a false alarm, not a finding. We cover exactly what it does and doesn't grant in our breakdown of whether a Firebase API key is safe to expose.

The real risk hides one layer deeper, in two places a padlock checker (and a glance at the page source) never reaches:

1. Firebase Security Rules. These decide, per collection or per file, who is allowed to read or write what. An AI tool building fast will often generate a rule that works in the demo and protects nothing, because it never had a reason to test it as an attacker would.
2. Storage buckets. Uploaded files (photos, ID documents, receipts) live under their own rules, separate from your database rules, and it's easy for a permissive default to slip through unnoticed.

For the fuller picture of how these two pieces fit together on an AI-built app, see Firebase security for AI-built apps.

How to check your own Firebase app

You can run a version of the "is this safe" question against your own app in about five minutes, and none of it requires reading code.

Check your Security Rules. Open the Firebase console, go to Firestore Database (or Realtime Database) → Rules. Look for anything shaped like this:

match /{document=**} {
  allow read, write: if true;
}

if true means "let anyone in," for every document, every time. That's the database equivalent of leaving your front door open with a sign that says come in. A working rule instead checks who's asking, for example:

match /users/{userId} {
  allow read, write: if request.auth.uid == userId;
}

Check your storage bucket. Find a file that belongs to a private, logged-in user (a profile photo, an upload), copy its direct URL, then open that exact URL in a private or incognito browser window while fully logged out. If the file loads, anyone with the link can see it, no account required.

Both of these are covered in more depth, including the specific rule patterns to avoid, in common Firebase Security Rules mistakes and Firebase storage security.

What happens when this check never runs

The Tea app breach in July 2025 is the clearest example of exactly this gap. An unsecured legacy Firebase storage bucket exposed roughly 72,000 images, including around 13,000 selfies and government ID photos, submitted for identity verification. A second breach at the same company exposed over 1.1 million private messages. Neither incident had anything to do with a padlock, a certificate, or a phishing database. A safe website checker would have shown a clean pass on both counts right up until the day the story broke. The full incident, and what changed because of it, is worth reading in the Tea app Firebase breach writeup.

That's the gap this whole post is about. The checks that stop a scam site from tricking you on arrival and the checks that stop your own app from leaking user data live in completely different places, and only one of them shows up as a padlock.

FAQ

Does a padlock mean a website is safe to use?

It means the connection is encrypted and the certificate matches the domain. It does not mean the company is trustworthy, that the site isn't a scam, or that your data is protected once it's stored. Treat it as one small, useful signal, not a verdict.

Can a scam or phishing site have HTTPS?

Yes. Free, automated certificates are available to anyone who controls a domain, including someone who registered it yesterday for a scam. HTTPS confirms encryption and domain ownership, not intent.

My scanner flagged my Firebase apiKey as exposed. Should I worry?

No. The Firebase web config, apiKey included, is public by design and meant to sit in your app's frontend code. Rotating it does nothing useful. The actual question to ask is whether your Security Rules and storage bucket restrict access to the right people, which is what actually determines who can read your data.

How do I know if my Firebase Security Rules are too permissive?

Open the Rules tab for each database and storage bucket in the Firebase console and look for if true or a missing condition entirely. Then confirm it in practice: try loading a private file's direct URL while logged out. If it opens, the rule isn't enforcing what you think it is.

The bottom line

Is this website safe is really two separate questions with two separate answers. The padlock answers whether your connection is encrypted, which it usually is, and says nothing about whether the app behind it protects your data. On Firebase-backed apps built with AI tools, the public apiKey is not the leak; permissive Security Rules and open storage buckets are, and they're invisible to every padlock checker. An attacker can find those gaps in minutes. The only real defense is checking them yourself first, on every deploy, because your AI ships new code, and occasionally a new hole, every time you ask it for a feature.