---
term: 'Klassenberechtigungen (CLP) und Schema-Sicherheit'
seoTitle: 'Klassenberechtigungen (CLP): Schema-Sicherheit erklärt'
headline: 'Was sind Klassenberechtigungen (CLP)?'
slug: klassenberechtigungen-clp
category: database
shortDefinition: 'Eine Klassenberechtigung ist eine Regel im Klassenschema, die steuert, welche Nutzer oder Rollen jede Operation dieser Klasse überhaupt ausführen dürfen.'
relatedTerms:
  - access-control-lists-acl
  - row-level-security
  - role-based-access-control-rbac
  - data-layer-vs-application-layer-security
  - visual-database-management
contrastsWith:
  - access-control-lists-acl
aboutTerms:
  - 'Class-Level Permissions (CLPs)'
  - 'Schema Security'
faq:
  - question: 'Was sind Klassenberechtigungen?'
    answer: 'Regeln am Schema einer Klasse (Tabelle/Collection), die steuern, welche Nutzer oder Rollen jede Operation – find, get, count, create, update, delete, add field – auf einem beliebigen Objekt dieser Klasse ausführen dürfen. Sie sind das gröbste Zugriffstor und das erste, das geprüft wird: Verweigert die Klassenregel eine Operation, wird nie eine Berechtigung pro Objekt herangezogen.'
  - question: 'Was ist der Unterschied zwischen CLP und ACL?'
    answer: 'Reichweite und Reihenfolge. Eine CLP beantwortet "wer darf diese Klasse überhaupt anfassen" – eine Regel für die ganze Tabelle. Eine ACL beantwortet "wer darf genau diese Zeile anfassen" – Daten, die jedes Objekt selbst trägt. Eine Anfrage muss beide Tore passieren: zuerst das Klassentor, dann das Objekttor, und jedes kann ablehnen. Grobe Linien auf Klassenebene, feines Korn auf Objektebene.'
  - question: 'Was ist requiresAuthentication?'
    answer: 'Die mittlere Einstellung zwischen öffentlich und namentlich genannten Rollen: Sie beschränkt eine Operation auf jeden angemeldeten Nutzer mit gültiger Session, ohne bestimmte Nutzer oder Rollen zu benennen. Für die meisten Anwendungsdaten ist das der richtige Standard – anonyme Anfragen werden abgewiesen, während jeder authentifizierte Nutzer das Klassentor passiert und zu den ACL-Prüfungen pro Objekt weitergeht.'
  - question: 'Was sind Pointer Permissions?'
    answer: 'Regeln auf Klassenebene, die an ein Pointer-Feld auf einen Nutzer im Objekt gebunden sind – zum Beispiel "nur der Nutzer im Feld owner darf lesen oder schreiben". Sie wirken wie eine virtuelle ACL: Die Durchsetzung erfolgt pro Objekt, die Regel wird aber einmal im Schema deklariert statt auf jeder Zeile gespeichert. Sie überschneiden sich mit echten ACLs; beide müssen die Aktion erlauben.'
  - question: 'Was sind geschützte Felder (protected fields)?'
    answer: 'Regeln auf Feldebene, gelegt über das Klassentor: Bestimmte Spalten – eine E-Mail-Adresse, eine interne Bewertung – bleiben für manche Anfragenden verborgen, während der Rest des Objekts lesbar bleibt. Sie machen aus der Berechtigungsleiter drei Sprossen an einem Schema: Operationen für die ganze Klasse, Zugriff pro Objekt und Sichtbarkeit pro Feld.'
  - question: 'Was ist das SQL-Äquivalent von Klassenberechtigungen?'
    answer: 'Tabellen- und Schema-Privilegien: GRANT SELECT, INSERT, UPDATE, DELETE ON eine Tabelle an eine Rolle, REVOKE zum Entziehen, dazu die Rechte USAGE und CREATE auf Schemaebene. Das Konzept lässt sich eins zu eins übertragen – ein GRANT auf Tabellenebene ist eine Klassenberechtigung mit anderer Syntax – und Dokumentdatenbanken bilden es mit Rollen ab, die auf Aktionen einer Collection beschränkt sind.'
  - question: 'Sollten Clients in Produktion Felder hinzufügen oder Klassen anlegen dürfen?'
    answer: 'Nein – das ist der Härtungsschritt, über den Einigkeit herrscht. Schema-Flexibilität ist eine Entwicklungsbequemlichkeit; in Produktion deaktivieren Sie die Berechtigung "add field" auf jeder Klasse und schalten die Klassenerstellung durch Clients vollständig ab, womit das Schema gegenüber Clients eingefroren ist. Schemaänderungen laufen dann über das Dashboard oder serverseitigen Code, wo sie hingehören.'
  - question: 'Reichen Klassenberechtigungen aus, um eine App abzusichern?'
    answer: 'Sie sind die erste Schicht, nicht die ganze Verteidigung. Der übliche Stack: CLPs kontrollieren Operationen pro Klasse, ACLs oder Pointer Permissions grenzen Zeilen ein, geschützte Felder verbergen sensible Spalten, und serverseitige Trigger validieren Schreibzugriffe. Und eine Regel über allen: Der Master Key – der jedes Tor umgeht – landet niemals im Client-Code.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Backend security guide'
    url: 'https://docs.parseplatform.org/parse-server/guide/#security'
  - name: 'PostgreSQL GRANT reference'
    url: 'https://www.postgresql.org/docs/current/sql-grant.html'
  - name: 'MongoDB collection-level access control'
    url: 'https://www.mongodb.com/docs/manual/core/collection-level-access-control/'
  - name: 'Back4app app security guidelines'
    url: 'https://www.back4app.com/docs/security/parse-security'
