Questions d'entretien Application Security Engineer

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é.

On ne le déchiffre pas — les hashs cryptographiques sont des fonctions à sens unique sans inverse. « Cracker » un hash, c'est deviner des entrées candidates, les hacher et comparer (dictionnaire, force brute, rainbow tables), ce qui explique justement pourquoi on utilise des hashs lents et salés pour les mots de passe. Aucune clé ne « déchiffre » un hash. Si une donnée peut être déchiffrée, c'est qu'elle a été chiffrée, pas hachée — et le Base64 est un encodage réversible, pas du hachage.

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.

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. 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.

Non. Un sel est une valeur aléatoire unique stockée juste à côté du hash ; son rôle est de faire en sorte que des mots de passe identiques produisent des hashes différents et de neutraliser les rainbow tables précalculées — pas de rester secret. Il est normal qu'un attaquant qui vole la base récupère aussi les sels. Ce qui protège réellement les mots de passe, c'est un hash lent et salé (bcrypt, scrypt, Argon2). Un « poivre » secret optionnel et séparé est un concept différent.

Une autonomie sans limites associée à l'accès aux outils, c'est l'« agence excessive » d'OWASP LLM : un modèle manipulé ou en erreur peut entreprendre des actions destructrices. Encadrez-le avec des outils au moindre privilège, exigez une confirmation humaine pour les opérations irréversibles, et gardez des permissions restreintes et auditées. Lui faire confiance ou lui donner les droits admin élargit le rayon d'impact, et masquer un bouton dans l'interface ne change rien à la capacité sous-jacente du modèle à appeler l'action.

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é.

Un modèle tiers est une dépendance de chaîne d'approvisionnement : vérifiez qu'il provient d'une source de confiance avec des sommes de contrôle/signatures correspondantes, que sa licence autorise votre usage, et que le format de fichier n'exécute pas de code arbitraire au chargement (préférez une sérialisation sûre aux formats de type pickle). « Il se charge » et « la vitesse de téléchargement » ne disent rien de la confiance, et supposer que les modèles publics sont sûrs ignore les risques réels d'empoisonnement et de désérialisation.

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.

Envoyer des données personnelles de clients à une API externe les expose au traitement et à la conservation d'un tiers et peut enfreindre des obligations de confidentialité. Minimisez et anonymisez ce qui est envoyé, confirmez les conditions d'usage/conservation du fournisseur et un accord de traitement des données (ou des garanties de non-entraînement), ou passez à un déploiement privé pour les données sensibles. La longueur de la clé n'a aucune importance, et envoyer plus de données personnelles augmente l'exposition.

Si la récupération extrait n'importe quel document indexé quelle que soit la personne qui interroge, le modèle restituera fidèlement des données que l'utilisateur ne devrait pas voir — c'est une faille d'autorisation, pas une hallucination. Imposez les permissions de l'utilisateur au niveau du document au moment de la récupération, pour que seuls les fragments autorisés entrent dans le contexte. Un prompt système plus long est contournable et n'implémente aucun contrôle d'accès, la température n'a aucun rapport, et un autre modèle présente la même faille.

S'entraîner sur des données utilisateurs non vérifiées permet à un attaquant d'empoisonner le modèle — en y implantant des portes dérobées, des déclencheurs ou un comportement biaisé qui surgit plus tard. Maîtrisez-le par la vérification et le filtrage des données, le suivi de provenance, la détection d'anomalies sur le jeu de données et l'évaluation du comportement du modèle après l'entraînement. « Plus de données, c'est mieux » ignore l'intégrité, et le vrai souci est l'empoisonnement, pas la vitesse ni l'espace disque.

