C.2 Le pare-feu applicatif et le développement sécurisé

1Situer

Le pare-feu réseau de la leçon précédente laisse passer le port 443, et il le doit : c'est par là qu'arrivent les clients. Mais c'est aussi par là qu'arrivent les injections SQL et le XSS. Le pare-feu applicatif ouvre chaque requête HTTP pour en lire le contenu. Il aide, mais la vraie protection reste un code écrit avec de bonnes habitudes : c'est le développement sécurisé, qui termine ce module.

2Comprendre

Le pare-feu applicatif lit le contenu des requêtes

Une recherche normale, q=savon, arrive sur le port 443 : le pare-feu réseau la laisse passer.

1 / 5

Le pare-feu applicatif

Le WAF prend place juste après le pare-feu réseau :

Internet → pare-feu réseau (adresses, ports) → WAF (contenu HTTP) → serveur web → PHP → MySQL

Il existe sous plusieurs formes :

un module du serveur web : ModSecurity pour Apache ou Nginx, le plus connu des WAF libres ;
un service en ligne placé devant le site, souvent fourni avec le CDN (leçon A.2, DDoS) ;
une couche dans l’application elle-même, comme le petit waf.php de la simulation.

Exemple simple

Une requête bloquée par le WAF

Un attaquant tente une injection SQL dans la recherche.

GET /recherche.php?q=x' UNION SELECT email, nom FROM clients --

Le WAF reconnaît le motif UNION ... SELECT dans le paramètre q. La requête n’atteint jamais PHP.

Résultat

HTTP/1.1 403 Forbidden
Requête bloquée. Règle déclenchée : injection UNION

Les limites du WAF

Les principes du développement sécurisé

Les règles que vous avez pratiquées tout au long des modules 07 et 08 :

Principe	Dans le code
Ne jamais faire confiance aux entrées	Valider côté serveur ce qui vient de `$_GET`, `$_POST`, `$_COOKIE`, des fichiers et des en-têtes
Séparer les données du code	Requêtes préparées (SQL), `htmlspecialchars` (HTML), `textContent` (JavaScript)
Moindre privilège	Un compte MySQL du site sans `DROP` ni `GRANT`, des rôles vérifiés à chaque page
Défense en profondeur	Pare-feu réseau, WAF, code sûr, base chiffrée : plusieurs couches indépendantes
Échouer en sécurité	En cas de doute, refuser. Une erreur affiche une page neutre et se lit dans le journal
Secrets hors du code	Mots de passe et clés dans un fichier `.env` hors du dossier public et hors de Git
Dépendances à jour	`composer audit` et `npm audit` régulièrement, mises à jour de PHP et du framework
Journaliser	Connexions, échecs, actions d’administration, sans jamais écrire de mot de passe

Exemple simple

Une erreur qui en dit trop

Avec display_errors = On, une base injoignable affiche à tous les visiteurs :

Fatal error: Uncaught PDOException: SQLSTATE[HY000] [1045] Access denied
for user 'souk_app'@'localhost' (using password: YES)
in /var/www/soukatlas/app/db.php:3

L’attaquant apprend le nom du compte MySQL, le chemin du site et le nom du fichier de connexion. En production, on règle display_errors = Off et log_errors = On : le visiteur voit « Le service est momentanément indisponible », le développeur lit le détail dans le journal.

Les en-têtes de sécurité HTTP

En-tête	Ce qu’il demande au navigateur
`Content-Security-Policy: default-src 'self'`	N’exécuter que les scripts et styles venus du site lui-même (limite le XSS, leçon A.2)
`Strict-Transport-Security: max-age=31536000`	Toujours utiliser HTTPS pour ce site pendant un an, même si l’on tape `http://`
`X-Content-Type-Options: nosniff`	Respecter le type annoncé d’un fichier : un « texte » envoyé par un utilisateur n’est jamais exécuté comme script
`X-Frame-Options: DENY`	Interdire l’affichage du site dans un cadre (`iframe`) d’un autre site, ce qui empêche le clickjacking
`Referrer-Policy: strict-origin-when-cross-origin`	Ne pas transmettre l’adresse complète des pages aux autres sites

En PHP, on les envoie avant tout affichage, une fois pour toutes dans un fichier inclus partout :

<?php
header("Content-Security-Policy: default-src 'self'");
header('Strict-Transport-Security: max-age=31536000');
header('X-Content-Type-Options: nosniff');
header('X-Frame-Options: DENY');
header('Referrer-Policy: strict-origin-when-cross-origin');

C’est la dernière leçon du module : vous savez maintenant reconnaître les principales attaques, protéger les données et configurer les défenses d’une application web. Pour vérifier un site avant sa mise en ligne, la liste de l’exercice « Le bilan avant la mise en ligne » est un bon point de départ.

Exemple simple

Le contrôle des bagages à l'aéroport

Le contrôle des billets (pare-feu réseau) vérifie que vous allez au bon terminal. Le scanner des bagages (WAF) regarde ce que vous transportez. Les deux sont utiles, et aucun ne remplace l'autre.

Exemple simple

La recette écrite proprement

