Admin / Server SDKs Bypass Security Rules: Service Account Least Privilege and Application-Layer Authorization

1. The dangerous misconception: “Admin means trusted, therefore safe”

Admin/server libraries are trusted by Firestore in the narrow sense that Security Rules are not evaluated. That is not evidence that every caller of AtlasMart’s backend deserves every database action. If the orders API can update any order and the API simply forwards req.body.path and req.body.data, a single application authorization bug converts the service account’s IAM scope into an attacker’s write scope.

Learning outcomes

2. Least privilege has two dimensions

Cloud least privilege limits what the workload principal can do to Google Cloud resources. Application least privilege limits what a verified user may ask that workload to do. Firestore IAM roles operate at resource/API permission scope; they do not encode AtlasMart’s customerId, tenant refund policy, order state machine, or fraud review.

3. Build the privileged refund endpoint as a narrow capability

// Never ship this module to a browser bundle.process.env.FIRESTORE_EMULATOR_HOST = "127.0.0.1:8080";process.env.FIREBASE_AUTH_EMULATOR_HOST = "127.0.0.1:9099";process.env.GCLOUD_PROJECT = "demo-atlasmart-firestore";import { initializeApp } from "firebase-admin/app";import { getAuth } from "firebase-admin/auth";import { getFirestore } from "firebase-admin/firestore";initializeApp({ projectId: "demo-atlasmart-firestore" });export const adminAuth = getAuth();export const adminDb = getFirestore();

export async function verifiedActor(adminAuth, authorizationHeader) {  const prefix = "Bearer ";  if (!authorizationHeader?.startsWith(prefix)) {    throw Object.assign(new Error("UNAUTHENTICATED"), { status: 401 });  }  const idToken = authorizationHeader.slice(prefix.length);  const decoded = await adminAuth.verifyIdToken(idToken);  return {    uid: decoded.uid,    tenantId: decoded.tenantId,    role: decoded.role,    authTime: decoded.auth_time  };}export function authorizeRefund(actor, order) {  if (actor.tenantId !== order.tenantId) {    throw Object.assign(new Error("CROSS_TENANT"), { status: 403 });  }  if (!["support", "admin"].includes(actor.role)) {    throw Object.assign(new Error("ROLE_REQUIRED"), { status: 403 });  }  if (order.status !== "PAID") {    throw Object.assign(new Error("ORDER_NOT_REFUNDABLE"), { status: 409 });  }}

