Conception sécurisée (A06) et protection des données dès la conception

Une conception non sécurisée (Insecure Design, A06:2025) est un défaut de sécurité qui vient de ce que l'application est censée faire, et non de la façon dont elle est codée : une règle métier absente, un processus contournable, une architecture qui ne prévoit pas l'abus. Ce chapitre montre les failles de logique métier, la modélisation des menaces (STRIDE, cas d'abus), l'écriture d'exigences de sécurité avec l'ASVS, la protection des données dès la conception imposée par le RGPD et l'intégration de la sécurité à chaque étape du développement.

C'est quoi une conception non sécurisée ?

L'OWASP distingue deux sources de failles. Un défaut d'implémentation : la conception prévoyait le bon contrôle, le code l'a oublié ou mal écrit (une requête concaténée, un middleware manquant). Un défaut de conception : même un code parfait reste vulnérable, parce que le contrôle n'a jamais été prévu. On ne corrige pas une conception défaillante en relisant le code ligne à ligne ; il faut revenir à la spécification.

Exemples de défauts de conception :

• la récupération de mot de passe repose sur une question secrète (« ville de naissance ? ») ;
• aucune limite au nombre de tentatives de connexion, d'envois de SMS ou de bons de réduction ;
• un circuit de validation dont une étape peut être sautée en appelant directement l'étape suivante ;
• des données sensibles collectées « au cas où », sans besoin réel ;
• une fonctionnalité d'administration accessible depuis Internet alors qu'elle ne sert qu'en interne.

Les failles de logique métier

Une faille de logique métier exploite les règles de gestion de l'application. Aucun scanner automatique ne la trouve : il faut comprendre le métier.

Le cas du double remboursement est une condition de concurrence (race condition) : deux requêtes lisent l'état VA en même temps, et chacune déclenche un virement. La parade est de faire la vérification et le changement d'état en une seule opération atomique, ou dans une transaction qui verrouille la ligne :

const [resultat] = await pool.execute(
  "UPDATE fiche_frais SET etat = 'RB', date_modif = NOW() WHERE id = ? AND etat = 'VA'",
  [idFiche]
);
if (resultat.affectedRows === 0) {
  return res.status(409).json({ erreur: 'Fiche déjà remboursée ou non validée' });
}
await declencherVirement(idFiche);    // n'est atteint qu'une seule fois

Le chapitre Transactions du cours SQL explique les verrous et les niveaux d'isolation.

Penser comme un attaquant : cas d'abus et modélisation des menaces

Les spécifications décrivent ce que les utilisateurs doivent pouvoir faire. La conception sécurisée ajoute ce qu'un utilisateur malveillant voudrait faire. Pour chaque récit utilisateur, on écrit un ou plusieurs cas d'abus :

La modélisation des menaces (threat modeling) systématise cette démarche. On dessine les flux de données de l'application (qui envoie quoi à qui, où les données sont stockées), on repère les frontières de confiance (entre le navigateur et l'API, entre l'API et la base, entre l'application et un service tiers), puis on passe chaque élément au crible d'une grille. La plus connue est STRIDE, proposée par Microsoft :

Pour une analyse de risques à l'échelle de l'organisation, l'ANSSI propose la méthode EBIOS Risk Manager, que tu rencontreras dans les sujets d'E7 (ateliers, événements redoutés, scénarios). Le cours Droit informatique et RGPD présente l'analyse d'impact relative à la protection des données (AIPD).

Écrire des exigences de sécurité

Une exigence de sécurité se rédige comme une exigence fonctionnelle : précise, vérifiable, avec un critère d'acceptation. « L'application doit être sécurisée » ne vaut rien ; « un visiteur ne peut lire que ses propres fiches ; une demande sur la fiche d'un autre renvoie 404 » se teste.

Récit : en tant que visiteur, je consulte mes fiches de frais.
Critères d'acceptation :
- seules les fiches dont id_visiteur est celui du visiteur connecté sont renvoyées ;
- une demande sur la fiche d'un autre visiteur renvoie 404 et est journalisée ;
- sans jeton valide, l'API renvoie 401 ;
- la liste est paginée, 50 fiches au maximum par page.

Pour ne rien oublier, on s'appuie sur un référentiel. L'OWASP ASVS (Application Security Verification Standard, version 5.0 publiée en 2025) liste des centaines d'exigences vérifiables, rangées par thème (authentification, sessions, contrôle d'accès, validation, cryptographie, journalisation, API, fichiers…) et par niveau :

« Mettre en œuvre et vérifier la conformité d'une solution applicative à un référentiel » se traduit concrètement par : choisir un niveau de l'ASVS, en tirer la liste des exigences applicables, et vérifier chacune par un test, une revue de code ou un audit.

Protection des données dès la conception et par défaut

L'article 25 du RGPD impose au responsable de traitement la protection des données dès la conception (privacy by design) et par défaut (privacy by default) : les mesures techniques et organisationnelles se prévoient dès la conception du traitement, et les réglages par défaut ne traitent que les données nécessaires à chaque finalité. Pour un développeur, cela se traduit par des choix concrets :

Quand un traitement présente un risque élevé pour les personnes (données de santé, données biométriques, surveillance systématique), une analyse d'impact (AIPD, article 35) est obligatoire avant sa mise en œuvre. Le cours Droit informatique et RGPD et le chapitre Données personnelles et CNIL du cours CEJM détaillent ces obligations.

Sécuriser tout le cycle de développement

La sécurité coûte d'autant moins cher qu'elle intervient tôt. Corriger un défaut de conception pendant l'analyse prend une réunion ; le corriger après la mise en production peut imposer de refondre l'application. On parle d'approche DevSecOps ou de « décaler la sécurité vers la gauche » (shift left) : chaque étape du cycle a ses activités de sécurité.

Le chapitre 14 détaille les outils de test ; le chapitre 12, la surveillance en exploitation.