Comment fonctionne le contrôle d'accès (RBAC, principe du moindre privilège) ?

Question

Accepted Answer

**Le contrôle d'accès** régit ce que les utilisateurs authentifiés peuvent faire — à travers des modèles comme **RBAC** (contrôle d'accès basé sur les rôles) et des principes comme le **moindre privilège**. Le contrôle d'accès approprié est critique, car un contrôle d'accès défaillant est la vulnérabilité #1 de l'OWASP.

## Modèles de contrôle d'accès

```text
RBAC (Role-Based Access Control) → assign users to ROLES; roles have PERMISSIONS:
  → user → role(s) (admin, editor, viewer) → permissions → access decisions
  → manageable, common; change a role's permissions, all its users update
ABAC (Attribute-Based) → decisions based on ATTRIBUTES (user, resource, context) → flexible,
  fine-grained (e.g. "editors can edit docs in their department during business hours")
ACLs → per-resource lists of who can do what
```

## Le principe du moindre privilège

```text
LEAST PRIVILEGE → grant the MINIMUM access needed to do the job, nothing more:
  → limits the BLAST RADIUS if an account/component is compromised
  → applies to users, services, processes, database accounts, API keys, etc.
→ a foundational security principle (default to LESS access; grant more only as needed)
```

## Implémenter le contrôle d'accès de manière sécurisée

```text
⚠️ BROKEN ACCESS CONTROL is OWASP #1 — common and serious:
✓ ENFORCE authorization on the SERVER for EVERY protected action/resource (never trust
  the client; don't rely on hiding UI elements)
✓ Check the user is authorized for the SPECIFIC resource (prevent IDOR — accessing
  others' data by changing an ID)
✓ DENY by default; verify on each request; centralize authorization logic
✓ Test access control (a common gap — easy to miss authorization checks)
```

## Pourquoi c'est important

Comprendre le contrôle d'accès est important car il **régit ce que les utilisateurs peuvent faire et est critique pour la sécurité** — un contrôle d'accès défaillant est la vulnérabilité #1 de l'OWASP — donc c'est une connaissance de sécurité précieuse et pratiquement critique.

Le contrôle d'accès détermine ce que les utilisateurs authentifiés sont autorisés à faire, et bien le mettre en place est essentiel.

Comprendre les **modèles** — **RBAC** (assigner les utilisateurs à des rôles ayant des permissions — gérable et courant), **ABAC** (décisions basées sur les attributs pour un contrôle flexible et granulaire), et ACLs (listes de permissions par ressource) — fournit les cadres pour structurer les permissions, RBAC étant le plus courant à comprendre.

Comprendre le **principe du moindre privilège** — accorder l'**accès minimum nécessaire**, ce qui **limite la zone d'impact en cas de compromission d'un compte ou d'un composant** — est un principe de sécurité fondamental s'appliquant largement (utilisateurs, services, comptes de base de données, clés API), et l'un des concepts de sécurité les plus importants.

Critiquement, comprendre comment **implémenter le contrôle d'accès de manière sécurisée** aborde la vulnérabilité #1 : **appliquer l'autorisation sur le serveur pour chaque action protégée** (ne jamais faire confiance au client ou s'appuyer sur une UI cachée — une erreur courante), **vérifier l'autorisation pour la ressource spécifique** (prévenir IDOR, où les utilisateurs accèdent aux données d'autres en changeant un ID — une faille de contrôle d'accès fréquente), **refuser par défaut**, vérifier à chaque requête, et **tester le contrôle d'accès** (une lacune courante, car les vérifications d'autorisation manquantes sont faciles à ignorer).

Comme le contrôle d'accès régit ce que les utilisateurs peuvent faire et un contrôle d'accès défaillant est la vulnérabilité principale (courante et grave), et comme comprendre les modèles (RBAC), le principe du moindre privilège, et l'implémentation sécurisée (application serveur, vérifications spécifiques à la ressource, refus par défaut) est critique pour la sécurité, comprendre le contrôle d'accès est une connaissance de sécurité précieuse et pratiquement critique — abordant le risque de sécurité #1, fondamental pour contrôler ce que les utilisateurs peuvent faire, et essentiel pour éviter les flaws de contrôle d'accès (comme IDOR et les vérifications d'autorisation manquantes) qui sont parmi les vulnérabilités les plus courantes et les plus graves.