Tests de sécurité : revue de code, SAST, DAST et SCA

Les tests de sécurité vérifient qu'une application résiste aux attaques connues, avant qu'un attaquant ne s'en charge. On combine plusieurs familles : la revue de code par un humain, l'analyse statique du code (SAST), l'analyse des dépendances (SCA), la recherche de secrets, l'analyse dynamique de l'application en fonctionnement (DAST) et le test d'intrusion. Ce chapitre présente chacune, avec les outils courants (Semgrep, npm audit, gitleaks, ZAP), leur intégration dans l'intégration continue et la rédaction d'un rapport d'audit.

Les familles de tests

Aucune famille ne suffit seule. Les outils automatiques trouvent vite et souvent les failles « techniques » ; seuls les humains trouvent les failles de logique (une IDOR, une étape de validation contournable) que le code exprime parfaitement.

La revue de code orientée sécurité

Une revue de code suit une liste de points de contrôle. Celle-ci reprend les chapitres du cours :

Un exemple de revue sur un extrait de la version PHP :

1  $id = $_GET['id'];
2  $res = $pdo->query("SELECT * FROM ligne_frais WHERE id_fiche = $id");
3  foreach ($res as $ligne) {
4      echo "<tr><td>" . $ligne['libelle'] . "</td><td>" . $ligne['montant'] . "</td></tr>";
5  }

Les commentaires de revue :

• Ligne 2 : injection SQL, $id est concaténé. Requête préparée avec un marqueur.
• Ligne 2 : aucune vérification que la fiche appartient à l'utilisateur connecté (IDOR). Ajouter AND id_visiteur = ? via une jointure avec fiche_frais.
• Ligne 2 : SELECT * : ne sélectionner que les colonnes affichées.
• Ligne 4 : XSS stockée possible, libelle est affiché sans encodage. htmlspecialchars.

SAST : analyser le code source

Un outil SAST lit le code sans l'exécuter et cherche des motifs dangereux : une saisie de l'utilisateur qui atteint une requête SQL sans passer par une requête préparée, l'appel d'une fonction risquée, un secret écrit en dur. Semgrep est gratuit dans sa version communautaire et couvre de nombreux langages :

semgrep scan --config p/owasp-top-ten        # règles publiques alignées sur le Top 10
semgrep scan --config p/javascript --error   # code de sortie en erreur si un problème est trouvé

On peut aussi écrire ses propres règles, pour les erreurs propres au projet :

rules:
  - id: requete-sql-concatenee
    languages: [javascript]
    severity: ERROR
    message: Requête SQL construite par concaténation, utiliser une requête préparée
    pattern-either:
      - pattern: $POOL.query("..." + $X, ...)
      - pattern: $POOL.execute("..." + $X, ...)

Les autres outils courants : SonarQube, qui combine qualité et sécurité et s'intègre aux pull requests ; CodeQL, le moteur de l'analyse de code de GitHub (code scanning), gratuit pour les dépôts publics ; eslint-plugin-security pour JavaScript ; Psalm et son analyse de propagation des données (taint analysis) pour PHP.

SCA et secrets dans la chaîne d'intégration

L'analyse des dépendances et la recherche de secrets se branchent au même endroit que les tests, pour bloquer une pull request qui ajoute une dépendance vulnérable ou un secret :

npm audit --omit=dev --audit-level=high     # échoue s'il existe une vulnérabilité élevée ou critique
gitleaks git . --redact                      # cherche des secrets dans l'historique, sans les afficher en clair

Le chapitre 5 détaille npm audit et Dependabot ; le chapitre 4, la réaction à un secret commité.

DAST : attaquer l'application qui tourne

Un outil DAST se comporte comme un attaquant : il parcourt l'application en fonctionnement, envoie des requêtes piégées et analyse les réponses. Il ne voit pas le code, mais il voit ce que voit un attaquant : en-têtes, cookies, messages d'erreur, réactions aux charges d'injection.

