Questions d'entretien Web Security

Non. La validation côté client est un pur confort d'usage — un attaquant peut désactiver JavaScript, modifier la requête dans le navigateur ou Burp, ou appeler votre API directement avec curl, ce qui la contourne totalement. Les contrôles de sécurité (validation, autorisation, assainissement) doivent s'imposer sur le serveur, le seul endroit que vous maîtrisez. L'erreur est de prendre le navigateur pour une frontière de confiance ; il ne l'est pas, car le client tourne sur la machine de l'attaquant. Les contrôles côté client sont parfaits pour un retour rapide, jamais pour la sécurité.

Non. Supprimer le cookie retire seulement l'identifiant de votre navigateur — l'enregistrement de session (ou un JWT encore valide) sur le serveur reste généralement utilisable jusqu'à son expiration ou son invalidation explicite. Un attaquant ayant déjà capturé le jeton peut continuer à l'utiliser. L'erreur prend le cookie pour la session elle-même ; ce n'est qu'un pointeur vers l'état côté serveur. La vraie déconnexion doit invalider la session côté serveur, ou révoquer et limiter la durée du jeton.

En grande partie non. Le nom d'hôte de destination est envoyé en clair dans l'extension SNI du ClientHello de TLS, et votre requête DNS le révèle généralement aussi, de sorte qu'un FAI ou un réseau peut voir QUEL site vous visitez même en HTTPS — il ne peut simplement pas lire le chemin ni le contenu. Le ClientHello chiffré (ECH) et le DNS-over-HTTPS peuvent combler cette faille, mais ils ne sont pas universels. « HTTPS cache tout » est l'idée fausse.

Non. TLS/HTTPS sécurise les données en transit entre client et serveur ; une fois reçues, elles sont déchiffrées et traitées en clair par l'application, puis stockées selon la configuration de la base. Protéger les données au repos est un sujet distinct — chiffrement de disque/colonne, un KMS et le contrôle d'accès. Confondre « on utilise HTTPS » avec « nos données stockées sont chiffrées » est une idée fausse courante et dangereuse.

Non. HTTPS chiffre le canal pour que les attaquants ne puissent ni lire ni altérer le trafic en transit, mais l'entrée malveillante arrive, est déchiffrée et traitée par votre application exactement comme avant. L'injection SQL et le XSS sont des failles applicatives corrigées par des requêtes paramétrées et l'encodage de sortie, pas par le chiffrement du transport. L'erreur suppose que le chiffrement assainit le contenu — il ne le fait pas ; l'attaquant envoie simplement la charge via la connexion HTTPS.

Non. Le mode privé/incognito empêche seulement le navigateur local d'enregistrer l'historique, les cookies et les données de formulaire après la session — il ne change rien au chemin réseau. Votre FAI, le proxy de votre employeur, le résolveur DNS et les sites où vous vous connectez voient encore votre activité. L'erreur est « incognito = invisible » ; en réalité c'est de la confidentialité face aux autres utilisateurs du même appareil, pas de l'anonymat face au réseau.

Non. POST place simplement les paramètres dans le corps de la requête au lieu de l'URL ; ce corps est en clair et parfaitement visible pour quiconque voit le trafic, sauf en HTTPS. POST est préférable pour les actions qui modifient l'état et garde les paramètres hors des URL, des journaux et de l'historique, mais il n'offre aucune confidentialité en soi. L'erreur confond « pas dans l'URL » et « chiffré » — seul TLS chiffre les données de l'une ou l'autre méthode en transit.

Le contenu non fiable que le modèle ingère peut porter des instructions — c'est l'injection de prompt indirecte. Vous ne pouvez pas empêcher totalement le modèle d'être influencé, alors isolez le contenu récupéré en tant que donnée, limitez les outils/permissions de l'agent, exigez une confirmation pour les actions sensibles, et évitez de lui confier des secrets qu'il pourrait être contraint de divulguer. Supposer que le modèle ignorera simplement les instructions injectées, c'est exactement le mode de défaillance exploité.

C'est la « gestion incorrecte des sorties » d'OWASP LLM : une sortie de modèle influencée par l'entrée utilisateur peut devenir une injection de commande lorsqu'elle est transmise à un shell ou à eval. Traitez-la comme non fiable — faites correspondre les intentions à une petite liste blanche d'actions paramétrées, validez strictement et exécutez dans un bac à sable plutôt que de lancer des chaînes générées brutes. Faire confiance à la sortie, augmenter la limite de jetons ou se contenter de journaliser n'arrête en rien l'injection.