Un cuisinier qui se lave les mains, garde le poulet cru à part et vérifie les dates n'a pas besoin d'un inspecteur pour éviter l'intoxication. Le développement sécurisé, ce sont ces gestes répétés à chaque ligne de code.

3Manipuler

La recherche de Souk Atlas passe par un petit pare-feu applicatif (waf.php). Ses règles sont trop naïves : essayez les attaques proposées, puis améliorez les règles (expressions régulières insensibles à la casse) sans bloquer les recherches normales, et ajoutez deux en-têtes de sécurité.

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
// Pare-feu applicatif (WAF) minimal, inclus en tête de chaque page.

// 3. Envoyez ici, pour chaque réponse, les en-têtes :
//    X-Content-Type-Options: nosniff
//    X-Frame-Options: DENY

function bloquer(string $regle): never
{
    http_response_code(403);
    exit("<h1>Requête bloquée</h1><p>Règle déclenchée : $regle</p>");
}

// Chaque règle : [nom, motif cherché dans les valeurs reçues].
// 1. str_contains respecte la casse : <ScRiPt> passe. Passez à preg_match avec le drapeau i.
// 2. Ajoutez une règle contre « UNION SELECT » (et UNION ALL SELECT, espaces multiples).
//    Attention : une recherche « Union des artisans » doit rester permise.
$REGLES = [
    ['balise script', '<script'],
];

foreach ([$_GET, $_POST, $_COOKIE] as $source) {
    foreach ($source as $cle => $valeur) {
        $valeur = is_array($valeur) ? json_encode($valeur) : (string) $valeur;
        foreach ($REGLES as [$nom, $motif]) {
            if (str_contains($valeur, $motif)) {
                bloquer($nom);
            }
        }
    }
}

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

Consignes 0 / 5

La balise script en casse mélangée est bloquée (403)
L'injection « UNION ALL SELECT » (deux espaces) est bloquée (403)
Pas de faux positif : la recherche « Union des artisans » reste permise
Chaque réponse envoie X-Content-Type-Options: nosniff
Chaque réponse envoie X-Frame-Options: DENY

4Pratiquer

Exercice 1 · Réseau ou applicatif ?

Pour chaque attaque, dites quel pare-feu peut la repérer : (a) un robot qui tente le port 22 ; (b) un paramètre ?id=1 OR 1=1 ; (c) une adresse IP bannie qui revient ; (d) un champ de formulaire contenant <script>.

Voir le corrigé

(a) Pare-feu réseau : il voit le port 22 et le bloque.
(b) Pare-feu applicatif : le contenu de la requête HTTP (le paramètre id) n'est visible qu'en lisant HTTP.
(c) Les deux savent bloquer une adresse ; le pare-feu réseau le fait le plus tôt et le moins cher.
(d) Pare-feu applicatif. Et surtout le code : htmlspecialchars à l'affichage.

Exercice 2 · Une règle de WAF

Écrivez une règle (expression régulière PHP) qui détecte une tentative de traversée de répertoires (../ ou ..\, y compris encodée %2e%2e%2f) dans une valeur déjà décodée par PHP.

Voir un indice

PHP décode déjà %2e%2e%2f en ../ dans $_GET. Pensez aux deux barres, / et \.

Voir le corrigé

<?php
$REGLES[] = ['traversée de répertoires', '#\.\.[/\\\\]#'];
// Mais la vraie protection reste dans le code : basename() et une liste de fichiers permis (leçon A.2).

Exercice 3 · Le bilan avant la mise en ligne

Votre projet de fin de module va être mis en ligne. Listez six vérifications de sécurité à faire avant.

Voir le corrigé

1. display_errors = Off en production, les erreurs vont dans un journal.
2. Les secrets (mot de passe MySQL, clés d'API) sont dans un fichier .env hors du dossier public et hors de Git.
3. Toutes les requêtes SQL sont préparées, toutes les sorties échappées.
4. Les mots de passe sont hachés avec password_hash, la connexion limite les tentatives.
5. HTTPS partout, avec les en-têtes de sécurité (HSTS, CSP, nosniff, X-Frame-Options) et des cookies Secure, HttpOnly, SameSite.
6. composer audit (ou npm audit) ne signale aucune dépendance vulnérable ; le compte MySQL du site n'a que les droits nécessaires.

5Vérifier

1. Que lit un pare-feu applicatif (WAF) qu'un pare-feu réseau ne lit pas ? L'adresse IP de la sourceLe contenu de la requête HTTP : URL, paramètres, en-têtes, corpsLe numéro de port

2. Le site a un WAF. Peut-on se passer des requêtes préparées ? Oui, le WAF bloque toutes les injectionsNon : un WAF se contourne (encodages, commentaires SQL) ; il complète un code sûr, il ne le remplace pasOui, si le WAF est payant

3. Qu'est-ce qu'un faux positif pour un WAF ? Une attaque qui n'est pas détectéeUne requête légitime bloquée par erreurUn virus caché dans un fichier

4. Pourquoi désactiver display_errors en production ? Pour que le site soit plus rapideParce que les messages d'erreur révèlent des chemins, des noms de tables, parfois des requêtes SQL, utiles à un attaquantParce que PHP l'exige