Le stockage de mots de passe exige un hachage délibérément lent, salé et à coût mémoire élevé — bcrypt, scrypt ou Argon2 — pour que casser des hachages volés soit coûteux et que les rainbow tables ne s'appliquent pas. Un hachage rapide comme SHA-256 se brute-force trivialement à grande échelle ; le chiffrement réversible signifie qu'une seule compromission de clé expose tous les mots de passe d'un coup ; et le texte clair est indéfendable, quelle que soit la fermeture de la base. Choisissez Argon2id (ou bcrypt) avec un facteur de coût ajusté et un sel unique par utilisateur.

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.

Les secrets doivent vivre dans un magasin géré avec contrôle d'accès, audit et rotation, injectés au runtime — jamais versionnés. Utilisez un gestionnaire de secrets (AWS Secrets Manager, HashiCorp Vault) et retirez les valeurs versionnées de l'historique, puis faites-les tourner car elles doivent être considérées comme compromises. Le base64 est de l'encodage, pas une protection — n'importe qui peut le décoder. Un dépôt privé répand quand même le secret à tous ceux qui ont l'accès en clone, plus les systèmes CI et les forks. Le compiler dans le binaire ne fait que cacher un secret toujours trivial à extraire.

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.

Un jailbreak vise l'alignement de sécurité du modèle : il pousse le modèle à produire du contenu que le fournisseur a cherché à interdire, comme des instructions nuisibles. La prompt injection vise la hiérarchie d'instructions de l'application : elle écrase le system prompt du développeur ou détourne le comportement du modèle dans une application, souvent via des données non fiables. Les jailbreaks attaquent le modèle ; la prompt injection attaque le système environnant. Ils se recoupent, mais l'objectif et la frontière de confiance franchie diffèrent.

La chaîne d'approvisionnement LLM couvre les modèles de base, les variantes fine-tunées, les jeux de données, les embeddings, les plugins, les bibliothèques et la plateforme d'hébergement — chacun un endroit où introduire du risque. Les menaces incluent le téléchargement de poids de modèle altérés ou avec backdoor, des fine-tunes malveillants, des jeux de données empoisonnés ou à la licence viciée, des plugins vulnérables ou sur-permissionnés et des dépôts de modèles typosquattés. Défenses : sourcer les modèles depuis des registres de confiance, vérifier l'intégrité et la provenance, maintenir un AI bill of materials, scanner et épingler les dépendances, vérifier les plugins et appliquer le moindre privilège à tout ce que le modèle intègre.

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.

Les applis LLM divulguent des données de plusieurs façons : le modèle mémorise et restitue des données d'entraînement ou de fine-tuning sensibles, le system prompt (qui peut contenir des secrets ou de la logique) est extrait, des documents RAG récupérés exposent des données que l'utilisateur ne devrait pas voir, et le contexte d'un utilisateur ou d'une session déborde sur un autre. La prévention passe par la minimisation des données avant l'entraînement, ne jamais mettre de secrets dans les prompts, appliquer l'autorisation par utilisateur à la récupération, le filtrage des sorties et la rédaction de PII, et l'isolement par locataire.

L'empoisonnement des données d'entraînement, c'est quand un attaquant altère les données utilisées pour pré-entraîner, fine-tuner ou créer les embeddings d'un modèle afin que le modèle résultant se comporte de façon malveillante — en intégrant un déclencheur de backdoor, en injectant du biais ou en dégradant la précision. Il exploite le fait que les modèles aspirent et font confiance à de vastes jeux de données souvent issus du web. Les défenses incluent la curation et la signature des sources de données, les vérifications de provenance et d'intégrité, la détection d'anomalies sur les données d'entraînement, le versionnage des jeux de données, et la limitation de qui peut contribuer aux corpus d'entraînement et RAG.

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.

Partez d'une image de base minimale et de confiance (distroless ou slim) pour réduire la surface d'attaque, analysez les images à la recherche de CVE connues dans la CI et dans le registre, épinglez et vérifiez les empreintes (digests) des images, exécutez avec un utilisateur non-root et évitez d'intégrer des secrets. Signez les images et imposez des politiques d'admission pour que seules les images analysées et signées s'exécutent. Reconstruisez régulièrement pour que les couches de base corrigées se propagent.