Une redirection ouverte sur un flux d'authentification permet à un attaquant de forger un lien de connexion d'apparence fiable qui, après authentification, envoie l'utilisateur — et potentiellement un code d'autorisation ou un jeton — vers un domaine contrôlé par l'attaquant, permettant le détournement de compte et un phishing convaincant. Corrigez-le en allow-listant strictement les redirect URI exacts côté serveur et en rejetant tout le reste. Ce n'est ni cosmétique ni un problème de performance, et HTTPS n'aide pas car la destination de l'attaquant peut aussi être un site HTTPS valide.

Si le navigateur joint automatiquement le cookie de session, une page malveillante peut déclencher le virement au nom de la victime — c'est le Cross-Site Request Forgery (CSRF). Protégez les requêtes qui modifient un état avec des jetons anti-CSRF et des cookies SameSite, et vérifiez l'en-tête Origin/Referer. Le cookie prouve l'identité mais pas l'intention, un CAPTCHA de connexion ne protège pas une action déjà authentifiée, et HTTPS protège la confidentialité du transport, pas la falsification de requête.

Si un attaquant peut téléverser un fichier exécutable côté serveur (ou du HTML/SVG) dans un répertoire servi, il peut obtenir une exécution de code à distance ou un XSS stocké. Validez le vrai type de contenu, stockez les fichiers hors de la racine web ou sur un stockage non exécutant, randomisez les noms de fichiers et servez-les de manière à empêcher leur exécution ou leur interprétation comme balisage. Les chargements de page plus lents et la consommation disque sont des problèmes opérationnels, pas le risque de sécurité exploité ici.

Récupérer côté serveur des URL contrôlées par l'attaquant relève du Server-Side Request Forgery (SSRF) : cela permet d'atteindre des services internes ou le point de terminaison de métadonnées cloud pour voler des identifiants. Pour l'atténuer, restreignez les hôtes et schémas autorisés par allow-list, bloquez les plages privées et link-local (en revérifiant après chaque redirection) et durcissez l'accès aux métadonnées avec IMDSv2. Dire qu'il n'y a aucun risque ignore l'accès que confère la requête, et un spinner de chargement ou une mise en cache ne change rien aux destinations que le serveur peut joindre.

Il s'agit d'un contrôle d'accès défaillant (IDOR) : le serveur ne vérifie pas que l'utilisateur authentifié a le droit d'accéder à l'objet demandé. La correction est une autorisation par objet appliquée côté serveur à chaque requête. Nettoyer le nombre n'établit pas la propriété. Chiffrer ou masquer l'ID relève de l'obscurité et reste devinable, divulgable ou rejouable. La méthode HTTP n'a aucun rapport avec l'autorisation. Vérifiez toujours le droit de l'appelant sur l'objet précis avant de le renvoyer.

`alg: none` permet à quiconque de forger un jeton non signé d'apparence valide et d'usurper n'importe quel utilisateur — un contournement total de l'authentification, pas un détail. Corrigez-le en autorisant côté serveur une liste blanche des algorithmes attendus et en vérifiant toujours la signature avec la bonne clé ; ne faites jamais confiance à l'en-tête alg du jeton pour choisir la méthode de vérification. Une expiration plus longue ou un changement de stockage ne fait rien contre des jetons forgés et non signés. C'est critique et exploitable, documenter n'est donc pas une correction.

