APIs Are Not Optional | Thomas Panzeri

Modern application development often feels like a race. Build faster. Ship sooner. Iterate constantly. In this rush, platforms like Firebase and Supabase offer a tempting shortcut: they promise you don’t need to worry about backend infrastructure. Just connect your app directly to the database, toss some rules on top, and you’re done.

But there’s a fundamental flaw in that mindset—and it’s not just theoretical. It’s a live, painful lesson that real companies and real users are learning the hard way.

🚨 What Just Happened: The T App Breach

Take the example of T, a women-only app that required strict identity verification. Users submitted sensitive documents—selfies, IDs, and more—thinking their data would be safe. Instead, these were dumped into a Firebase Storage bucket… that was public.

That’s right. Sensitive files, including PII and embedded metadata, were exposed because of how Firebase defaults are set up and how its APIs are often used: insecurely, without a proper permission layer or even access isolation.

All it took was someone finding a publicly accessible endpoint, listing all file URLs, and downloading the entire trove. It wasn’t a deep hack. It was negligence. And worse, it was predictable.

Why APIs Are Needed: A Real Architecture Lesson

At the heart of this disaster is a misunderstanding of how software should be structured. Here’s what good infrastructure looks like:

User → API → Database
Each request is authenticated, validated, and authorized before data access.
Business logic lives in the server, not in the client.

The API is a gatekeeper. It’s where:

Permissions are enforced.
Logs are generated.
Input is sanitized.
Rate limits are applied.

When you skip this layer—when users talk directly to your database—you lose all of that. Firebase and Supabase sell you this shortcut. And unless you’re hyper-aware of the risks (and deeply experienced), it will betray you.

Firebase & Supabase: The Problems

Let’s break down what makes these tools dangerous in the hands of most developers:

1. Exposed by Default

Firebase buckets and Firestore databases are often readable by unauthenticated users unless you explicitly lock them down. Supabase, while slightly more opinionated, still pushes devs toward directly querying the database from the frontend.

2. No Real API Layer

These platforms blur the lines between a database and an API. That’s a mistake. Permissions, validation, logging—those belong in code, not in rules or roles duct-taped to your data model.

3. Security Theater

Row-level security or client-based permission rules sound great in theory, but they:

Are hard to reason about.
Are often incomplete.
Are rarely tested like traditional server logic.

Most importantly: they hide complexity instead of exposing it. And that’s dangerous.

4. Bad Defaults, Worse Habits

Because Firebase and Supabase lower the barrier to entry, they attract developers who may not yet understand backend principles—and who may never learn them because the platform abstracts everything away.

This leads to an ecosystem full of “vibe-coded” apps: they work, until they don’t. Then they explode in ways that destroy user trust—and sometimes entire companies.

Lessons From the T App Leak

Let’s be brutally clear:

Nothing was “hacked.” The system was simply left unlocked. That’s not sophisticated—it’s tragic.
Metadata wasn’t stripped. Even if the files hadn’t been public, EXIF and location data were leaking by default.
APIs weren’t used. The app relied on Firebase’s exposed storage and Firestore APIs without a custom backend to mediate access.
Responsibility lies in the architecture. Firebase didn’t leak the data. The people who misused it did. But Firebase made it easy to make those mistakes.

This wasn’t an isolated incident. Similar misconfigurations have led to over 125 million accounts being exposed across 900+ Firebase-backed apps, many of them built by mobile developers or startups looking for shortcuts.

The Core Takeaway: Write Your APIs

If you’re building a product, here’s the hard truth:

You cannot avoid backend code. If you try to, you are building your app on a trapdoor.

Write server-side logic. Create real API endpoints. Define access rules in your code—not in your database. Store files securely, with signed URLs, expiration logic, and proper authentication.

There are modern tools that help with this:

Convex: serverless backend with enforced function-based access.
tRPC + Next.js: full-stack TypeScript with strict types and API layers.
Go, Node, Python backends: proven, production-ready tools that teach you the discipline of secure development.

Final Word

APIs are not overhead. They are the architecture. If you’re skipping them, you’re not building software. You’re building a liability.

Firebase and Supabase aren’t inherently evil—but they are dangerous if you don’t know what you’re doing. They trade short-term speed for long-term risk. And if your app handles real users, real money, or real identity data, that’s a trade you cannot afford to make.