Le RBAC contrôle ce que les identités peuvent faire sur l'API Kubernetes — les Roles et ClusterRoles accordent des verbes sur des ressources, liés à des sujets via des RoleBindings — et doit suivre le moindre privilège, en évitant cluster-admin et les wildcards. Les politiques réseau contrôlent le trafic pod-à-pod, qui est autorisé par défaut jusqu'à ce que vous appliquiez un default-deny puis permettiez explicitement les flux requis. Ensemble, ils limitent le rayon d'impact si un pod ou un jeton est compromis.

Stockez les secrets dans un service géré dédié (Secrets Manager, Parameter Store, Vault), chiffrés avec une clé KMS, et accordez l'accès via des rôles IAM pour que les charges de travail les récupèrent à l'exécution avec des identifiants à courte durée de vie. N'intégrez jamais de secrets dans le code, les images de conteneurs ou des fichiers .env versionnés. Ajoutez une rotation automatique, des politiques de clé restreintes et une journalisation d'audit pour que chaque récupération soit traçable.

La CI/CD est de grande valeur car elle détient les identifiants de déploiement et exécute du code non fiable. Les risques incluent les dépendances et actions de build compromises, les secrets divulgués ou trop larges, les actions tierces mutables, et les runners ou la confiance OIDC surprivilégiés. Réduisez-les avec des dépendances épinglées et vérifiées, une fédération OIDC à courte durée de vie au lieu de clés à longue durée de vie, le moindre privilège restreint à des dépôts/branches précis, des runners éphémères isolés, et des artefacts signés à provenance tracée (SLSA).

Une signature numérique est le hachage d'un message transformé avec la clé privée du signataire. Le vérificateur recalcule le hachage, applique la clé publique du signataire, et vérifie qu'ils correspondent. Comme seul le signataire détient la clé privée, une signature valide prouve que le message vient de lui (authenticité), n'a pas été altéré (intégrité), et qu'il ne peut le nier de façon crédible (non-répudiation).