import { adminAuth, adminDb } from "./admin.js";import { verifiedActor, authorizeRefund } from "./authorize.js";import { auditAuthorization } from "./audit.js";export async function refundOrder({ authorization, orderId, correlationId }) {  const actor = await verifiedActor(adminAuth, authorization);  const ref = adminDb.doc(`orders/${orderId}`);  const snap = await ref.get();  if (!snap.exists) throw Object.assign(new Error("NOT_FOUND"), { status: 404 });  const order = snap.data();  try {    authorizeRefund(actor, order);    auditAuthorization({      correlationId, actor, action: "order.refund",      resource: ref.path, outcome: "allow", reason: "policy_passed"    });  } catch (error) {    auditAuthorization({      correlationId, actor, action: "order.refund",      resource: ref.path, outcome: "deny", reason: error.message    });    throw error;  }  // Chapter 9/10 invariants still apply: use transaction/precondition/idempotency  // if concurrent state or external payment side effects are involved.  await ref.update({ status: "REFUNDED" });  return { orderId, status: "REFUNDED" };}

export function auditAuthorization({ correlationId, actor, action, resource, outcome, reason }) {  console.log(JSON.stringify({    event: "authorization_decision",    correlationId,    actorUid: actor?.uid ?? null,    actorTenantId: actor?.tenantId ?? null,    actorRole: actor?.role ?? null,    action,    resource,    outcome,    reason,    // Deliberately omitted: ID token, refresh token, Authorization header,    // service-account private keys, ADC credential material.    at: new Date().toISOString()  }));}

This endpoint exposes one business operation rather than a generic Firestore proxy. The service account may technically write many documents, but the code narrows what users can ask it to do. That separation also makes authorization tests readable.

4. Deliberate failure: a generic Admin proxy defeats your Rules design

// DANGEROUS: verified identity is not enough.export async function updateAnything(req) {  const actor = await verifiedActor(adminAuth, req.headers.authorization);  console.log("authenticated", actor.uid);  await adminDb.doc(req.body.path).update(req.body.patch);}

An ordinary customer could request orders/o-9001 with {"status":"REFUNDED"}. Security Rules cannot save this code because the Admin write bypasses them. The safe repair is to expose purpose-specific commands such as refundOrder, derive target paths from validated identifiers, and authorize against authoritative server data.

5. IAM roles are capabilities, not business roles

PROJECT_ID="YOUR_ISOLATED_PROJECT"SA="atlasmart-orders-api@${PROJECT_ID}.iam.gserviceaccount.com"# Create one workload identity for one service responsibility.gcloud iam service-accounts create atlasmart-orders-api   --project="$PROJECT_ID"   --display-name="AtlasMart orders API"# roles/datastore.user permits Firestore entity read/write operations.# It is still broader than per-customer authorization; application code must enforce that.gcloud projects add-iam-policy-binding "$PROJECT_ID"   --member="serviceAccount:${SA}"   --role="roles/datastore.user"# Inspect exactly what the principal has before deployment.gcloud projects get-iam-policy "$PROJECT_ID"   --flatten="bindings[].members"   --filter="bindings.members:serviceAccount:${SA}"   --format="table(bindings.role)"

6. One workload identity per responsibility limits blast radius

Suppose AtlasMart deploys an orders API, a reporting job and an index-deployment job. Reusing one highly privileged service account means compromise of the reporting job can mutate orders and manage indexes. Separating identities permits a read-only reporting principal and keeps operational roles away from request-serving workloads. The design objective is not “many service accounts”; it is independent revocation and minimum permissions aligned with service responsibilities.

7. Observability: preserve two actors

A backend log should preserve the end-user actor and the workload executor as separate concepts. Cloud Audit Logs can identify the Google Cloud principal for supported production actions; AtlasMart application logs must add the verified user UID/tenant/role and the business reason. Never put raw credentials in either.

{  "event": "authorization_decision",  "correlationId": "corr-7f8c",  "actorUid": "u-support-1",  "actorTenantId": "t-atlas",  "actorRole": "support",  "workload": "atlasmart-orders-api",  "action": "order.refund",  "resource": "orders/o-9001",  "outcome": "allow",  "reason": "policy_passed"}

8. Verification matrix

Production judgment and bridge to Lesson 3

IAM limits what a service can technically do; application authorization limits what a caller can cause it to do. Neither replaces the other. Keep service identities narrow, avoid primitive roles, and design privileged APIs as business capabilities rather than generic database tunnels. Lesson 3 now examines the user-side role signal—custom claims—and why token refresh and revocation make them unsuitable as an instant, rapidly changing authorization database.

Knowledge check

1. Why can a customer exploit a generic Admin proxy even if Firestore Rules are perfect?
2. What is the difference between roles/datastore.user and an AtlasMart support role?
3. Why is one service account for every backend a blast-radius problem?
4. Can the emulator prove a production IAM binding?
5. What should privileged APIs expose instead of arbitrary document paths?

Summary

The Admin SDK is powerful because it bypasses client Rules. That power is safe only when the workload principal is least-privileged and every user-driven privileged operation has an independent application authorization decision.

Authoritative references

• Secure data in Cloud Firestore
• Firestore IAM
• Security Rules conditions and server-library bypass
• Add the Firebase Admin SDK to your server
• Verify Firebase ID tokens
• Custom claims and access control
• Manage user sessions and token revocation
• Connect to the Authentication emulator
• Connect to the Firestore emulator
• How Application Default Credentials works
• Best practices for service accounts
• Workload Identity Federation
• Firestore IAM roles and permissions
• Authenticate and connect with Firestore MongoDB compatibility
• Enterprise Native server client libraries
• Firebase Admin Node.js SDK release notes
• Firebase CLI release notes