L'injection de prompt ne se résout pas entièrement avec plus de texte ; supposez que le modèle peut être détourné et contraignez ce qu'il est autorisé à FAIRE. Donnez aux outils le moindre privilège, conditionnez les actions à fort impact à une confirmation humaine, et validez ou isolez les appels d'outils avant d'agir (OWASP LLM « excès d'autonomie » et « gestion inadéquate des sorties »). Implorer dans le prompt système est contournable. Une température plus élevée n'ajoute que de l'aléa, et la seule journalisation enregistre le dommage sans empêcher l'action injectée.

C'est une faille d'affectation en masse (over-posting) : le serveur mappe aveuglément le JSON client sur des champs sensibles du modèle. Corrigez-la en ne liant qu'une liste blanche explicite des champs autorisés (DTO / strong params) afin que des attributs privilégiés comme isAdmin ne puissent pas être définis par le client. Masquer le champ dans le frontend et ajouter une validation côté client se contournent tous deux avec une requête brute. Renommer isAdmin relève de l'obscurité, facilement découverte. Contrôlez quels champs sont liés, côté serveur.

Les requêtes paramétrées sont la vraie correction : elles séparent le code des données, de sorte que la saisie utilisateur est toujours traitée comme une valeur, jamais comme du SQL pouvant modifier la structure de la requête. L'échappement manuel est source d'erreurs et contournable selon les encodages et les dialectes. Un WAF est un contrôle compensatoire, pas un correctif, et les astuces d'encodage le déjouent. Une vérification de longueur n'empêche en rien l'injection. Corrigez au niveau de la requête.

Le XSS stocké se corrige en encodant les données pour le contexte exact où elles sont rendues (corps HTML, attribut, JavaScript, URL) afin que le navigateur les traite comme du texte, avec une Content-Security-Policy en seconde couche. Mettre le mot « script » en liste noire se contourne trivialement via des gestionnaires d'événements, la casse mixte et les encodages. Vous ne pouvez pas forcer vos utilisateurs à désactiver JavaScript. Demander aux utilisateurs de ne pas saisir de HTML n'est pas un contrôle applicable. Encodez à la sortie, à chaque rendu.

Le code transitif s'exécute dans votre application, donc une CVE critique est votre risque. Évaluez si le chemin de code vulnérable est réellement atteignable, puis remédiez en montant ou en surchargeant la version (ou en atténuant) et vérifiez en production. L'ignorer parce qu'elle est transitive laisse un trou connu qu'un attaquant peut exploiter. Supprimer l'avertissement ne fait que masquer le signal. Réinstaller node_modules ramène la même version vulnérable. Suivez-la via le SCA, ne la faites pas taire.

La modélisation des menaces est la moins coûteuse et la plus efficace à la conception, avant que le code ne fige les décisions : parcourez les flux de données, énumérez les menaces avec un cadre comme STRIDE, intégrez les mesures, puis révisez à mesure que la conception évolue. La faire seulement après un incident ou au pentest annuel révèle les problèmes une fois qu'ils sont coûteux à corriger et déjà exposés. Et se fier à des « développeurs prudents » est un espoir, non un contrôle reproductible et auditable.

Prouvez la vulnérabilité sans nuire au client ni accumuler ses données : montrez que vous pouvez lire des données arbitraires via la version de la base, le schéma ou un seul échantillon anonymisé, puis arrêtez-vous. Extraire l'intégralité des données personnelles crée une responsabilité de notification de violation et de traitement pour les deux parties. Supprimer une table est destructeur et dépasse de loin la preuve de concept. Chiffrer la base et exiger une prime, c'est de l'extorsion, pas un test : c'est un délit, pas un constat.

Un rapport utile pousse à la remédiation : classez par risque métier (probabilité × impact), mettez en avant les chaînes d'exploitation qui mènent à une compromission critique et donnez des correctifs actionnables pour chaque constat. Le classement alphabétique enterre l'essentiel sous ce qui commence par « A ». Le plus long écrit d'abord récompense le verbiage plutôt que la gravité. Supprimer les constats faibles cache un risque réel et les motifs dont le client a besoin pour la défense en profondeur, le laissant avec une image faussement rassurante.

Les données sensibles ne devraient jamais atteindre les journaux : masquez ou caviardez à la source d'abord pour arrêter l'hémorragie, puis remédiez aux journaux existants et resserrez les accès. PCI DSS interdit de stocker ainsi des PAN complets et des CVV, et les mots de passe ne devraient jamais être journalisés. Des journaux « internes » restent une cible de choix. Chiffrer ou restreindre l'accès au stockage laisse quand même des secrets en clair dans les journaux, accessibles à quiconque a un droit de lecture — sauvegardes, pipelines SIEM et administrateurs les voient tous.

La prompt injection directe, c'est quand un utilisateur tape des instructions adverses directement dans le prompt pour écraser le system prompt ou les règles de sécurité. La prompt injection indirecte cache des instructions malveillantes dans du contenu externe que le modèle ingère ensuite — une page web, un e-mail, un PDF ou un document RAG — si bien que l'attaque se déclenche sans que la victime ne la tape jamais. L'injection indirecte est le plus grand risque parce que l'attaquant et la victime sont des personnes différentes, et que la charge arrive via des données que l'application fait implicitement confiance.

Le traitement non sécurisé des sorties consiste à faire confiance à ce que le modèle renvoie et à le transmettre à un système en aval sans validation ni encodage. Comme la sortie du modèle est influençable par l'attaquant, l'afficher en HTML brut cause du XSS, l'envoyer à un récupérateur d'URL cause du SSRF, et la passer à un shell ou une requête SQL cause une command ou SQL injection. La solution est de traiter la sortie du modèle exactement comme une entrée utilisateur non fiable : encodage de sortie sensible au contexte, allowlisting, assainissement et paramétrage avant qu'elle n'atteigne un sink.

L'OWASP Top 10 for LLM Applications est la liste consensuelle des risques les plus critiques lorsqu'on construit avec de grands modèles de langage. L'édition 2025 couvre la prompt injection, la divulgation d'informations sensibles, la supply chain, l'empoisonnement des données et du modèle, le traitement non sécurisé des sorties, l'excessive agency, la fuite de system prompt, les faiblesses des vecteurs et embeddings, la désinformation et la consommation non bornée. Elle existe parce que les listes appsec traditionnelles ne capturent pas les modes de défaillance propres aux LLM, et elle donne aux équipes un vocabulaire commun et une checklist pour prioriser les contrôles.

La sécurité RAG, c'est traiter chaque document récupéré comme une entrée non fiable. Risques clés : prompt injection indirecte cachée dans le contenu récupéré, empoisonnement de la base de connaissances ou des embeddings, et absence d'autorisation par utilisateur si bien que le modèle renvoie des données auxquelles l'utilisateur n'a pas accès. Les défenses incluent le contrôle d'accès appliqué à la récupération, la provenance du contenu et la vérification à l'ingestion, traiter le texte récupéré comme des données et non des instructions, la validation des sorties et l'isolement du magasin de vecteurs par locataire.

Un agent LLM transforme du texte en actions via des outils et des function calls, donc une prompt injection devient une action réelle — le risque d'excessive agency. Sécurisez-le en donnant à chaque outil le moindre privilège et la portée dont il a besoin, en validant et contraignant les arguments d'outils, en exigeant une confirmation humaine pour les actions sensibles ou irréversibles, en sandboxant l'exécution, en limitant le débit et en budgétant les appels, et en journalisant chaque invocation d'outil. Ne laissez jamais la sortie du modèle, influencée par des données non fiables, autoriser directement une action à fort impact.

SPF publie quelles IP peuvent envoyer du courrier pour un domaine. DKIM ajoute une signature cryptographique pour que le destinataire puisse vérifier que le message n'a pas été altéré et provient bien du domaine. DMARC relie les résultats SPF/DKIM à l'en-tête From: visible via l'« alignement », dit aux destinataires quoi faire en cas d'échec (none/quarantine/reject) et envoie des rapports. SPF et DKIM seuls ne protègent pas le From que voit l'utilisateur — c'est DMARC qui l'impose.

Intégrez la sécurité à chaque phase du SDLC plutôt que de tester à la fin : les exigences incluent des exigences de sécurité et de confidentialité, la conception inclut la modélisation des menaces, le développement suit des normes de codage sécurisé avec SAST, les tests ajoutent DAST et des revues, et la mise en production nécessite une validation — le tout gouverné par la politique, la séparation des tâches et la gestion des changements. Corriger les failles tôt coûte nettement moins cher qu'après la mise en production.

Un JWT comporte trois parties en base64url — en-tête, charge utile (revendications) et signature — réunies par des points. Le serveur signe l'en-tête et la charge utile avec un secret ou une clé privée, et vérifie cette signature à chaque requête pour faire confiance aux revendications sans état de session côté serveur. Pièges : accepter alg=none, la confusion de clés RS256 vers HS256, ne pas valider l'expiration/l'émetteur/l'audience, mettre des secrets dans la charge utile lisible, et l'absence de voie de révocation.

L'application redirige l'utilisateur vers le serveur d'autorisation pour se connecter et consentir. Le serveur redirige avec un code d'autorisation de courte durée. Le backend de l'application échange ensuite ce code (plus son secret client) au point de terminaison de jeton contre un jeton d'accès, via un canal arrière de serveur à serveur. Cela garde les jetons hors du navigateur/de l'URL. Les clients publics ajoutent PKCE pour lier le code au demandeur initial.

Les lockfiles épinglent les versions exactes et les empreintes des dépendances pour que chaque build résolve les mêmes octets vérifiés — rendant les builds reproductibles et bloquant les mises à jour malveillantes silencieuses. L'épinglage par empreinte, la vérification des empreintes d'intégrité et le cloisonnement des paquets internes dans un registre privé défendent aussi contre la confusion de dépendances, où un attaquant publie un paquet public de version supérieure correspondant à un nom interne pour détourner la résolution. Le principe : ne jamais laisser le build récupérer silencieusement du code non vérifié.

Le SAST lit le code source sans l'exécuter et trouve tôt les failles comme les points d'injection, mais avec beaucoup de faux positifs. Le DAST attaque l'application en cours d'exécution depuis l'extérieur, sans visibilité sur le code, et trouve de vrais problèmes exploitables mais tardivement et avec une couverture superficielle. L'IAST instrumente l'application en cours d'exécution pour corréler le comportement runtime au code, obtenant des résultats précis avec le contexte du code, mais nécessite une application sollicitée et le support d'un agent.

Utilisez la défense en profondeur : les hooks pre-commit (par ex. gitleaks) attrapent les secrets avant qu'ils n'arrivent, l'analyse CI côté serveur attrape ce qui passe, et des analyses périodiques de tout l'historique trouvent les anciennes fuites. Crucialement, un secret qui a atteint un dépôt distant doit être considéré comme compromis et tourné — supprimer le commit n'aide pas car il vit dans l'historique, les forks et les logs. Associez cela à un vrai gestionnaire de secrets pour que les secrets ne soient pas du tout dans le code.

Ne faites échouer le build que sur les résultats à forte confiance, à forte gravité et nouvellement introduits ; signalez (sans bloquer) tout le reste afin que les développeurs gardent confiance dans la porte. Gérez les faux positifs par des règles ajustées, une mise en référence des problèmes préexistants, et des suppressions documentées, limitées dans le temps et revues, plutôt que de désactiver les scanners. Une porte qui crie au loup finit ignorée ou contournée : la qualité du signal est tout l'enjeu.

Le shift-left consiste à déplacer la sécurité plus tôt — dans la conception, l'IDE et la pull request — là où les problèmes coûtent moins cher à corriger qu'en production. Vous évitez de bloquer les développeurs en faisant du chemin sécurisé le chemin facile : retour rapide et contextualisé, portes à faible taux de faux positifs qui n'échouent durement que sur les nouveaux problèmes à forte gravité, valeurs par défaut sécurisées et modèles « voie pavée », et en traitant la sécurité comme un facilitateur plutôt qu'un veto tardif.

La SCA inventorie les composants open-source et tiers qu'une application embarque — y compris les dépendances transitives — et signale ceux qui présentent des CVE connues ou des licences problématiques. Elle compte parce que la majeure partie du code moderne, ce sont des dépendances que vous n'avez pas écrites, et un seul paquet transitif vulnérable (comme Log4j) peut exposer toute l'application. Une bonne SCA priorise par accessibilité et exploitabilité, pas par simple décompte brut de CVE.

Un SBOM est un inventaire lisible par machine de chaque composant, bibliothèque et dépendance d'un logiciel, avec les versions et idéalement les empreintes (hashes). Il est important car lorsqu'une nouvelle vulnérabilité apparaît, vous pouvez interroger vos SBOM pour répondre instantanément à « sommes-nous affectés et où ? » au lieu de paniquer. Les deux standards dominants sont SPDX et CycloneDX, et les SBOM sont de plus en plus exigés par la réglementation et les achats.

L'encodage (comme le Base64) est un changement de format réversible sans secret — ce n'est pas de la sécurité. Le chiffrement est réversible avec une clé et protège la confidentialité. Le hachage est une fonction à sens unique produisant un condensé de longueur fixe, utilisé pour les vérifications d'intégrité et le stockage des mots de passe, et ne peut pas être inversé pour retrouver l'entrée.

Cela confirme le XSS. Si alert() s'est déclenché du tout, c'est que le navigateur a analysé et exécuté votre JavaScript injecté dans le contexte de la page : c'est la vulnérabilité. Une fenêtre vide signifie simplement que l'argument chaîne que vous avez transmis ne s'est pas affiché comme prévu (gestion des guillemets, encodage ou altération du contexte ont cassé le message), pas que la charge est bloquée. Le point d'exécution est actif ; vous affinez la charge à partir de là.

Non. CORS n'est pas une défense contre le CSRF : il assouplit en réalité la politique de même origine pour qu'une page puisse lire des réponses cross-origin qu'elle ne pourrait pas lire autrement. Le CSRF n'a pas besoin de lire la réponse ; il a juste besoin que le navigateur de la victime envoie une requête authentifiée qui modifie l'état. Les vraies défenses sont les jetons anti-CSRF, l'attribut de cookie SameSite, et la vérification d'Origin/Referer.

Non. Le cadenas signifie que le transport est chiffré et que le certificat est valide pour ce domaine : il ne dit rien sur l'honnêteté de l'opérateur ni sur le caractère malveillant du contenu. Des certificats gratuits et automatisés font que les sites d'hameçonnage et de logiciels malveillants ont presque toujours un cadenas parfaitement valide. HTTPS protège le canal, pas la destination.

Gardez les jetons d'accès à courte durée de vie (quelques minutes) pour qu'un jeton volé expire vite, et utilisez des jetons de rafraîchissement à plus longue durée pour obtenir de nouveaux jetons d'accès sans re-solliciter l'utilisateur. Faites tourner les refresh tokens à chaque utilisation et détectez la réutilisation d'un jeton consommé comme un signal de vol, en révoquant la chaîne. L'objectif est d'équilibrer la limitation de la fenêtre d'un jeton compromis sans forcer les utilisateurs à se réauthentifier sans cesse.

La divulgation coordonnée de vulnérabilités est un processus où un chercheur signale une faille en privé à l'éditeur, les deux parties s'accordent sur la correction et un délai, et les détails ne sont publiés qu'une fois un correctif disponible (ou le délai convenu écoulé). Elle équilibre le temps laissé aux défenseurs pour corriger et le droit du public à être informé. Un fichier security.txt et une politique claire rendent le signalement sans friction ; les programmes de bug bounty ajoutent des récompenses structurées par-dessus.

Le WSTG est une méthodologie adossée à une checklist qui fait passer une application par des catégories de test : collecte d'informations, configuration et déploiement, identité et authentification, autorisation, gestion de session, validation des entrées (injection/XSS), gestion des erreurs, cryptographie, logique métier et côté client. Il offre une couverture systématique avec des identifiants de test stables, de sorte que les constats sont reproductibles et que rien d'évident n'est oublié.

PTES définit sept phases : pré-engagement (périmètre, règles d'engagement, autorisation), collecte de renseignements (OSINT, reconnaissance), modélisation des menaces, analyse de vulnérabilités, exploitation, post-exploitation (pivotement, données de valeur, persistance) et reporting. La structure rend les missions reproductibles, défendables et liées au risque métier plutôt qu'à du hacking improvisé. Le pré-engagement et le reporting sont les phases que les juniors sous-estiment.

Commencez par comprendre le modèle de menace de l'application et où elle manipule des entrées non fiables, des secrets, de l'authentification et de l'autorisation. Utilisez le SAST pour scanner largement et le DAST contre l'application en cours d'exécution, mais traitez la sortie des outils comme des pistes, pas des constats — triez les faux positifs. Consacrez ensuite le temps humain aux zones à forte valeur et dépendantes du contexte que les outils manquent : logique d'autorisation, logique métier, usage de la cryptographie et frontières de confiance. Tracez le flux de données de la source au sink.

Un SDLC sécurisé intègre la sécurité à chaque phase au lieu de tester à la fin : exigences (cas de sécurité et d'abus), conception (modélisation des menaces), implémentation (standards de codage sécurisé, SAST/SCA dans l'IDE et la CI), tests (DAST, pentest), publication (gates et validation) et exploitation (surveillance, patching, feedback). Le shift-left déplace les défauts plus tôt, là où ils sont peu coûteux à corriger ; des modèles de maturité comme OWASP SAMM et BSIMM mesurent à quel point vous le faites réellement.

La modélisation des menaces répond à quatre questions : que construisons-nous, qu'est-ce qui peut mal tourner, qu'allons-nous y faire, et avons-nous bien fait le travail. Vous schématisez le système (souvent un diagramme de flux de données avec frontières de confiance), énumérez les menaces avec un framework comme STRIDE, priorisez par risque et assignez des mitigations. PASTA ajoute une saveur centrée sur le risque et l'attaquant ; les arbres d'attaque décomposent un seul objectif. Le faire au moment de la conception est bien moins coûteux que de patcher la production.

Un proxy direct se place devant les clients et émet des requêtes sortantes en leur nom — pour le contrôle de sortie, le filtrage, la mise en cache et l'anonymat. Un proxy inverse se place devant les serveurs et reçoit les requêtes entrantes en leur nom — pour la répartition de charge, la terminaison TLS, la mise en cache et comme façade de sécurité pour un WAF. Le sens vers lequel il fait face, côté client ou côté serveur, est la distinction clé.

Identifiez la stack à partir des en-têtes et du source, puis brute-forcez répertoires et fichiers avec gobuster ou feroxbuster en utilisant une bonne wordlist et les extensions pertinentes. Cherchez panneaux d'administration, sauvegardes, fichiers de configuration et points d'upload, et vérifiez les hôtes virtuels quand le site répond à un nom d'hôte.

Isolément, une SQLi expose ou modifie des données et peut atteindre le RCE ; une XSS stockée détourne les sessions dans le navigateur des victimes. Enchaînées, vous pouvez utiliser la SQLi pour implanter une charge XSS stockée qui se déclenche dans la session d'un admin, voler sa session et passer au contrôle total de l'application.

Un test d'intrusion passe par le pré-engagement (cadrage et règles d'engagement), la reconnaissance, le balayage et l'énumération, l'exploitation, la post-exploitation et le reporting. Chaque phase alimente la suivante, et le reporting est le moment où la valeur est réellement livrée au client.

Un scan de vulnérabilités est un inventaire automatisé, en largeur, des faiblesses potentielles, souvent avec des faux positifs. Un test d'intrusion est mené par un humain : il valide les trouvailles, les enchaîne et démontre un impact métier réel par une exploitation effective.

Un bon rapport sert deux publics : un résumé exécutif qui cadre le risque métier pour la direction, et des trouvailles détaillées et reproductibles avec preuves, évaluations de risque exactes et remédiation priorisée pour l'équipe technique. Le rapport — et non l'exploit — est le livrable.

Un SDLC sécurisé intègre la sécurité à chaque phase plutôt que de la rajouter à la fin. Les exigences incluent des cas de sécurité et d'abus, la conception ajoute la modélisation des menaces, le développement utilise le codage sécurisé et le SAST plus l'analyse des dépendances, les tests ajoutent le DAST et les tests d'intrusion, et l'exploitation ajoute la surveillance, les correctifs et la réponse aux incidents — en décalant la sécurité vers la gauche.

Imposer TLS partout, authentifier chaque requête (par exemple des jetons OAuth2/OIDC) et autoriser par objet pour que les utilisateurs n'atteignent que leurs propres données. Ajouter la validation des entrées, la limitation de débit et les quotas, la validation de schéma et une journalisation approfondie. La faille d'API la plus courante est l'autorisation au niveau objet défaillante, vérifiez donc la propriété à chaque accès à une ressource.

Examinez l'e-mail sans cliquer : vérifiez les en-têtes et l'authentification de l'expéditeur (SPF/DKIM/DMARC), inspectez les URL et pièces jointes en sandbox ou avec des outils de réputation, puis mesurez la portée — qui d'autre l'a reçu, quelqu'un a-t-il cliqué ou saisi des identifiants. Selon les constats, remédiez en purgeant l'e-mail, en bloquant les indicateurs et en réinitialisant les identifiants exposés.

La Content-Security-Policy est un en-tête de réponse HTTP qui indique au navigateur quelles sources de scripts, styles, images et autres contenus sont autorisées à se charger et s'exécuter sur une page. En interdisant le script en ligne et les origines non fiables — idéalement via des nonces ou des hachages — elle sert de rempart de défense en profondeur qui neutralise les charges utiles XSS injectées, même lorsqu'une passe au travers.

Le CSRF piège le navigateur d'un utilisateur connecté pour lui faire envoyer une requête modifiant l'état vers un site où il est authentifié, en abusant du fait que les cookies sont envoyés automatiquement. On l'empêche avec des jetons anti-CSRF (une valeur secrète par session que l'attaquant ne peut ni lire ni deviner) et l'attribut de cookie SameSite, qui empêche les cookies d'accompagner les requêtes intersites.

