C'est quoi la sécurité applicative ?

La sécurité applicative est l'ensemble des mesures prises pendant la conception, le développement et l'exploitation d'une application pour protéger ses données et son fonctionnement contre les attaques. Ce chapitre explique pourquoi elle compte, pose le vocabulaire (vulnérabilité, menace, risque, CVE), les critères DICP et les grands principes qui reviennent dans tous les autres chapitres. Il présente aussi l'application fil rouge du cours et ce que la loi dit des tests de sécurité.

Pourquoi sécuriser une application

La plupart des grandes fuites de données ne viennent pas d'attaques géniales, mais d'erreurs de développement ou de maintenance très ordinaires.

Quatre erreurs, quatre catégories du Top 10 que tu verras dans ce cours : une dépendance pas à jour, un contrôle d'accès absent, une requête construite par concaténation, un composant tiers vulnérable. Aucune ne demandait de compétence exceptionnelle pour être évitée. Elles demandaient de connaître les risques et d'avoir les bons réflexes.

Pour l'organisation, une faille coûte cher : arrêt du service, enquête, notification des personnes concernées, sanctions de la CNIL, perte de clients. Pour toi, développeur, elle peut engager ta responsabilité et celle de ton employeur (responsabilité civile et pénale).

Les critères DICP

Une attaque cherche toujours à casser au moins une des garanties qu'un service doit à ses utilisateurs. Les sujets du BTS les appellent les critères de sécurité, regroupés sous le sigle DICP.

Tu rencontreras aussi le sigle anglais CIA (Confidentiality, Integrity, Availability), qui ne garde que les trois premiers critères. La preuve, parfois appelée traçabilité ou non-répudiation, repose sur la journalisation et l'authentification.

Dans une analyse de risques, chaque critère reçoit un niveau de besoin pour chaque donnée ou chaque processus (par exemple de 1, faible, à 4, critique). Un dossier médical a un besoin de confidentialité très élevé ; un catalogue public, un besoin de confidentialité nul mais un besoin de disponibilité réel. Ces niveaux guident les mesures : on ne protège pas tout de la même façon.

Vulnérabilité, menace, risque : le vocabulaire

Ces mots ne sont pas synonymes, et les confondre coûte des points à l'écrit.

On mesure souvent un risque par gravité × vraisemblance. Une vulnérabilité sans menace crédible ou sans impact pèse peu ; une vulnérabilité facile à exploiter sur des données sensibles passe en tête de la liste.

Trois sigles reviennent dans tous les avis de sécurité :

• CVE (Common Vulnerabilities and Exposures) : l'identifiant unique d'une vulnérabilité publiée dans un produit précis, par exemple CVE-2021-44228 pour Log4Shell.
• CWE (Common Weakness Enumeration) : le type de faiblesse, indépendamment du produit. CWE-89 est l'injection SQL, CWE-79 le cross-site scripting. Chaque catégorie de l'OWASP Top 10 regroupe des CWE.
• CVSS (Common Vulnerability Scoring System) : une note de gravité de 0 à 10 calculée à partir de critères normalisés (accès réseau ou local, complexité, privilèges nécessaires, impact sur chaque critère). Le chapitre 5 apprend à la lire.

Les principes de base

Ces principes reviennent à chaque chapitre. Ils te serviront aussi à justifier une correction à l'écrit : « j'applique le principe du moindre privilège » vaut mieux que « c'est plus sûr ».

Ne jamais faire confiance aux entrées. Tout ce qui vient de l'extérieur du serveur peut être forgé : paramètres d'URL, champs de formulaire, champs cachés, en-têtes HTTP, cookies, corps JSON, noms et contenus de fichiers envoyés, réponses d'une API tierce. Un contrôle fait seulement dans le navigateur (JavaScript, attribut required, menu déroulant) se contourne en quelques secondes avec les outils de développement ou curl. Le serveur doit tout revérifier.

Moindre privilège. Chaque utilisateur, chaque compte de service, chaque processus n'a que les droits dont il a besoin, et pas plus. Le compte MySQL de l'application n'a pas besoin de DROP TABLE ; un visiteur n'a pas besoin de voir les fiches des autres.

