The Client SDK Model and Why Rules Matter

No API server in between

In a classic stack, the browser calls your API and your API talks to the database. With Firebase, the client SDK talks to Firestore, Storage and Auth directly over the network. That removes a lot of backend code, but it also means anyone can open dev tools, take your config and send their own requests. The only thing standing between those requests and your data is Security Rules (for Firestore, Realtime Database and Storage), plus App Check to reduce abuse from non-genuine clients. Code that must be trusted (payments, admin actions, secrets) belongs in Cloud Functions using the Admin SDK, which bypasses rules.

A direct client read

Modular SDK, TypeScript.

import { initializeApp } from "firebase/app";
import { getFirestore, doc, getDoc } from "firebase/firestore";

const app = initializeApp(firebaseConfig);
const db = getFirestore(app);

// This request goes straight from the browser to Firestore.
// Security Rules decide whether it is allowed.
const snap = await getDoc(doc(db, "profiles", "alice"));
if (snap.exists()) {
  console.log(snap.data());
}

Never ship open rules

Rules such as allow read, write: if true; (or test-mode rules with an expiry date) make your database public. Write real rules before you store real data.

Quick check: In a typical Firebase app, what protects Firestore data from a user who copies your web config?

• Security Rules evaluated on every client request
• Keeping the API key secret
• Minifying the JavaScript bundle
• Using HTTPS only