Que sont les permissions au niveau de la classe (CLP) ?

Une permission au niveau de la classe est une règle du schéma qui contrôle quels utilisateurs ou rôles peuvent exécuter chaque opération sur cette classe. C’est la porte la plus extérieure de la sécurité de la couche de données : avant tout contrôle ligne par ligne, la classe elle-même décide si cet appelant a le droit d’interroger, de créer, de modifier ou de supprimer ici — une règle, toute la table, vérifiée en premier.

Points clés

La porte de la classe, déclarée puis ressentie

Une CLP est de la configuration de schéma — ici sous la forme du payload REST qui verrouille une classe Config en lecture publique, écriture réservée au serveur :

PUT /schemas/Config
{
  "classLevelPermissions": {
    "find":   { "*": true },              // tout le monde peut interroger
    "get":    { "*": true },
    "create": {},                         // personne côté client
    "update": { "role:admin": true },     // admins uniquement
    "delete": {},
    "addField": {}                        // schéma figé
  }
}

Ce que vivent les clients, c’est la porte qui fait son travail — les lectures passent, les écritures meurent à la frontière de la classe avant que la moindre donnée ne soit touchée :

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

Comment les permissions au niveau de la classe et les ACL fonctionnent ensemble

L’échelle de granularité : CLP vs. ACL vs. pointer permissions vs. champs protégés

L’idiome de conception qui en découle : les grandes lignes dans le schéma, le grain fin dans les lignes. Les classes dont la règle d’accès est uniforme (configuration, catalogues, logs) n’ont besoin que de la porte de la classe ; les classes contenant des données par utilisateur y ajoutent des ACL ou des pointer permissions en dessous.

La même porte dans d’autres moteurs

-- PostgreSQL : les privilèges de table sont des CLP sous un autre nom
GRANT SELECT ON films TO PUBLIC;
GRANT INSERT, UPDATE ON films TO role_editor;
REVOKE ALL ON launch_codes FROM PUBLIC;

Les bases documentaires le reproduisent avec des rôles limités à des actions au niveau de la collection — un rôle doté de find et insert sur une seule collection. Le concept est universel ; ce qui change, c’est l’ergonomie : les GRANT SQL et les documents de rôles s’administrent dans le code, tandis que les plateformes BaaS exposent la même matrice sous forme de cases à cocher dans le dashboard.

Réglages recommandés par type de contenu

Ce tableau est la checklist dont la plupart des lancements ont réellement besoin — remarquez la constante dans la dernière colonne, et sa règle sœur : la création de classes côté client désactivée en production, pour que le schéma ne change que volontairement.

Cas d’usage courants

• Figer les schémas de production. Add field désactivé partout ; les classes cessent d’apparaître et de muter au gré du trafic client.
• Données de référence en lecture seule. Catalogues et paramètres lisibles publiquement, modifiables uniquement par le code serveur — le modèle Config ci-dessus.
• Boîtes de dépôt en écriture seule. Des classes de feedback et de télémétrie dans lesquelles les clients peuvent créer mais jamais lire — la porte inverse que le code de la couche applicative oublie souvent.
• Surfaces d’administration par rôle. Update et delete réservés à un rôle admin, pendant que l’application lit librement.
• Défense contre le dump classique. Le tristement célèbre one-liner — un curl muni d’un app ID qui interroge une classe User ouverte — meurt à la porte find dès que la classe exige l’authentification.

La porte de la classe ou le code serveur ? Matrice de décision

Les deux se composent : le modèle durci pour les classes vraiment sensibles verrouille entièrement les CLP et expose des fonctions côté serveur comme seule porte d’entrée — la porte de la classe garantit que personne ne contourne le point de passage.

Limites et trade-offs

• La granularité de classe est grossière par définition. Tout ce qui est par ligne revient aux ACL et aux pointer permissions ; tout ce qui est conditionnel relève de la validation côté serveur — les CLP filtrent, elles ne raisonnent pas.
• Les réglages par défaut sont permissifs pour le développement. Les nouvelles classes naissent ouvertes pour que les prototypes avancent vite ; la passe d’avant lancement qui applique le tableau ci-dessus est une discipline, pas un automatisme.
• La master key ignore tout. Chaque porte de cet article tombe partout où cette clé circule — c’est pourquoi elle reste exclusivement côté serveur, utilisée opération par opération, jamais livrée.
• La surface d’application doit être complète. Les abonnements temps réel et les endpoints spéciaux ont connu par le passé des trous d’application — maintenez la plateforme à jour et testez les portes depuis un vrai client, pas seulement depuis le dashboard.
• Les cases à cocher méritent aussi une revue. La sécurité déclarative n’est une sécurité auditable que si quelqu’un l’audite — la matrice de réglages a sa place dans votre checklist de lancement, pas dans la mémoire collective.

Les CLP sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Les permissions au niveau de la classe y sont la surface de sécurité du schéma rendue visuelle : chaque classe du dashboard porte la matrice des opérations sous forme de cases à cocher — public, authentification requise, par rôle — ainsi que les pointer permissions et les champs protégés, appliqués côté serveur à chaque requête, aussi bien via les SDK que via REST et GraphQL. En dessous se trouvent les ACL par objet ; au-dessus, les triggers Cloud Code pour les règles qui demandent de la logique. Les recommandations de sécurité détaillent toute la passe d’avant lancement — la matrice de réglages de cet article, appliquée clic par clic.