Refus par défaut. Ce qui n'est pas explicitement autorisé est interdit. Une route oubliée doit renvoyer « accès refusé », pas « accès total ».

Défense en profondeur. On empile plusieurs protections indépendantes, pour qu'une seule défaillance ne suffise pas : requête préparée et compte SQL limité et journalisation des erreurs ; échappement des sorties et en-tête CSP et cookie HttpOnly.

Réduire la surface d'attaque. Chaque route, chaque port ouvert, chaque dépendance, chaque fonctionnalité de débogage est une porte de plus. Ce qui ne sert pas doit disparaître.

Échouer en sécurité. Quand une erreur survient pendant un contrôle (base injoignable, exception imprévue), l'application refuse l'accès au lieu de le laisser passer (chapitre 12).

Pas de sécurité par l'obscurité. Cacher une route d'administration derrière une URL compliquée ou utiliser des identifiants imprévisibles ne remplace pas un contrôle d'accès. L'URL finit toujours par fuiter : historique, journaux, capture d'écran, code du front.

Séparation des responsabilités. Une même personne ne devrait pas pouvoir à la fois saisir une dépense, la valider et la rembourser. Côté développement, personne ne pousse en production sans relecture.

Où se cache une faille

Une application web moderne est une chaîne de composants. Chaque maillon a ses risques, et le Top 10 les couvre tous.

La frontière de confiance passe entre le navigateur et le serveur. Tout ce qui est à gauche est sous le contrôle de l'utilisateur, donc potentiellement de l'attaquant : le code JavaScript du front, les cookies, les requêtes. Le serveur est le seul endroit où un contrôle a de la valeur.

L'application fil rouge : AppliFrais

Les exemples du cours tournent autour d'AppliFrais, l'application de gestion des frais de déplacement des visiteurs médicaux du laboratoire GSB, un cas d'entreprise classique du BTS SIO. Un visiteur saisit chaque mois sa fiche de frais (nuits d'hôtel, repas, kilomètres, frais hors forfait avec justificatif) ; un comptable la contrôle, la valide puis la met en paiement.

Les tables utiles pour le cours :

utilisateur (id, login, email, mdp_hash, role, actif)

