What are Class-Level Permissions (CLPs)?

A class-level permission is a rule on a class schema that controls which users or roles may run each operation on that class at all. It’s the outermost gate of data-layer security: before any per-row check happens, the class itself decides whether this caller may find, create, update, or delete here — one rule, whole table, checked first.

Key takeaways

The class gate, declared and felt

A CLP is schema configuration — here as the REST payload that locks a Config class to public-read, server-only-write:

PUT /schemas/Config
{
  "classLevelPermissions": {
    "find":   { "*": true },              // anyone may query
    "get":    { "*": true },
    "create": {},                         // nobody from the client side
    "update": { "role:admin": true },     // admins only
    "delete": {},
    "addField": {}                        // schema frozen
  }
}

What clients experience is the gate doing its job — reads flow, writes die at the class boundary before any data is touched:

// JavaScript / Node.js — Back4app JS SDK
// The class gate in action: Config is read-only for clients (CLP),
// so reads succeed and writes never reach the data
const config = await new Parse.Query('Config').first(); // ✓ public read

const c = new Parse.Object('Config');
c.set('flag', true);
try {
  await c.save(); // ✗ CLP blocks client writes to this class entirely
} catch (e) {
  console.log(e.code); // 119: operation forbidden by class-level permissions
}

// Flutter / Dart — Back4app Flutter SDK
// The class gate in action: reads allowed, client writes blocked by CLP
final config = ParseObject('Config')..set('flag', true);
final response = await config.save();
if (!response.success) {
  print(response.error?.code); // 119: forbidden by class-level permissions
}

// iOS / Swift — Back4app Swift SDK
// The class gate in action: reads allowed, client writes blocked by CLP
var config = Config()
config.flag = true
config.save { result in
  if case .failure(let error) = result {
    print(error) // operation forbidden by class-level permissions
  }
}

// Android / Kotlin — Back4app Android SDK
// The class gate in action: reads allowed, client writes blocked by CLP
val config = ParseObject("Config").apply { put("flag", true) }
config.saveInBackground { e ->
  if (e != null) {
    Log.d("CLP", "blocked: ${e.code}") // forbidden by class-level permissions
  }
}

How Class-Level Permissions and ACLs Work Together

The granularity ladder: CLP vs. ACL vs. pointer permissions vs. protected fields

The design idiom that falls out: broad strokes on the schema, fine grain on the rows. Classes whose access rule is uniform (config, catalogs, logs) need only the class gate; classes with per-user data add ACLs or pointer permissions beneath it.

The same gate in other engines

-- PostgreSQL: table-level privileges are CLPs by another name
GRANT SELECT ON films TO PUBLIC;
GRANT INSERT, UPDATE ON films TO role_editor;
REVOKE ALL ON launch_codes FROM PUBLIC;

Document databases mirror it with roles scoped to collection-level actions — a role granted find-and-insert on exactly one collection. The concept is universal; what differs is ergonomics: SQL grants and role documents are administered in code, while BaaS platforms surface the same matrix as dashboard toggles.

Recommended settings by content type

That table is the checklist most launches actually need — note the constant in the last column, and its sibling rule: client-side class creation off in production, so the schema only changes on purpose.

Common use cases

• Freezing production schemas. Add-field off everywhere; classes stop appearing and mutating from client traffic.
• Read-only reference data. Catalogs and settings publicly readable, writable only by server code — the Config pattern above.
• Write-only inboxes. Feedback and telemetry classes clients may create into but never read — the inverse gate app-layer code often forgets.
• Role-tiered admin surfaces. Update and delete reserved to an admin role while the app reads freely.
• Defense against the classic dump. The infamous one-liner — a curl with an app ID querying an open User class — dies at the find gate when the class requires authentication.

Should the class gate or server code enforce it? A decision matrix

They compose: the hardened pattern for genuinely sensitive classes locks the CLPs entirely and exposes server-side functions as the only doorway — the class gate guarantees nobody walks around the chokepoint.

Limitations and trade-offs

• Class granularity is coarse by definition. Anything per-row belongs to ACLs and pointer permissions; anything conditional belongs in server-side validation — CLPs gate, they don’t reason.
• Defaults are permissive for development. New classes are born open so prototypes fly; the pre-launch pass that flips the table above is a discipline, not an automatism.
• The master key ignores everything. Every gate in this article is void wherever that key travels — which is why it lives server-side only, used per-operation, never shipped.
• Enforcement surface must be complete. Real-time subscriptions and special endpoints have historically had enforcement gaps — keep the platform updated, and test the gates from a real client, not just the dashboard.
• Toggles need review too. Declarative security is auditable security only if someone audits it — the settings matrix belongs in your launch checklist, not in tribal memory.

CLPs on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. Class-level permissions are its schema-security surface made visual: every class in the dashboard carries the operations matrix as checkboxes — public, requires-authentication, per-role — plus pointer permissions and protected fields, enforced server-side on every request across SDKs, REST, and GraphQL alike. Underneath sit per-object ACLs; above sit Cloud Code triggers for the rules that need logic. The security guidelines walk the full pre-launch pass — the settings matrix in this article, applied click by click.