Qu'est-ce que le durcissement de la sécurité BaaS ?

Le durcissement de la sécurité BaaS est un ensemble de contrôles en couches — CLP, ACL, discipline des clés — qui ferme les brèches d’un backend par défaut. Les backends naissent permissifs, et c’est voulu : des classes ouvertes et un schéma modifiable depuis le client font décoller les prototypes. Le durcissement est la passe délibérée qui inverse ces valeurs par défaut avant le lancement — et il s’agit d’une checklist courte et connue, pas d’un projet de recherche.

Points clés

Le durcissement par défaut, en code

La moitié « par objet » de l’histoire — une ACL limitée au propriétaire, posée sous une classe verrouillée :

// JavaScript / Node.js — Back4app JS SDK
// Per-object ACL: the owner reads and writes, a moderator role reads,
// the public gets nothing — layered under the class-level permissions
const note = new Parse.Object('Note');
note.set('body', 'quarterly numbers');

const acl = new Parse.ACL(Parse.User.current()); // owner: read + write
acl.setPublicReadAccess(false);
acl.setPublicWriteAccess(false);
acl.setRoleReadAccess('moderator', true);        // role: read only
note.setACL(acl);
await note.save();

// The class gate above it is schema config, set in the dashboard:
// find/get: requiresAuthentication · create: authenticated · addField: nobody

// Flutter / Dart — Back4app Flutter SDK
// Per-object ACL: owner read/write, moderator role read, public nothing
final note = ParseObject('Note')..set('body', 'quarterly numbers');

final acl = ParseACL(owner: await ParseUser.currentUser()); // owner: r+w
acl.setPublicReadAccess(allowed: false);
acl.setPublicWriteAccess(allowed: false);
acl.setReadAccess(userId: 'role:moderator', allowed: true); // role: read
note.setACL(acl);
await note.save();

// The class gate above it is schema config, set in the dashboard:
// find/get requiresAuthentication, create authenticated, addField off

// iOS / Swift — Back4app Swift SDK
// Per-object ACL: owner read/write, moderator role read, public nothing
var note = Note()
note.body = "quarterly numbers"

var acl = ParseACL()
acl.publicRead = false
acl.publicWrite = false
if let user = User.current {
    acl.setReadAccess(user: user, value: true)   // owner: read
    acl.setWriteAccess(user: user, value: true)  // owner: write
}
acl.setReadAccess(roleName: "moderator", value: true) // role: read only
note.ACL = acl
note.save { result in
    if case .failure(let error) = result { print(error) }
}

// Android / Kotlin — Back4app Android SDK
// Per-object ACL: owner read/write, moderator role read, public nothing
val note = ParseObject("Note").apply { put("body", "quarterly numbers") }

val acl = ParseACL(ParseUser.getCurrentUser()) // owner: read + write
acl.publicReadAccess = false
acl.publicWriteAccess = false
acl.setRoleReadAccess("moderator", true)       // role: read only
note.acl = acl
note.saveInBackground { e ->
    if (e != null) Log.w("ACL", "save failed: ${e.code}")
}

// The class gate above it is schema config, set in the dashboard:
// find/get requiresAuthentication, create authenticated, addField off

CLP vs. ACL vs. master key : quel contrôle fait quoi

Les trois premiers s’assemblent en une échelle de permissions que chaque requête doit gravir. Le quatrième est l’issue de secours de cette échelle — indispensable côté serveur, catastrophique partout ailleurs. Quant aux identifiants que les apps livrent bel et bien — l’app ID et les clés d’API client —, ils relèvent d’une tout autre catégorie mentale : extractibles de n’importe quel binaire, ils identifient l’app plutôt qu’ils ne la protègent. Partez du principe qu’ils sont publics, et laissez la couche de données faire respecter les règles.

Où meurt une requête hostile

Le diagramme est aussi le script d’audit : à chaque barrière, demandez-vous ce qui se passe quand un attaquant muni de vos clés publiques arrive en tant qu’utilisateur anonyme, en tant qu’utilisateur connecté, puis en tant qu’utilisateur d’un autre tenant. Chaque « autorisé » qui vous surprend est une anomalie à corriger.

Comment durcir un backend BaaS

Les étapes 1 à 4 relèvent de l’application des règles au niveau de la couche de données — déclarative, vérifiée sur chaque chemin. Les étapes 5 à 8 relèvent de la discipline opérationnelle. Les deux moitiés sont nécessaires ; aucune n’est suffisante.

