New CS proposal: Client-Direct Backend (BaaS) Security Cheat Sheet

What is the proposed Cheat Sheet about?

A vendor-neutral security guide for applications where untrusted browser or mobile clients call managed database, storage, realtime, authentication, or function APIs directly.

These platforms share a distinct trust model:

• a publishable project identifier or client key selects the backend;
• declarative row, document, record, or resource policies become the primary authorization boundary; and
• a separate server or administrative credential intentionally bypasses ordinary client policies.

The proposed sheet would call this architecture a client-direct backend and use Backend as a Service (BaaS) as the familiar category name. Supabase, Firebase, Appwrite, and PocketBase would be evidence and examples, not vendor-specific recommendations.

What security issues are commonly encountered related to this area?

• Treating a publishable client identifier as a secret instead of relying on complete authorization policies.
• Exposing a privileged server, service-role, administrative, or superuser credential to client code.
• Missing or overly broad policies on newly added tables, collections, buckets, files, realtime channels, functions, or remote procedure calls.
• Trusting client-supplied owner IDs, tenant IDs, roles, or mutable profile metadata.
• Authorizing reads while failing to constrain creates, updates, deletes, or changed ownership fields.
• Assuming database policies automatically protect storage, realtime, authentication administration, functions, and management APIs.
• Using privileged server clients without performing the application authorization that the bypassed policy would otherwise enforce.
• Treating policy rules as filters when a platform instead rejects a query whose potential result is broader than the rule permits.
• Failing to test anonymous, user-A/user-B, cross-tenant, deleted-user, and privileged-client negative paths.
• Letting schema or resource changes reach production without a policy classification, coverage check, or deployment-drift check.
• Relying on application attestation, rate limits, or an unguessable project URL as a replacement for authentication and authorization.
• Cross-environment credential reuse, bulk data extraction, function-trigger amplification, and billing/resource abuse.

What is the objective of the Cheat Sheet?

Give developers a concise architecture-first method to secure this model:

• map every client-accessible backend surface and its policy engine;
• distinguish publishable identifiers from privileged credentials by capability rather than by naming;
• treat policies as production authorization code: deny by default, version control them, review them, and deploy them with the application;
• keep user-context and privileged clients separate, with explicit authorization before every privileged operation;
• test an authorization matrix covering anonymous users, multiple users and tenants, mutation attempts, and administrative paths;
• discover newly exposed resources and fail when they have no explicit policy classification;
• verify that database, storage, realtime, function, and management controls do not drift independently;
• separate development, preview, and production projects, data, policies, and credentials; and
• cover abuse limits without presenting them as substitutes for access control.

The sheet would link to existing OWASP guidance rather than repeat generic authorization, tenant-isolation, database, authentication, or serverless advice. It would favor architectural controls and small test matrices over vendor-specific code snippets.

What other resources exist in this area?

The common architecture is documented independently by the major platforms:

• Supabase: Securing your data explains client-direct Data API access, Row Level Security (RLS), publishable keys, and privileged keys that bypass RLS.
• Supabase: API keys distinguishes public-component keys from server-controlled credentials and documents their Postgres roles.
• Firebase Security Rules describes separate policy enforcement for database and storage products and recommends emulator testing.
• Firebase: Securely validate app identity with App Check explains that app attestation complements rather than replaces authentication.
• Appwrite permissions documents client resource permissions and the different capability of scoped server API keys.
• PocketBase API rules and filters documents collection rules and the authenticated-superuser bypass.

Relevant OWASP sheets cover adjacent principles:

• Authorization Cheat Sheet
• Database Security Cheat Sheet
• Multi-Tenant Security Cheat Sheet
• Serverless FaaS Security Cheat Sheet

None centers the client-policy-privileged-client triangle, cross-service policy coverage, or the testing and deployment lifecycle for a client-direct backend. I found no existing sheet, draft, open issue, or pull request for BaaS, Supabase, Firebase, Appwrite, PocketBase, or PostgREST in this repository.

If this scope is suitable, I am happy to draft one focused sheet after acknowledgment and adjust the title or boundaries before implementation.

---

Disclosure: I used OpenAI Codex (GPT-5) to help survey the current repository, compare the adjacent OWASP sheets, inspect the platform documentation linked above, and draft this proposal. I verified the sources and claims before posting.