ZAP (maintenu aujourd'hui sous le nom ZAP by Checkmarx) est le scanner libre le plus utilisé. Il fonctionne en trois temps :

1. Proxy : ZAP se place entre le navigateur et l'application et enregistre toutes les requêtes pendant que tu utilises l'application normalement.
2. Exploration (spider) : il suit les liens et les formulaires pour découvrir les pages et les routes.
3. Analyse : l'analyse passive examine les réponses sans rien envoyer de plus (en-têtes manquants, cookies sans HttpOnly, informations divulguées) ; l'analyse active envoie des charges d'attaque (injections, XSS, parcours de répertoire) et observe les réponses.

Pour une analyse rapide et automatisable, ZAP fournit des scripts prêts à l'emploi dans son image Docker :

# Analyse de base : exploration et analyse passive, sans attaque, rapport HTML dans le dossier courant
docker run --rm -v "$(pwd):/zap/wrk" -t ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py -t https://preprod.frais.gsb.fr -r rapport-zap.html

Le script zap-full-scan.py ajoute l'analyse active, et zap-api-scan.py analyse une API à partir de sa description OpenAPI.

Burp Suite, dont l'édition Community est gratuite, est l'outil de référence des testeurs pour intercepter, modifier et rejouer les requêtes à la main : changer un identifiant pour tester une IDOR, retirer un jeton, modifier un champ caché.

Tester l'autorisation avec des tests automatisés

Aucun scanner ne sait que le visiteur A ne doit pas lire la fiche du visiteur B : c'est une règle métier. Elle se protège par des tests écrits par l'équipe, exécutés à chaque commit. Une approche efficace : une matrice de tests qui joue chaque rôle contre chaque route sensible.

import { describe, it, expect } from 'vitest';
import request from 'supertest';
import { app } from '../src/app.js';
import { jetonPour } from './outils.js';

const cas = [
  // [méthode, route, utilisateur, statut attendu]
  ['get',   '/api/fiches/1187',                'visiteurA',  200],
  ['get',   '/api/fiches/1188',                'visiteurA',  404],
  ['get',   '/api/fiches/1188',                'comptable1', 200],
  ['patch', '/api/compta/fiches/1187/valider', 'visiteurA',  403],
  ['patch', '/api/compta/fiches/1187/valider', null,         401],
  ['get',   '/api/moi',                        'visiteurA',  200],
];

describe('matrice de contrôle d’accès', () => {
  it.each(cas)('%s %s par %s → %i', async (methode, route, utilisateur, attendu) => {
    let requete = request(app)[methode](route);
    if (utilisateur) requete = requete.set('Authorization', `Bearer ${jetonPour(utilisateur)}`);
    const reponse = await requete;
    expect(reponse.status).toBe(attendu);
  });
});

Un test qui vérifie aussi qu'une réponse ne contient pas de champ sensible (expect(reponse.body).not.toHaveProperty('mdp_hash')) protège contre le BOPLA. Le cours Tests présente les tests unitaires et d'intégration.

Intégrer les tests dans la chaîne d'intégration continue

Avec GitHub Actions, un fichier .github/workflows/securite.yml exécute les contrôles à chaque pull request :

name: securite
on: [pull_request]

jobs:
  controles:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0                       # tout l'historique, pour la recherche de secrets
      - uses: actions/setup-node@v4
        with:
          node-version: 24
      - run: npm ci
      - run: npm test                          # dont la matrice de contrôle d'accès
      - run: npm audit --omit=dev --audit-level=high
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - run: pipx run semgrep scan --config p/owasp-top-ten --error

Une règle de protection de la branche principale exige que ce workflow réussisse et qu'un relecteur approuve avant toute fusion. Le scan ZAP se lance après le déploiement en préproduction, dans un autre workflow. Le chapitre Sécurité dans la CI : SAST, dépendances et secrets du cours CI/CD détaille cette démarche DevSecOps, avec ses équivalents dans GitLab CI.

Le test d'intrusion et le rapport d'audit

Un test d'intrusion (pentest) est une attaque simulée menée par un expert, avec l'accord écrit de l'organisation. La convention fixe le périmètre (quelles applications, quelles adresses), les dates, les techniques autorisées ou interdites (pas de déni de service, pas d'ingénierie sociale…) et les contacts en cas de problème. Sans elle, le test est une intrusion au sens du Code pénal (chapitre 1). On distingue le test en boîte noire (le testeur ne sait rien), en boîte grise (il a un compte utilisateur) et en boîte blanche (il a le code). En France, l'ANSSI qualifie des prestataires d'audit (label PASSI) ; des plateformes de bug bounty rémunèrent les chercheurs qui signalent des failles dans un cadre défini.

Un audit, qu'il soit mené par toi sur ton projet ou par un prestataire, se termine par un rapport. Sa structure :

1. Synthèse pour la direction : périmètre, dates, niveau de sécurité global, les failles les plus graves en langage non technique, les priorités.
2. Méthodologie : outils, référentiel suivi (OWASP Top 10, ASVS, WSTG), limites du test.
3. Une fiche par vulnérabilité :

4. Plan d'action : les corrections classées par priorité (gravité, facilité d'exploitation, coût de correction), avec un responsable et une date.

Après correction, on vérifie : on rejoue la preuve, qui doit échouer, et on garde le test automatisé qui empêche le retour de la faille.

router.get('/api/recherche', async (req, res) => {
  try {
    const sql = "SELECT * FROM ligne_frais WHERE libelle LIKE '%" + req.query.q + "%'";
    const [lignes] = await pool.query(sql);
    res.send(`<h2>Résultats pour ${req.query.q}</h2>` + lignes.map(l => `<p>${l.libelle}</p>`).join(''));
  } catch (e) {
    res.status(500).send(e.stack);
  }
});