Sécurité de la couche données vs. de la couche application

La sécurité de la couche application est un gardien dans votre code ; celle de la couche de données, un gardien sur les données elles-mêmes. Il faut les deux. Ce ne sont pas des synonymes, même si certains glossaires pourtant bien classés les mélangent : la couche application sécurise le comportement (authentification, validation, règles métier), la couche de données sécurise l’information stockée (politiques, ACL, chiffrement) contre tous les chemins d’accès — y compris ceux que votre code ne voit jamais.

Points clés

Le bug qui résume tout le débat

Le contrôle dans la couche application est correct — jusqu’à ce que quelqu’un oublie de le répéter :

// Endpoint un : le contrôle de propriété, présent et correct
app.get('/contracts/:id', async (req, res) => {
  const contract = await db.contracts.findById(req.params.id);
  if (contract.ownerId !== req.user.id) return res.status(403).end();
  res.json(contract);
});

// Endpoint deux, trois sprints plus tard, dans un autre fichier :
app.get('/contracts/:id/export', async (req, res) => {
  const contract = await db.contracts.findById(req.params.id);
  res.send(toPdf(contract));   // ← personne n'a réécrit le contrôle. IDOR en production.
});

L’application des règles dans la couche de données inverse la défaillance : la règle voyage avec la ligne, donc le contrôle oublié n’a plus rien à oublier —

// JavaScript / Node.js — Back4app JS SDK
// Data-layer enforcement: the rule travels with the row, not the code path
const doc = await new Parse.Query('Contract').get(contractId); // someone else's row
doc.set('total', 0);
try {
  await doc.save(); // rejected by the object's ACL — server-side, every path
} catch (e) {
  console.log(e.code); // 101: object not found for update
}

// Flutter / Dart — Back4app Flutter SDK
// Data-layer enforcement: the rule travels with the row, not the code path
final doc = ParseObject('Contract')..objectId = contractId;
doc.set('total', 0);
final response = await doc.save();
if (!response.success) {
  print(response.error?.code); // rejected by the object's ACL, server-side
}

// iOS / Swift — Back4app Swift SDK
// Data-layer enforcement: the rule travels with the row, not the code path
var doc = Contract(objectId: contractId)
doc.total = 0
doc.save { result in
  if case .failure(let error) = result {
    print(error.code ?? .unknownError) // rejected by the object's ACL
  }
}

// Android / Kotlin — Back4app Android SDK
// Data-layer enforcement: the rule travels with the row, not the code path
val doc = ParseObject.createWithoutData("Contract", contractId)
doc.put("total", 0)
doc.saveInBackground { e ->
  if (e != null) Log.d("Security", "blocked by ACL: ${e.code}") // server-side
}

Défense en profondeur : superposer les couches de sécurité autour des données stockées

La flèche en pointillés est l’argument : tout ce qui contourne votre application se heurte quand même à la couche de données — c’est pourquoi des règles qui ne vivent que dans les contrôleurs protègent une seule porte d’une pièce qui en compte beaucoup. C’est la défense en profondeur appliquée au stockage : des barrières qui se chevauchent et qui échouent différemment.

Couche de données vs. couche application : qui fait quoi

Deux lignes portent tout le débat. Les règles de workflow — chaînes d’approbation, machines à états, plafonds — ont besoin d’un contexte que seul le code possède ; les forcer dans des prédicats de ligne produit une soupe de politiques impossible à maintenir. Les règles structurelles — propriété, appartenance au tenant, visibilité — sont exactement ce que les politiques par ligne et les ACL par objet appliquent sans exiger de discipline endpoint par endpoint. Placez chaque règle là où son mode de défaillance reste survivable.

IDOR : le débat des couches, liste de CVE à l’appui

La défaillance de contrôle d’accès classée en tête — et n° 1 de la liste spécifique aux API — est précisément le contrôle oublié du code ci-dessus : des utilisateurs authentifiés qui récupèrent des objets par ID sans aucune autorisation par objet. Les pages sécurité cataloguent la vulnérabilité ; les pages architecture cataloguent les couches ; c’est le lien entre les deux qui est utile : l’IDOR, c’est ce à quoi ressemble à grande échelle une sécurité appliquée uniquement dans l’app, et les politiques de la couche de données en sont le correctif structurel, parce que le contrôle manquant se solde par un refus au lieu d’une porte ouverte.

Comment le BaaS déplace la frontière

Les plateformes de Backend as a Service rendent la thèse de cet article architecturale : avec des clients qui parlent (presque) directement au service de données, il n’existe plus de couche de contrôleurs écrits à la main pour porter les contrôles — l’autorisation doit donc vivre dans des constructions de la couche de données. Les ACL par objet portent la propriété, les permissions au niveau de la classe encadrent les opérations par schéma, et la plateforme applique les deux à chaque requête, quelle que soit la surface d’où elle vient. La couche application ne disparaît pas ; elle se déplace dans des fonctions côté serveur qui portent la validation et les règles de workflow — la séparation en deux couches, imposée par conception plutôt que par discipline.

Cas d’usage courants

• SaaS multi-tenant. L’appartenance au tenant est la règle structurelle canonique — appliquée dans la couche de données, testée de façon adversariale, jamais confiée à des clauses WHERE.
• Enregistrements appartenant aux utilisateurs. Messages, documents, commandes : la propriété est portée par la ligne via les ACL ; le code de l’app reste lisible, les données restent scellées.
• Accès analytique et BI. Le chemin de contournement rendu sûr : les analystes interrogent directement des répliques et ne voient que ce que les règles de la couche de données autorisent.
• Preuves de conformité. Les auditeurs préfèrent des contrôles démontrables dans la couche de données à des renvois vers le code applicatif.
• Workflows d’approbation. Le contre-exemple : les règles métier qui dépendent d’un état vivent dans la logique applicative — avec les règles structurelles qui tiennent toujours en dessous.

Où chaque règle doit-elle vivre ? Matrice de décision

Et la règle permanente au-dessus des deux colonnes : les couches se combinent en ET, pas en OU — gardez les contrôles de la couche application pour la clarté et l’UX, et laissez la couche de données rendre leur absence survivable.

Limites et trade-offs

• Tout dans le code applicatif : logique dupliquée d’un endpoint à l’autre, dérive entre microservices et tous les chemins de contournement sans protection — l’usine à IDOR.
• Tout dans les données : des règles invisibles qui déroutent ceux qui déboguent, un coût d’évaluation par ligne, des subtilités de contexte avec le pooling et une logique métier contorsionnée en prédicats.
• Les deux ensemble coûtent de la coordination. Deux endroits à mettre à jour quand une règle change ; gardez les règles structurelles peu nombreuses, stables et documentées.
• Le placement du chiffrement est un vrai embranchement. Côté base, il est transparent et interrogeable ; côté application, il sépare les clés mais complique les requêtes — décidez champ par champ, menace par menace.
• La frontière elle-même doit être auditée. Quiconque détient des identifiants de contournement — rôles d’admin, master keys — se tient hors de tous les cercles ; cette liste est le véritable périmètre.

Les deux couches 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. Elle livre la conclusion de cet article comme architecture par défaut : la couche de données porte les règles structurelles — ACL par objet, permissions au niveau de la classe, champs protégés, appliqués côté serveur à chaque requête — tandis que les triggers Cloud Code portent la part de la couche application : validation, enrichissement et contrôles de workflow qui s’exécutent avant qu’une écriture n’aboutisse. Le bug du filtre oublié n’a aucun chemin pour passer, et les règles métier gardent un endroit où vivre.