cta:
  title: 'Schema-Sicherheit per Schalter, nicht per Policy'
  text: 'Auf Back4app sind Klassenberechtigungen Häkchen im Dashboard: eine Klasse sperren, Authentifizierung verlangen, Operationen auf Rollen begrenzen, Felder schützen – serverseitig bei jeder Anfrage durchgesetzt, darunter geschichtet die ACLs pro Objekt.'
  linkText: 'Kostenlos starten'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-24'
translationKey: class-level-permissions-clp
---

**Eine Klassenberechtigung ist eine Regel im Klassenschema, die steuert, welche Nutzer oder Rollen jede Operation dieser Klasse überhaupt ausführen dürfen.** Sie ist das äußerste Tor der Sicherheit in der Datenschicht: Bevor irgendeine Prüfung pro Zeile stattfindet, entscheidet die Klasse selbst, ob dieser Aufrufer hier suchen, anlegen, ändern oder löschen darf – eine Regel, die ganze Tabelle, zuerst geprüft.

## Das Wichtigste in Kürze

| Frage | Antwort |
| --- | --- |
| Was es ist | Zugriffsregeln pro Operation auf der Klasse (Tabelle) selbst |
| vs. ACLs | CLP kontrolliert die Klasse; ACLs kontrollieren jede Zeile – beides muss passiert werden |
| Die Operationen | Find, get, count, create, update, delete, add field – jede einzeln gesetzt |
| Die goldenen Standards | Authentifizierung verlangen, add field sperren, den Master Key nie ausliefern |
| SQL-Verwandter | `GRANT`/`REVOKE` auf Tabellen und Schemas – gleiche Idee, andere Syntax |

## Das Klassentor, deklariert und erlebt

Eine CLP ist Schemakonfiguration – hier als REST-Payload, das eine Klasse `Config` auf öffentliches Lesen und serverseitiges Schreiben festlegt:

```text
PUT /schemas/Config
{
  "classLevelPermissions": {
    "find":   { "*": true },              // jeder darf abfragen
    "get":    { "*": true },
    "create": {},                         // niemand von der Client-Seite
    "update": { "role:admin": true },     // nur Admins
    "delete": {},
    "addField": {}                        // Schema eingefroren
  }
}
```

Was Clients erleben, ist das Tor bei der Arbeit – Lesezugriffe laufen durch, Schreibzugriffe sterben an der Klassengrenze, bevor auch nur ein Datum angefasst wird:

**JavaScript:**

```javascript
// 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
// 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
}
```

**Swift:**

```swift
// 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
  }
}
```

**Kotlin:**

```kotlin
// 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
  }
}
```

## Wie Klassenberechtigungen und ACLs zusammenwirken