Le Top 10 de l'OWASP est un document de sensibilisation piloté par la communauté qui classe les risques de sécurité des applications web les plus critiques, actualisé tous les quelques années à partir de données réelles. Ce n'est ni une liste de contrôle ni une norme, mais un point de départ — les entrées récentes incluent le contrôle d'accès défaillant (n°1), les échecs cryptographiques, l'injection et la conception non sécurisée.

Ne stockez jamais les mots de passe en clair ni chiffrés de façon réversible, et jamais avec des hachages rapides à usage général comme MD5 ou SHA-256. Utilisez une fonction de hachage de mots de passe lente et exigeante en mémoire — Argon2id (préféré) ou bcrypt — avec un sel aléatoire unique par mot de passe et un facteur de coût ajusté, afin qu'un attaquant qui vole la base de données ne puisse pas casser les hachages de manière réaliste.

Les requêtes préparées envoient d'abord le modèle de requête à la base de données, avec des emplacements réservés, afin que la structure soit figée avant l'arrivée de toute donnée utilisateur. Les paramètres sont ensuite liés comme de pures données et ne peuvent jamais être interprétés comme du SQL — ainsi une entrée comme ' OR 1=1 est traitée comme une chaîne littérale, pas comme du code. Cette séparation est le correctif canonique et fiable contre l'injection.

