M08 · B. Assurer la confidentialité des données

Les droits d'accès des utilisateurs d'une application

Authentification et autorisation, le principe du moindre privilège, les modèles de contrôle d'accès (par rôle, par propriétaire), la faille IDOR (accès direct à l'objet d'un autre), le contrôle systématique côté serveur et les droits limités du compte MySQL de l'application.

1Situer

Amina est connectée et consulte sa facture : facture.php?id=1. Que se passe-t-il si elle tape id=2 ? Si le site affiche la facture d'un autre client, c'est le premier risque de l'OWASP Top 10, le contrôle d'accès défaillant. Être connecté ne veut pas dire avoir le droit de tout voir.

2Comprendre

Vérifier les droits à chaque requête

Amina, connectée, ouvre facture.php?id=1 : c'est sa commande.

1 / 4

S’identifier n’est pas tout

Les modèles de contrôle d’accès

Modèle	Principe	Exemple
Par rôle (RBAC)	les droits sont attachés à des rôles, les utilisateurs reçoivent un rôle	admin, préparateur, client (leçon C.2)
Par propriétaire	on n’accède qu’à ce qui nous appartient	un client et SES commandes
Par attributs	la décision dépend de règles sur l’utilisateur, l’objet, le contexte	un préparateur de Fès ne voit que les commandes de Fès

Une application réelle combine souvent les deux premiers : le rôle dit quelles pages on peut ouvrir, la propriété dit quelles lignes on peut voir.

La faille IDOR

Exemple simple

Énumérer les factures

Connectée avec son compte, Amina change l’adresse de sa facture :

GET /facture.php?id=1   → 200  Facture de la commande n° 1 · Amina Benali · 270 DH
GET /facture.php?id=2   → 200  Facture de la commande n° 2 · Youssef El Idrissi · 1200 DH
GET /facture.php?id=3   → 200  ...

Un petit script peut ainsi aspirer toutes les factures du site en quelques secondes. La correction tient dans la requête :

... WHERE c.id = ? AND c.client_id = ?     -- [$id, $_SESSION['client_id']]

Une commande qui n’est pas la sienne n’est plus trouvée : réponse 404, comme si elle n’existait pas.

Contrôler côté serveur, partout

Les règles d’or :

Refuser par défaut : une page ou une API sans vérification explicite est inaccessible.
Vérifier à chaque requête, sur le serveur : masquer un bouton ou un lien ne protège rien.
Les API aussi : api/commandes.php?id=2 doit faire le même contrôle que la page HTML.
Lire l’identité dans la session, jamais dans un paramètre (?client_id=1) ni dans un cookie modifiable (leçon A.5).

Un accès sécurisé à la base

L’application elle-même ne doit pas avoir tous les droits sur MySQL. Avec le compte root, une seule injection SQL permet de tout supprimer, de lire les autres bases, voire de créer des comptes. On crée un compte dédié avec le strict nécessaire (exercice 1), et un autre compte, utilisé seulement par l’administrateur, pour les changements de structure. Le mot de passe de ce compte vit dans un fichier de configuration hors du dossier public.

Exemple simple

Le badge de l'hôtel

La carte de votre chambre ouvre la porte 214, pas la 215. L'hôtel sait que vous êtes client (authentification) ET vérifie, porte par porte, que celle-ci est la vôtre (autorisation).

Exemple simple

Le numéro de vestiaire

Si le vestiaire rend le manteau à quiconque annonce un numéro, il suffit d'essayer 1, 2, 3... C'est la faille IDOR : l'identifiant ne doit jamais servir de preuve.

3Manipuler

Connectez-vous en Amina (amina.benali@mail.ma / Atlas2025) puis ouvrez facture.php?id=2 : c'est la facture de Youssef. Corrigez facture.php pour que chaque client ne voie que ses propres commandes.

Pas à pas dans le lab ↗ Cliquez sur Exécuter : PHP 8.3 démarre dans votre navigateur (environ 5 Mo à télécharger, une seule fois).

<?php
session_start();
require __DIR__ . '/db.php';
// 1. Sans client en session : redirection vers connexion.php

$id = (int) ($_GET['id'] ?? 0);
// 2. La commande doit appartenir au client connecté ($_SESSION['client_id']).
//    Sinon : code 404 et « Commande introuvable » (on ne dit pas qu'elle existe).
$req = $pdo->prepare('SELECT c.id, c.date_commande, cl.prenom, cl.nom,
                             SUM(l.quantite * l.prix_unitaire) AS total
                      FROM commandes c
                      JOIN clients cl ON cl.id = c.client_id
                      JOIN lignes_commande l ON l.commande_id = c.id
                      WHERE c.id = ?
                      GROUP BY c.id, c.date_commande, cl.prenom, cl.nom');
$req->execute([$id]);
$f = $req->fetch();
if (!$f) {
    http_response_code(404);
    exit('Commande introuvable');
}
?>
<h1>Facture de la commande n° <?= $f['id'] ?></h1>
<p>Client : <?= htmlspecialchars($f['prenom'] . ' ' . $f['nom']) ?> · <?= $f['date_commande'] ?></p>
<p>Total : <?= $f['total'] ?> DH</p>
<p><a href="facture.php?id=<?= $f['id'] + 1 ?>">Facture suivante ?</a></p>

Entre le navigateur et le serveur aucun échange pour l'instant

Consignes 0 / 3

Amina voit sa facture n° 1 (Amina Benali, 270 DH)
Amina ne voit pas la facture n° 2 de Youssef (404)
Sans connexion, facture.php renvoie vers connexion.php

4Pratiquer

Exercice 1 · Les droits du compte MySQL

Le site Souk Atlas se connecte à MySQL en root. Créez un utilisateur souk_app qui ne peut que lire et modifier les données de la base souk depuis le serveur local, sans pouvoir supprimer de table ni créer d'utilisateur.

Voir le corrigé

CREATE USER 'souk_app'@'localhost' IDENTIFIED BY 'Un-Mot-De-Passe-Long-2025!';
GRANT SELECT, INSERT, UPDATE, DELETE ON souk.* TO 'souk_app'@'localhost';
-- pas de DROP, ALTER, GRANT OPTION ni de droits sur les autres bases
SHOW GRANTS FOR 'souk_app'@'localhost';

Exercice 2 · Matrice des droits

Pour Souk Atlas, construisez une matrice : rôles (visiteur, client, préparateur de commandes, administrateur) × actions (voir le catalogue, passer commande, voir ses commandes, voir toutes les commandes, changer un statut, modifier les prix, gérer les comptes).

Voir le corrigé

Visiteur : voir le catalogue.
Client : voir le catalogue, passer commande, voir SES commandes.
Préparateur : voir le catalogue, voir toutes les commandes, changer un statut (en préparation, expédiée).
Administrateur : tout, y compris modifier les prix et gérer les comptes.
Chaque case « non » doit être vérifiée côté serveur, pas seulement cachée dans le menu.

Les droits d'accès des utilisateurs d'une application

1Situer

2Comprendre

S’identifier n’est pas tout

Les modèles de contrôle d’accès

La faille IDOR

Contrôler côté serveur, partout

Un accès sécurisé à la base

Le badge de l'hôtel

Le numéro de vestiaire

3Manipuler

4Pratiquer

Exercice 1 · Les droits du compte MySQL

Exercice 2 · Matrice des droits

5Vérifier