fiche_frais (id, #id_visiteur, mois, montant_valide, etat, date_modif)

ligne_frais (id, #id_fiche, date_frais, libelle, montant, justificatif)

journal (id, date_heure, login, ip, action, ressource, resultat)

• id_visiteur : clé étrangère en référence à id de utilisateur
• id_fiche : clé étrangère en référence à id de fiche_frais

L'état d'une fiche suit un cycle : CR (en cours de saisie), CL (clôturée par le visiteur), VA (validée par le comptable), RB (remboursée). Le cycle compte pour la sécurité : un visiteur ne doit plus pouvoir modifier une fiche validée, et seul un comptable valide.

Ce que dit la loi

Tester la sécurité d'un système sans autorisation est un délit, même « pour voir », même sans rien casser. Le Code pénal punit les atteintes aux systèmes de traitement automatisé de données (articles 323-1 et suivants) :

Quand le système contient des données personnelles mises en œuvre par l'État, les peines des articles 323-1 à 323-3 montent à 7 ans et 300 000 €.

Côté données personnelles, le RGPD impose au responsable de traitement des « mesures techniques et organisationnelles appropriées » pour garantir un niveau de sécurité adapté au risque (article 32), la protection des données dès la conception et par défaut (article 25) et la notification d'une violation à la CNIL dans les 72 heures (article 33). Le cours Droit informatique et RGPD détaille ces obligations.

La sécurité applicative au BTS SIO

Le référentiel du BTS SIO (arrêté du 8 juillet 2024, sessions 2025 et suivantes) consacre le bloc 3, « Cybersécurité des services informatiques », à la sécurité. Quatre compétences sont communes aux deux options : protéger les données à caractère personnel, préserver l'identité numérique de l'organisation, sécuriser les équipements et les usages des utilisateurs, garantir la disponibilité, l'intégrité et la confidentialité des services et des données face aux cyberattaques. La cinquième est propre à l'option SLAM : « Assurer la cybersécurité d'une solution applicative et de son développement ». Elle couvre ce que ce cours traite : prendre en compte la sécurité dès le projet, vérifier la conformité à un référentiel comme l'OWASP, prévenir les attaques, analyser les connexions dans les journaux et proposer des contre-mesures après un incident.

L'écrit de cybersécurité s'appelait E6 (unité U6) pour les sessions 2022 à 2024. Les sujets de ces sessions restent d'excellents entraînements : on y retrouve les mêmes thèmes (risques, mots de passe, droits, journaux, API, RGPD). Le chapitre 15 donne la méthode et un cas corrigé.

Exercice 1 sur 3 Vulnérabilité, menace ou contre-mesure ? Réussi À revoir

Classe chaque élément dans la bonne case : actif, vulnérabilité, menace, attaque, impact ou contre-mesure.

1. Un ancien salarié qui garde rancune à l'entreprise.
2. Le formulaire de connexion n'impose aucune limite au nombre d'essais.
3. La base des fiches de frais et des RIB des visiteurs.
4. Un script essaie 50 000 mots de passe sur le compte du comptable.
5. Bloquer temporairement un compte après dix échecs consécutifs.
6. Des remboursements versés sur un compte bancaire frauduleux.

Voir la réponseMasquer la réponse de l'exercice 1

1. Menace : un acteur qui pourrait vouloir nuire.
2. Vulnérabilité : une faiblesse exploitable, qui rend la force brute possible.
3. Actif : ce qu'on protège.
4. Attaque : l'exploitation de la vulnérabilité 2 par la menace (ici, quelqu'un qui dispose d'un script).
5. Contre-mesure : elle supprime la vulnérabilité 2 (limiter les tentatives).
6. Impact : la conséquence financière pour le laboratoire.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 3 Quel critère DICP ? Réussi À revoir

Pour chaque incident, indique le ou les critères atteints.

1. Un visiteur affiche la fiche de frais d'un collègue en changeant le numéro dans l'URL.
2. Un comptable valide une fiche, mais l'application n'enregistre ni qui l'a validée ni quand.
3. Un fichier envoyé de 2 Go remplit le disque du serveur ; l'API ne répond plus.
4. Un visiteur repasse sa fiche validée à l'état « en cours » et augmente un montant.

Voir la réponseMasquer la réponse de l'exercice 2

1. Confidentialité : il lit des données qui ne lui sont pas destinées.
2. Preuve (traçabilité) : en cas de fraude, impossible de savoir qui a validé.
3. Disponibilité : le service est interrompu pour tout le monde.
4. Intégrité : une donnée est modifiée par quelqu'un qui n'en a pas le droit. Si aucune trace ne permet de le détecter, la preuve est aussi atteinte.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 3 Justifier par un principe Réussi À revoir

Pour chaque mesure, nomme le principe de sécurité qu'elle applique.

1. Le compte MySQL app_frais a seulement les droits SELECT, INSERT et UPDATE sur les tables de l'application.
2. Toutes les routes de l'API exigent un jeton valide, sauf /api/connexion.
3. Le serveur revérifie que le montant est positif, même si le formulaire l'interdit déjà.
4. La page phpMyAdmin et la route /api/debug sont supprimées du serveur de production.
5. Les mots de passe sont hachés et les sauvegardes de la base sont chiffrées.

Voir la réponseMasquer la réponse de l'exercice 3

1. Moindre privilège : si une injection réussit malgré tout, elle ne peut ni supprimer une table ni créer un compte.
2. Refus par défaut : une route ajoutée plus tard sera protégée sans qu'on y pense.
3. Ne jamais faire confiance aux entrées : le contrôle du navigateur se contourne avec curl.
4. Réduction de la surface d'attaque : un outil d'administration ou de débogage exposé est une porte d'entrée.
5. Défense en profondeur : une sauvegarde volée ne révèle ni les données en clair ni les mots de passe.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Pour aller plus loin. Le vocabulaire du risque et la méthode pour hiérarchiser les menaces sont développés dans le cours Analyse de risques, commun aux deux options.