```mermaid
flowchart LR
  accTitle: Wie Klassenberechtigungen und ACLs zusammenwirken
  accDescr: Jede Anfrage passiert zuerst das Tor der Klassenberechtigungen für ihre Operation; nur wenn die Klasse sie zulässt, wird die ACL des Objekts herangezogen, und jedes der beiden Tore kann die Anfrage ablehnen.
  R["Anfrage:<br/>Objekt X in Klasse C ändern"] --> G1{"Klassentor (CLP):<br/>darf dieser Aufrufer<br/>Klasse C ändern?"}
  G1 -- nein --> D["Abgelehnt – 119"]
  G1 -- ja --> G2{"Objekttor (ACL):<br/>darf dieser Aufrufer<br/>Objekt X schreiben?"}
  G2 -- nein --> D2["Abgelehnt – Objekt verborgen"]
  G2 -- ja --> A["Erlaubt"]
```

## Die Granularitätsleiter: CLP vs. ACL vs. Pointer Permissions vs. geschützte Felder

| Mechanismus | Reichweite | Deklariert wo | Geprüft | Typische Aufgabe |
| --- | --- | --- | --- | --- |
| Klassenberechtigung | Ganze Klasse, pro Operation | Schema | Zuerst | "Clients schreiben nie in `Config`" |
| Pointer Permission | Pro Objekt, über eine Schemaregel | Schema (an ein Feld gebunden) | Danach | "Nur der `owner` fasst seine Zeilen an" |
| ACL | Pro Objekt | Auf jeder Zeile, als Daten | Danach | "Diese Notiz: nur ihr Autor" |
| Geschützte Felder | Pro Spalte | Schema | Beim Lesen | "`email` vor anderen Nutzern verbergen" |

Daraus folgt die Entwurfsregel: **grobe Linien im Schema, feines Korn in den Zeilen.** Klassen mit einheitlicher Zugriffsregel (Konfiguration, Kataloge, Logs) brauchen nur das Klassentor; Klassen mit Daten pro Nutzer ergänzen darunter ACLs oder Pointer Permissions.

## Dasselbe Tor in anderen Engines

```sql
-- PostgreSQL: Tabellenprivilegien sind CLPs unter anderem Namen
GRANT SELECT ON films TO PUBLIC;
GRANT INSERT, UPDATE ON films TO role_editor;
REVOKE ALL ON launch_codes FROM PUBLIC;
```

