Sécurité applicative

Questions fréquentes

C'est quoi la sécurité applicative ?

La sécurité applicative regroupe les 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 : contrôle d'accès, requêtes préparées, encodage des sorties, gestion des mots de passe et des sessions, mises à jour des dépendances, journalisation. Elle vise à garantir la disponibilité, l'intégrité, la confidentialité et la traçabilité (les critères DICP). Au BTS SIO, c'est le cœur de l'écrit E7 de l'option SLAM.

C'est quoi l'OWASP Top 10, et quelle est la dernière version ?

L'OWASP Top 10 est la liste des dix catégories de risques les plus critiques pour les applications web, publiée par la fondation OWASP. La version en vigueur est l'OWASP Top 10:2025, qui remplace celle de 2021 : le contrôle d'accès défaillant reste premier et absorbe la SSRF, et deux catégories apparaissent, la chaîne d'approvisionnement logicielle (A03) et la mauvaise gestion des conditions exceptionnelles (A10). Écris toujours l'année avec le code : A03:2021 et A03:2025 ne désignent pas la même catégorie.

Quelles sont les failles les plus courantes d'une application web ?

Le contrôle d'accès défaillant arrive en tête du Top 10 : un utilisateur lit ou modifie les données d'un autre en changeant un identifiant (IDOR), ou appelle une fonction réservée. Viennent ensuite la mauvaise configuration, les dépendances vulnérables, les défauts cryptographiques et les injections (SQL, XSS). Les injections comptent le plus de vulnérabilités publiées : plus de 30 000 pour le seul XSS selon l'OWASP.

Quelle est la différence entre une faille XSS et une faille CSRF ?

Une XSS injecte du JavaScript dans une page du site : le script s'exécute dans le navigateur de la victime avec les droits du site, et peut lire la page, voler la session ou agir à sa place. Une CSRF n'injecte rien dans le site : une page d'un autre site fait envoyer une requête par le navigateur de la victime, qui y joint ses cookies, sans pouvoir lire la réponse. On se protège de la XSS en encodant les sorties, de la CSRF avec un jeton anti-CSRF et l'attribut SameSite des cookies.

Comment se protéger d'une injection SQL ?

Avec des requêtes préparées : la structure de la requête est envoyée d'abord, avec des marqueurs, et les valeurs ensuite, séparément, de sorte qu'elles ne peuvent jamais devenir du code SQL. Échapper les apostrophes à la main ne suffit pas. Les noms de colonnes ou de tables, qu'un marqueur ne peut pas remplacer, passent par une liste blanche, et le compte SQL de l'application n'a que les droits nécessaires pour limiter les dégâts.

Quelle est la différence entre authentification et autorisation ?

L'authentification vérifie qui est l'utilisateur (identifiant et mot de passe, jeton, biométrie). L'autorisation vérifie ce qu'il a le droit de faire, sur quelle donnée (lire sa propre fiche, valider une fiche quand on est comptable). La plupart des contrôles d'accès défaillants viennent d'une application qui authentifie correctement mais oublie l'autorisation (chapitre 3).

Quelle est la différence entre hachage et chiffrement ?

Le hachage est à sens unique : on ne retrouve pas la donnée d'origine à partir de l'empreinte. Il sert à stocker les mots de passe, avec un algorithme lent et salé comme Argon2id ou bcrypt. Le chiffrement est réversible avec une clé : il sert aux données qu'on doit relire, comme un IBAN, avec AES-256-GCM par exemple (chapitre 6). « Chiffrer les mots de passe » est donc une erreur.

Session ou JWT : que choisir ?

La session garde l'état de la connexion sur le serveur et ne donne au navigateur qu'un identifiant dans un cookie : elle se révoque immédiatement et convient bien à une application web classique. Le JWT contient lui-même l'identité, signée par le serveur : il convient aux API consommées par une application mobile ou plusieurs services, mais se révoque mal avant son expiration, d'où des jetons d'accès courts. Un JWT est signé, pas chiffré : son contenu est lisible par tous (comparaison détaillée).

C'est quoi SAST et DAST ?

Le SAST (Static Application Security Testing) analyse le code source sans l'exécuter, avec des outils comme Semgrep ou SonarQube : il repère les requêtes concaténées, les fonctions dangereuses, les secrets écrits en dur. Le DAST (Dynamic Application Security Testing) attaque l'application en fonctionnement, comme le ferait un attaquant, avec des outils comme ZAP : il repère les en-têtes manquants, les XSS, les injections visibles de l'extérieur. Les deux se complètent, avec l'analyse des dépendances (SCA) et la revue de code (chapitre 14).

Quelle sécurité tombe à l'E7 SLAM ?

L'écrit E7 « Cybersécurité des services informatiques » (4 heures) est une étude de cas : analyse de risques DICP, protection des mots de passe et des données, méthodes de contrôle des droits à écrire, comptes et droits SQL, journalisation et requêtes d'analyse des journaux, sécurisation d'une API REST, authentification (mot de passe oublié, SSO), parfois une application mobile, et des questions de droit (RGPD, Code pénal). Jusqu'à la session 2024, cette épreuve s'appelait E6 (U6) : les sujets 2022 à 2024 restent d'excellents entraînements (méthode et cas corrigé).