La défense principale est l'encodage de sortie contextuel — encoder les données non fiables pour l'endroit exact où elles atterrissent (corps HTML, attribut, JavaScript, URL). Associez cela à des API DOM sûres (textContent plutôt qu'innerHTML), à l'auto-échappement des frameworks, à la validation des entrées et à une Content-Security-Policy comme rempart de défense en profondeur qui limite quels scripts peuvent s'exécuter.

La Same-Origin Policy est la règle du navigateur selon laquelle un script d'une origine (schéma + hôte + port) ne peut pas lire les réponses d'une origine différente, ce qui protège les sessions authentifiées. CORS est un assouplissement contrôlé : un serveur renvoie des en-têtes Access-Control-Allow-Origin pour autoriser explicitement des origines spécifiques à lire ses réponses, ce qui assouplit la SOP au lieu de la contourner.

HttpOnly cache le cookie à JavaScript afin que le XSS ne puisse pas le voler via document.cookie. Secure garantit que le cookie n'est envoyé que sur HTTPS, bloquant l'interception réseau. SameSite contrôle si le cookie est envoyé sur les requêtes intersites, atténuant le CSRF. Ensemble, ils renforcent les cookies de session contre les voies de vol et d'abus les plus courantes.

Les en-têtes de sécurité clés incluent Strict-Transport-Security (force HTTPS, bloque le SSL stripping), Content-Security-Policy (limite les sources de scripts, atténue le XSS), X-Frame-Options ou CSP frame-ancestors (bloque le clickjacking), X-Content-Type-Options: nosniff (stoppe le MIME sniffing) et Referrer-Policy (contrôle la fuite du référent). Chacun traite une classe d'attaque spécifique.

L'injection SQL permet à l'entrée d'un attaquant de modifier une requête. Les techniques en bande renvoient les données directement : celle basée sur UNION ajoute un UNION SELECT pour extraire des colonnes supplémentaires, et celle basée sur les erreurs fait fuiter les données via les messages d'erreur de la base. Quand aucune sortie n'est visible, les attaquants utilisent la SQLi à l'aveugle — la booléenne déduit les données des différences de réponse vrai/faux, et la temporelle utilise des délais comme SLEEP() pour lire les données bit par bit.

Le SSRF pousse un serveur à effectuer des requêtes HTTP (ou autres) vers une destination choisie par l'attaquant, en abusant de la position réseau du serveur pour atteindre des services internes derrière le pare-feu. Dans le cloud, c'est particulièrement grave car le service de métadonnées d'instance (par exemple 169.254.169.254) peut renvoyer des identifiants IAM, transformant un SSRF en compromission du compte cloud.

HTTP est sans état — chaque requête est indépendante et n'a aucune mémoire des précédentes. Les sessions ajoutent un état par-dessus : après la connexion, le serveur émet un identifiant que le navigateur stocke dans un cookie et rejoue à chaque requête. Les sessions côté serveur conservent l'état sur le serveur, indexé par un ID de session opaque ; les jetons sans état comme les JWT mettent un état signé dans le jeton lui-même afin que le serveur puisse vérifier sans stockage.

Tout XSS injecte un script contrôlé par l'attaquant dans le navigateur d'une victime. Le XSS stocké persiste la charge utile sur le serveur (par exemple un commentaire) et touche tous ceux qui la consultent ; le XSS réfléchi renvoie la charge utile depuis le serveur dans une seule réponse, généralement via un lien forgé ; le XSS basé sur le DOM n'atteint jamais la logique serveur — du JavaScript côté client vulnérable écrit une entrée non fiable dans la page.

Le XXE abuse d'un analyseur XML qui résout les entités externes définies dans la DTD d'un document. Un attaquant déclare une entité pointant vers un fichier local ou une URL interne, et l'analyseur la récupère — permettant la divulgation de fichiers, le SSRF et le déni de service. Le correctif est de désactiver le traitement des DTD et la résolution des entités externes dans la configuration de l'analyseur.