Dokumentdatenbanken bilden es mit [Rollen ab, die auf Aktionen einer Collection beschränkt sind](https://www.mongodb.com/docs/manual/core/collection-level-access-control/) – eine Rolle mit find und insert auf genau einer Collection. Das Konzept ist universell; was sich unterscheidet, ist die Ergonomie: SQL-GRANTs und Rollendokumente werden im Code verwaltet, während BaaS-Plattformen dieselbe Matrix als Schalter im Dashboard anbieten.

## Empfohlene Einstellungen nach Inhaltstyp

| Inhaltstyp | Find/Get | Create | Update/Delete | Add field |
| --- | --- | --- | --- | --- |
| Öffentliche Inhalte (Katalog, Beiträge) | Öffentlich | Rollen/Server | Rollen/Server | Aus |
| Nutzereigene Daten (Notizen, Bestellungen) | Authentifiziert + ACLs | Authentifiziert | Per ACL begrenzt | Aus |
| Konfiguration und Flags | Öffentlich oder authentifiziert | Niemand (nur Server) | Admin-Rolle | Aus |
| Logs und Analytics | Niemand (nur Server) | Authentifiziert (nur schreiben) | Niemand | Aus |
| Nur für Admins | Admin-Rolle | Admin-Rolle | Admin-Rolle | Aus |

Diese Tabelle ist die Checkliste, die die meisten Markteinführungen tatsächlich brauchen – beachten Sie die Konstante in der letzten Spalte und ihre Schwesterregel: clientseitige Klassenerstellung in Produktion aus, damit sich das Schema nur absichtlich ändert.

## Typische Anwendungsfälle

- **Produktionsschemas einfrieren.** Add field überall aus; Klassen tauchen nicht mehr durch Client-Verkehr auf und verändern sich nicht mehr dadurch.
- **Referenzdaten nur zum Lesen.** Kataloge und Einstellungen öffentlich lesbar, beschreibbar nur durch Servercode – das `Config`-Muster von oben.
- **Postfächer nur zum Schreiben.** Klassen für Feedback und Telemetrie, in die Clients anlegen, aber niemals lesen dürfen – das umgekehrte Tor, das Code in der Anwendungsschicht gern vergisst.
- **Adminbereiche nach Rollenstufen.** Update und delete einer Admin-Rolle vorbehalten, während die App frei liest.
- **Abwehr des klassischen Datenabzugs.** Der berüchtigte Einzeiler – ein curl mit einer App-ID gegen eine offene `User`-Klasse – stirbt am find-Tor, sobald die Klasse Authentifizierung verlangt.

## Klassentor oder Servercode? Eine Entscheidungsmatrix

| Mit CLPs (+ ACLs) durchsetzen, wenn … | Über Servercode leiten, wenn … |
| --- | --- |
| Die Regel lautet "wer darf was, wo" | Die Regel Geschäftslogik braucht ("nur vor dem Versand der Bestellung") |
| Sie pro Klasse oder pro Eigentümer einheitlich ist | Sie mehrere Objekte oder Klassen umspannt |
| Sie auf jedem Pfad gelten soll, auch für neue Clients | Sie einen geprüften Engpass für einen sensiblen Ablauf wollen |
| Deklarativ bei der Durchsicht besser ist als imperativ | Validierung, Anreicherung oder Seiteneffekte mitlaufen |
| Der Schalter im Dashboard die ganze Spezifikation ist | Die Spezifikation ein Absatz voller Bedingungen ist |

Beides ergänzt sich: Das gehärtete Muster für wirklich sensible Klassen sperrt die CLPs vollständig und stellt serverseitige Funktionen als einzige Tür bereit – das Klassentor garantiert, dass niemand um den Engpass herumläuft.

## Grenzen und Trade-offs

- **Klassengranularität ist per Definition grob.** Alles pro Zeile gehört zu ACLs und Pointer Permissions; alles Bedingte gehört in serverseitige Validierung – CLPs kontrollieren, sie schlussfolgern nicht.
- **Die Standardwerte sind für die Entwicklung großzügig.** Neue Klassen kommen offen zur Welt, damit Prototypen schnell entstehen; der Durchgang vor dem Start, der die obige Tabelle umsetzt, ist Disziplin, kein Automatismus.
- **Der Master Key ignoriert alles.** Jedes Tor in diesem Artikel ist wirkungslos, wo dieser Schlüssel hinkommt – deshalb lebt er ausschließlich serverseitig, wird pro Operation eingesetzt und niemals ausgeliefert.
- **Die Durchsetzungsfläche muss vollständig sein.** Echtzeit-Abonnements und Spezial-Endpoints hatten in der Vergangenheit Lücken in der Durchsetzung – halten Sie die Plattform aktuell und testen Sie die Tore von einem echten Client aus, nicht nur aus dem Dashboard.
- **Auch Schalter brauchen eine Durchsicht.** Deklarative Sicherheit ist nur dann prüfbare Sicherheit, wenn jemand sie prüft – die Einstellungsmatrix gehört in Ihre Startcheckliste, nicht in mündlich überliefertes Wissen.

## Klassenberechtigungen mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Klassenberechtigungen sind die sichtbar gemachte Oberfläche ihrer Schema-Sicherheit: Jede Klasse im Dashboard trägt die Operationsmatrix als Häkchen – öffentlich, requiresAuthentication, pro Rolle – dazu Pointer Permissions und geschützte Felder, [serverseitig bei jeder Anfrage durchgesetzt](https://docs.parseplatform.org/parse-server/guide/#security), über SDKs, REST und GraphQL gleichermaßen. Darunter sitzen die ACLs pro Objekt, darüber Cloud-Code-Trigger für die Regeln, die Logik brauchen. Die [Sicherheitsrichtlinien](https://www.back4app.com/docs/security/parse-security) führen durch den vollständigen Durchgang vor dem Start – die Einstellungsmatrix aus diesem Artikel, Klick für Klick angewendet.