Discipline de la master key et chemin privilégié

La master key existe parce que des acteurs légitimes — migrations, outils d’administration, jobs planifiés — doivent pouvoir ignorer les barrières. La discipline consiste à la traiter comme l’identifiant root qu’elle est : injectée dans les environnements serveur en tant que configuration, jamais commitée, jamais journalisée, jamais embarquée dans quoi que ce soit qu’un utilisateur télécharge, et utilisée opération par opération plutôt que conservée comme valeur par défaut pour toute une session. La rotation en est la moitié sous-estimée — les clés fuient discrètement dans les logs de CI et sur de vieux portables, si bien que les faire tourner selon un calendrier (et instantanément au moindre soupçon) limite le rayon d’impact d’une fuite que vous ne détecterez jamais.

Cloud Code est le pattern qui rend vivables des règles strictes au niveau de la couche de données. Verrouillez complètement une classe — aucune écriture client — et exposez une fonction serverless comme unique porte d’entrée. La fonction valide les entrées, applique les règles métier que le schéma ne sait pas exprimer (« seulement avant l’expédition de la commande »), écrit avec des privilèges élevés et laisse une trace d’audit. La barrière de la classe garantit que ce point de passage obligé ne peut pas être contourné ; le point de passage garde la logique relisible en un seul endroit.

Cas d’usage courants

• Le verrouillage d’avant lancement. La checklist complète ci-dessus, exécutée une fois avant l’arrivée des vrais utilisateurs — l’heure de sécurité la plus rentable qu’une petite équipe puisse passer.
• Isolation des données multi-tenant. Des ACL limitées au propriétaire et des CLP réservées aux utilisateurs authentifiés, pour que le tenant A ne puisse jamais interroger les données du tenant B — appliqué sous le code applicatif.
• Paiements et inventaire. Des classes fermées à toute écriture client, avec des fonctions Cloud Code comme chemin audité pour tout ce qui touche à l’argent ou au stock.
• Réponse à incident. Une clé qui fuit ou une surprise dans les logs déclenche une rotation, un audit des accès et une nouvelle exécution du test de permissions depuis l’extérieur.
• Preuves de conformité. Une matrice de permissions versionnée et des logs d’usage de la master key transforment « nous prenons la sécurité au sérieux » en un document qu’un auditeur peut lire.

Faut-il durcir au niveau de la couche de données ou dans le code applicatif ? Matrice de décision

En pratique, la réponse est en couches, pas l’un ou l’autre : les règles de la couche de données comme plancher qui tient toujours, les fonctions de la couche applicative pour tout ce qui est conditionnel — et la même requête traverse les deux.

Limites et trade-offs

• Le durcissement est de la configuration, et la configuration dérive. Les nouvelles classes arrivent avec des valeurs par défaut permissives ; sans l’habitude de réauditer, le verrouillage de l’an dernier s’érode sans bruit.
• Les règles déclaratives ne savent pas exprimer de logique. « Propriétaires uniquement » est une case à cocher ; « remboursable seulement dans les 30 jours » est du code — trop s’appuyer sur la couche de données pousse les équipes à tordre leur schéma au lieu d’écrire une fonction.
• La rigueur a un coût en expérience développeur. Des classes verrouillées et un schéma gelé ralentissent le prototypage, d’où une discipline par étapes : ouvert en développement, verrouillé au lancement.
• Rate limits et audits demandent des réglages. Des limites trop serrées brident les pics légitimes ; des logs que personne ne lit ne sont que de la décoration. Les deux ont besoin d’un responsable, pas seulement d’un commit de mise en place.
• Les couches protègent les données, pas tout le reste. Les vulnérabilités des dépendances, les mots de passe utilisateurs divulgués et l’ingénierie sociale sortent de ce modèle — durcir la couche de données est nécessaire, pas suffisant, comme le montre clairement le catalogue OWASP API Security Top 10.

Durcissement de la sécurité BaaS 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. La checklist de cet article se transpose presque point par point dans son dashboard : les permissions au niveau de la classe et les champs protégés sont des cases à cocher par classe, les ACL sont appliquées côté serveur à chaque requête — via les SDK, REST et GraphQL —, et la master key reste dans la configuration serveur, où Cloud Code — le chemin privilégié — peut l’utiliser opération par opération. Les consignes de sécurité parcourent la même passe étape par étape : durcir un backend se résume à un après-midi de réglages et à un test honnête depuis l’extérieur.