Un HMAC est un code d'authentification de message à clé : il hache le message avec une clé secrète via une construction imbriquée (hachage interne et externe avec des bourrages dérivés de la clé). Il prouve à la fois l'intégrité (le message n'a pas été altéré) et l'authenticité (il vient de quelqu'un détenant la clé). Un simple hachage ne prouve ni l'un ni l'autre, puisque n'importe qui peut le recalculer ; HMAC résiste aussi aux attaques par extension de longueur.

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.

Stockez les mots de passe avec une fonction de hachage de mots de passe délibérément lente, salée et adaptative — bcrypt, scrypt ou Argon2 — jamais un hachage générique rapide comme SHA-256 ou MD5. Les hachages rapides sont conçus pour la vitesse, donc des attaquants avec des GPU peuvent tester des milliards d'essais par seconde contre une base de données fuitée. Les hachages lents ont un facteur de travail ajustable (et un coût mémoire) qui rend chaque essai coûteux, gardant le brute force impraticable même après une fuite.

Un sel est une valeur aléatoire unique générée par utilisateur et combinée au mot de passe avant le hachage. Il garantit que des mots de passe identiques produisent des hachages différents et rend inutiles les attaques précalculées comme les tables arc-en-ciel, puisque l'attaquant aurait besoin d'une table distincte par sel. Les sels sont stockés à côté du hachage. Un poivre est une valeur secrète supplémentaire, la même pour tous les utilisateurs, conservée séparément (par exemple, dans la config de l'application ou un HSM) de sorte qu'une fuite de base de données seule ne suffise pas.

TOTP (mot de passe à usage unique basé sur le temps) combine un secret partagé, établi à l'enrôlement, avec l'heure courante divisée en fenêtres fixes (généralement 30 secondes). Il exécute HMAC sur le compteur de pas de temps avec le secret, puis tronque le résultat en un code à 6 chiffres. L'application et le serveur détiennent tous deux le même secret et la même horloge, donc ils calculent indépendamment le même code — aucun appel réseau nécessaire. Le code change à chaque fenêtre.

La signature lie cryptographiquement un artefact à son producteur, afin que les consommateurs puissent vérifier qu'il n'a pas été altéré ou substitué. La provenance est une métadonnée signée décrivant comment, où et à partir de quelle source l'artefact a été construit. Ensemble — via des outils comme Sigstore pour la signature sans clé et le framework SLSA pour les niveaux de provenance — ils permettent à un déployeur de vérifier qu'une image provient du pipeline et de la source attendus, déjouant l'altération et les attaques par substitution de dépendances.

Analysez les images pour les CVE connues dans les paquets OS et les bibliothèques applicatives, ainsi que les mauvaises configurations et les secrets intégrés, à la fois au moment du build et en continu dans le registre — car de nouvelles CVE apparaissent après la construction d'une image. Utilisez des images de base minimales ou distroless pour réduire la surface d'attaque, épinglez et référencez les images de base par empreinte, et exécutez le conteneur en non-root. L'analyse est nécessaire mais ne remplace pas la protection à l'exécution.

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é.

L'analyse IaC analyse statiquement les définitions Terraform, CloudFormation, Kubernetes et similaires par rapport à une politique pour détecter les mauvaises configurations — buckets S3 publics, groupes de sécurité ouverts, chiffrement manquant — avant même leur provisionnement. Parce que le même modèle provisionne de nombreuses ressources, le corriger une fois évite la dérive répétée, et le détecter avant l'application est bien moins coûteux que de remédier à des ressources cloud actives. Les outils incluent Checkov, tfsec et KICS, idéalement appliqués comme barrières policy-as-code.

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à.

Compresser d'abord, puis chiffrer. Un bon chiffrement produit une sortie statistiquement indiscernable de l'aléatoire, donc le texte chiffré n'a plus aucun motif à compresser : compresser après est inutile. La mise en garde importante : compresser ensemble des données secrètes et des données contrôlées par l'attaquant avant le chiffrement peut fuiter de l'information via la longueur du texte chiffré, ce qui est exactement le cas des attaques CRIME et BREACH.

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.

L'encodage transforme les données dans un autre format pour la compatibilité et est entièrement réversible par quiconque sans clé (par ex. Base64, encodage d'URL) : il n'offre aucune confidentialité. Le chiffrement n'est réversible qu'avec une clé et c'est lui qui assure la confidentialité. Le hachage est une fonction à sens unique : on ne peut pas retrouver l'entrée à partir de la sortie, ce qui le rend adapté aux contrôles d'intégrité et au stockage des mots de passe (avec un sel et une KDF lente).

Parce qu'ils sont rapides. MD5 et SHA-256 sont conçus pour la vitesse, ce qui est exactement l'inverse de ce qu'il faut pour les mots de passe : un attaquant qui vole les hachages peut calculer des milliards de tentatives par seconde sur un GPU. La solution est une fonction de dérivation de clé délibérément lente et coûteuse en mémoire — bcrypt, scrypt ou Argon2 — combinée à un sel par utilisateur et à un facteur de travail ajustable.

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é.

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.

Le chiffrement est réversible : avec la clé, on récupère le texte en clair ; il protège la confidentialité. Le hachage est une fonction à sens unique produisant une empreinte de taille fixe impossible à inverser ; il vérifie l'intégrité et l'identité. Les mots de passe doivent être hachés avec un algorithme lent et salé comme bcrypt ou Argon2, jamais chiffrés.

Ne jamais coder en dur les secrets dans le code source ni les committer dans git. Les stocker dans un gestionnaire de secrets ou un coffre-fort dédié, les injecter à l'exécution, restreindre l'accès au moindre privilège, les faire tourner régulièrement, et préférer des identifiants dynamiques à courte durée de vie aux identifiants statiques persistants. Auditer chaque accès.

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.

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.