Questions d'entretien Security Engineer

En pratique, non. AES-128 exige déjà environ 2^128 d'effort pour être cassé par force brute — totalement infaisable — donc AES-256 ne vous rend pas réellement plus sûr face à la force brute ; il ajoute surtout de la marge (réserve post-quantique, conformité). Les deux sont standardisés et non cassés. Votre mode (GCM), la gestion des nonces et celle des clés comptent bien plus que 128 contre 256. « AES-256 est deux fois plus sûr » est l'idée fausse.

Non. On ne peut pas comparer la longueur brute des clés entre familles d'algorithmes différentes. En raison de la manière dont les mathématiques sous-jacentes de chacun durcissent, une clé sur courbe elliptique de 256 bits offre à peu près la même sécurité qu'une clé RSA de 3072 bits — environ 128 bits de force, selon le NIST. Plus gros n'est pas simplement plus solide : l'ECC atteint une force équivalente avec des clés bien plus petites, d'où sa préférence dans les systèmes modernes. Au sein d'un même algorithme, des clés plus longues aident, jusqu'à un certain point.

Non. Les trois catégories de facteurs d'authentification sont quelque chose que vous savez (mot de passe/PIN), quelque chose que vous avez (jeton/téléphone) et quelque chose que vous êtes (biométrie). Une empreinte digitale ou un scan facial relève de « quelque chose que vous êtes », un trait physique mesuré. Le piège : la biométrie n'est pas un secret et ne peut pas être renouvelée — si le gabarit de votre empreinte fuite, vous ne pouvez pas changer votre empreinte. C'est pourquoi la biométrie fonctionne mieux comme un facteur, déverrouillant souvent une clé locale, que comme remplacement autonome du mot de passe.

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.

Pas nécessairement. Double-chiffrer avec le même algorithme ne double pas simplement la sécurité — le résultat classique est que le 2DES n'ajoute qu'environ un bit de force effective à cause des attaques par rencontre au milieu (meet-in-the-middle), d'où l'existence du 3DES. Plus important, les schémas multicouches faits maison tendent à introduire des bugs d'implémentation qui affaiblissent l'ensemble. Utilisez plutôt un seul chiffrement authentifié éprouvé (AES-GCM) avec une gestion de clés saine.

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. Toute la plage 127.0.0.0/8 est réservée au bouclage, donc 127.0.0.2, 127.1.1.1, et ainsi de suite résolvent toutes vers l'hôte local. C'est crucial pour le SSRF et le contournement de listes d'autorisation — un attaquant peut utiliser 127.0.0.2 ou d'autres encodages pour esquiver un contrôle naïf « bloquer 127.0.0.1 » — et pour lier plusieurs services locaux. (En IPv6, le bouclage est l'unique adresse ::1.)

Non. La MFA élève fortement la barre, mais les facteurs OTP et push sont hameçonnables : les kits d'adversaire au milieu (ex. Evilginx) relaient la connexion et le code en temps réel, et la fatigue MFA / le push-bombing poussent l'utilisateur à approuver. Les codes capturés sont réutilisables dans leur courte fenêtre. L'erreur est « MFA = inhameçonnable » ; c'est le type de facteur qui compte. La MFA résistante au phishing — les passkeys FIDO2/WebAuthn liés à l'origine du site — est ce qui déjoue réellement cela.

Non. Le NAT (et le PAT) associe des adresses privées à une IP publique et, par effet de bord, rejette les connexions entrantes non sollicitées car aucune correspondance n'existe pour elles. Ce n'est pas une politique de sécurité — pas d'inspection, pas de règles, pas de journalisation — et la traversée de NAT, le hole punching et le C2 initié en sortie passent sans problème. Le NAT est un outil d'adressage ; il vous faut un vrai pare-feu. « NAT = pare-feu » est l'idée fausse.

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.

Non. Un VPN chiffre le trafic jusqu'au serveur VPN et masque votre IP à la destination, mais le fournisseur peut voir et journaliser votre activité, et les connexions, cookies et l'empreinte du navigateur vous identifient toujours. Cela déplace la confiance de votre réseau local/FAI vers l'opérateur du VPN — c'est de la confidentialité vis-à-vis du réseau local, pas de l'anonymat. Tor et une discipline opérationnelle stricte sont d'autres outils pour un autre objectif.

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.

SSLv3, TLS 1.0 et RC4 sont cassés ou obsolètes et permettent des attaques par rétrogradation et déchiffrement ; désactivez-les donc et exigez TLS 1.2 ou 1.3 avec des suites de chiffrement robustes et à confidentialité persistante, en acceptant la rare perte de très vieux clients. Les laisser actifs par compatibilité maintient la faiblesse exploitable. Ajouter un second certificat ou passer à un certificat auto-signé ne supprime pas les protocoles faibles, et l'auto-signé nuit à la confiance sans corriger la cryptographie.

Le risque au départ, c'est l'accès résiduel ; le contrôle à vérifier est donc le déprovisionnement rapide de chaque voie d'accès — comptes d'annuaire, SSO, VPN, identifiants privilégiés et de service, et SaaS tiers — rapproché du processus arrivée/mobilité/départ (JML). Supposer que les RH gèrent tout sans vérification laisse des failles que personne ne possède. Garder le compte actif « au cas où il reviendrait » est un risque permanent et non surveillé. Désactiver seulement l'e-mail ignore les nombreux autres systèmes que la personne pourrait encore atteindre. L'enjeu est de vérifier que l'accès est réellement et totalement retiré, pas de présumer qu'il l'a été.

Les comptes de service inutilisés et sur-privilégiés sont des cibles de choix et une large surface d'attaque. Inventoriez-les, désactivez ou supprimez les inutilisés (en surveillant les casses), réduisez les survivants au moindre privilège et donnez à chacun un propriétaire et une revue récurrente. Les laisser est un risque permanent, leur accorder un accès admin global maximise le rayon d'impact, et tout consolider sur un compte partagé unique détruit le moindre privilège et la responsabilité.

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.

Un binaire SUID-root s'exécute avec les privilèges de root, et s'il est accessible en écriture par tous, un attaquant peut le remplacer ou le modifier pour exécuter du code arbitraire en tant que root — une voie classique d'élévation de privilèges locale. Retirez le bit SUID, corrigez le propriétaire et les permissions, et enquêtez sur l'origine de cette mauvaise configuration, car elle peut indiquer une compromission. Chiffrer le fichier laisse intact le chemin exécutable, et le renommer ne fait que déplacer le problème sans supprimer l'élévation. Aucune de ces options ne traite la cause racine.

Comme les pare-feu évaluent les règles de haut en bas, une large règle any/any près du haut court-circuite toutes les règles en dessous et autorise tout le trafic — le pare-feu cesse en pratique d'imposer quoi que ce soit. Remplacez-la par des règles explicites de moindre privilège pour les flux réellement nécessaires, ordonnées pour que les autorisations et refus spécifiques prennent effet, et terminez par un refus par défaut. La qualifier d'efficace est faux, la déplacer en bas peut encore masquer le refus par défaut, et la renommer ne change rien à ce qu'elle autorise.

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.

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 chiffrement au repos ne défend qu'une seule menace — le vol physique ou de disque — et n'apporte rien contre une application compromise, des identifiants volés ou un trafic intercepté, car la base déchiffre de façon transparente pour toute requête autorisée. Une conception saine exige aussi du TLS en transit, une authentification et une autorisation fortes, et une gestion des clés avec séparation des tâches. Doubler le chiffrement au repos ajoute du coût sans changer le modèle de menace, et ne chiffrer que les sauvegardes laisse les données en production et leurs chemins d'accès exposés.

Si la clé réside avec le texte chiffré, quiconque vole la base obtient les deux ; le chiffrement ne protège donc rien — c'est une serrure avec la clé scotchée dessus. Les clés doivent être gérées dans un KMS ou HSM dédié, séparées des données, avec contrôle d'accès strict, rotation et séparation des tâches. Hacher la clé la rend à sens unique et inutile pour le déchiffrement, et stocker des copies supplémentaires au même endroit ne fait que multiplier l'exposition au lieu de la réduire.

Le changement manuel dans la console est une dérive de configuration : le prochain terraform apply peut annuler silencieusement le correctif, et le changement a aussi contourné la revue et l'audit. Réconciliez-le en codifiant le changement dans Terraform, en lançant plan/apply pour que le code et la réalité concordent, et en ajoutant des garde-fous contre les modifications ad hoc dans la console (accès console au moindre privilège, SCP, détection de dérive). Ne rien faire laisse une mine pour le prochain apply. Supprimer l'état Terraform est destructeur et peut orpheliner ou dupliquer des ressources. Abandonner Terraform sacrifie reproductibilité, revue et pistes d'audit.

Une RCE non authentifiée sur un serveur exposé sur Internet relève de l'urgence : réduisez la fenêtre d'exposition par un déploiement testé, en staging ou progressif, et ajoutez des contrôles compensatoires (restreindre l'accès, règles WAF) en attendant. Attendre la fenêtre trimestrielle laisse un trou exploitable comme un ver ouvert des semaines. Patcher à l'aveugle en production en heures ouvrées sans test risque une panne et un rollback raté. Se fier au pare-feu périmétrique ne sert à rien — le service est déjà exposé et l'exploit n'a besoin d'aucun identifiant.

Les dirigeants sont précisément les comptes que veulent les attaquants (BEC, fraude au virement), donc les exempter inverse le modèle de risque. Résolvez la friction, pas le contrôle : déployez des passkeys/FIDO2 résistants au phishing, plus rapides que les codes. Céder à la dérogation détruit la crédibilité du programme et laisse vos comptes de plus grande valeur sans protection. Abandonner le projet MFA, c'est renoncer à un contrôle de premier ordre. L'activer en douce dans leur dos détruit la confiance et la responsabilité.

Les réseaux plats permettent à un seul appareil invité compromis d'atteindre directement les systèmes les plus précieux. Segmentez par niveau de confiance et appliquez un trafic à moindre privilège entre les zones pour contenir et surveiller les déplacements latéraux. Un pare-feu de bordure ne fait rien pour le trafic est-ouest entre des hôtes déjà à l'intérieur. Re-adresser les serveurs financiers est de la sécurité par l'obscurité qu'un simple scan déjoue. L'antivirus est une couche de détection, pas un substitut au contrôle architectural d'isolement des systèmes sensibles.

Moindre privilège plus accès juste-à-temps : accordez le minimum de permissions nécessaires, limité dans le temps et journalisé, pour que le débogage soit possible sans admin permanent devenant un risque durable et un angle mort d'audit. Un cluster-admin permanent viole le moindre privilège et élargit le rayon d'impact de toute compromission. Un refus total bloque le travail légitime et invite à des contournements parallèles risqués. Partager l'identifiant commun du compte de service admin détruit la responsabilité — les actions ne sont plus rattachables à une personne.

Considérez tout secret poussé comme grillé : révoquez-le et faites-le tourner d'abord, car les bots scrutent les commits publics en quelques secondes, puis examinez CloudTrail pour détecter un abus et purgez-le de l'historique. Supprimer le commit ne sert à rien — la clé est déjà clonée, forkée et mise en cache par des tiers. Rendre le dépôt privé laisse une clé déjà divulguée et active aux mains des attaquants. Ajouter le fichier au .gitignore ne change rien à un secret déjà commité.

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.

Les renouvellements manuels échouent, alors éliminez le problème par l'ingénierie avec un renouvellement ACME automatisé et une surveillance d'expiration qui alerte plusieurs jours à l'avance. Un rappel d'agenda, c'est le processus manuel qui a déjà échoué. Un certificat auto-signé à longue durée brise la confiance publique et viole les limites de durée modernes (les AC plafonnent la validité à ~398 jours, et cela baisse encore). Désactiver TLS échange une coupure de disponibilité contre une perte catastrophique de confidentialité et d'intégrité.

Réduisez les faux positifs par l'ingénierie de détection, pas en vous aveuglant. Réajustez pour que les alertes ne se déclenchent que sur les motifs qui comptent — un même mot de passe testé sur de nombreux comptes (spraying), un compte attaqué de nombreuses fois (stuffing/force brute), voyage impossible — tout en gardant les événements bruts consultables sur un tableau de bord. Mesurez ensuite la précision des alertes dans le temps. Désactiver la règle supprime un signal réel, une suppression globale crée un angle mort permanent, et embaucher des gens pour trier du bruit pur ne passe pas à l'échelle et les épuise.

L'IA aide le SOC en triant et dédupliquant les alertes, en résumant les incidents, en enrichissant le contexte, en rédigeant des détections et en accélérant l'intégration des analystes — réduisant la fatigue et le temps de présence. Les risques : conclusions hallucinées ou fausses avec assurance, biais d'automatisation où les analystes cessent de vérifier, prompt injection via des données de logs ou d'alertes contrôlées par l'attaquant, fuite de données sensibles vers des modèles tiers, et adversaires utilisant les mêmes outils. Gardez un humain dans la boucle, vérifiez les sorties et isolez les entrées non fiables.

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.

Le NIST AI Risk Management Framework (AI RMF 1.0) est un cadre volontaire et fondé sur le risque pour gouverner une IA digne de confiance tout au long de son cycle de vie. Son cœur est constitué de quatre fonctions : Govern (culture, politique, responsabilité — et elle traverse les autres), Map (contexte et identification des risques), Measure (évaluer et suivre les risques) et Manage (prioriser et répondre). Il définit aussi des caractéristiques de fiabilité — valide et fiable, sûr, sécurisé et résilient, responsable et transparent, explicable, respectueux de la vie privée et équitable. Il complète des listes techniques comme l'OWASP LLM Top 10 au niveau du programme.

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.

Le credential stuffing rejoue des paires identifiant:mot de passe connues issues de fuites tierces, en pariant sur la réutilisation des mots de passe — taux de réussite élevé par tentative, souvent réparti sur de nombreuses IP et machines pour paraître humain. Le password spraying essaie un ou deux mots de passe courants (comme Winter2026!) sur de nombreux comptes afin de rester sous les seuils de verrouillage. Le stuffing exploite la réutilisation ; le spraying exploite les mots de passe partagés faibles. La MFA déjoue les deux.

La Cyber Kill Chain modélise une intrusion en sept étapes séquentielles : reconnaissance, militarisation, livraison, exploitation, installation, commande et contrôle (C2), et actions sur les objectifs. Les défenseurs associent des détections et des contrôles à chaque étape ; comme les étapes sont séquentielles, briser un seul maillon — bloquer l'e-mail de phishing, tuer le C2 — perturbe toute l'attaque. Cela pousse à détecter tôt plutôt qu'à la seule intrusion finale.

L'exfiltration DNS encode des données volées dans des requêtes DNS (par ex. de longs labels de sous-domaine envoyés à un serveur autoritaire contrôlé par l'attaquant), en abusant du fait que le DNS est presque toujours autorisé en sortie et souvent non surveillé. Détectez-la par des anomalies : volume de requêtes anormalement élevé vers un domaine, sous-domaines longs / à forte entropie, nombreux sous-domaines uniques par domaine parent, abus d'enregistrements TXT/NULL, et requêtes vers des domaines récemment enregistrés ou rares.

L'antivirus traditionnel compare les fichiers à des signatures de malwares connus et les bloque ou les met en quarantaine — efficace contre les menaces connues, faible contre les attaques nouvelles ou sans fichier. L'EDR enregistre en continu le comportement du poste (processus, réseau, registre, mémoire), utilise l'analyse comportementale pour détecter l'activité suspecte, et permet aux intervenants d'investiguer, de traquer et de contenir ou restaurer à distance. L'AV est de la prévention par signature ; l'EDR ajoute visibilité, détection et réponse.

Sous Windows, les hashes des comptes locaux (NTLM) résident dans la ruche SAM sous C:\Windows\System32\config\SAM, protégée tant que l'OS tourne ; les identifiants vivants se trouvent dans la mémoire de LSASS, et les hashes de domaine sont dans NTDS.dit sur un contrôleur de domaine. Sous Linux, les hashes sont dans /etc/shadow (lisible uniquement par root), tandis que /etc/passwd contient les métadonnées de compte. Les attaquants les volent pour casser les mots de passe hors ligne ou faire du pass-the-hash.

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.

Un honeypot est un système ou service leurre sans usage métier légitime, délibérément exposé pour attirer les attaquants. Comme rien de bénin ne devrait jamais le toucher, toute interaction est une alerte hautement fiable. Les honeypots à faible interaction émulent des services à peu de frais ; ceux à forte interaction sont de vrais systèmes qui livrent une intel plus riche mais comportent plus de risque. Les honeytokens sont la même idée appliquée à de faux identifiants, fichiers ou enregistrements. Valeur : détection précoce, peu de faux positifs et threat intelligence.

DAC permet au propriétaire des données d'accorder l'accès à sa discrétion ; MAC applique l'accès de façon centralisée via des étiquettes/habilitations et est non discrétionnaire ; RBAC accorde l'accès via des rôles métier ; ABAC évalue des attributs (utilisateur, ressource, environnement) au regard d'une politique pour des décisions fines et contextuelles.

La défense en profondeur superpose des contrôles multiples, variés et indépendants à travers les personnes, les processus et la technologie, afin que la défaillance d'un seul contrôle n'entraîne pas de compromission. Elle suppose que chaque contrôle finira par échouer et utilise la redondance et la variété pour ralentir, détecter et contenir un attaquant.

La gestion du cycle de vie des identités encadre un compte de sa création à sa fin : attribution à l'arrivée (joiner), ajustement des droits lors d'un changement de rôle (mover), et suppression rapide au départ (leaver), avec des revues d'accès périodiques tout au long. Les défaillances les plus courantes sont l'accumulation de privilèges chez les movers et les comptes orphelins issus de suppressions manquées.

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 chiffrement en transit (TLS) protège les données circulant sur le réseau contre l'écoute et l'altération ; imposez TLS partout et rejetez le texte clair. Le chiffrement au repos protège les données stockées sur les disques et les sauvegardes, généralement via des clés gérées par KMS utilisant le chiffrement par enveloppe. Les deux sont des contrôles de base, mais aucun n'arrête une requête autorisée mais malveillante — le service déchiffre de manière transparente pour les appelants valides — donc le contrôle d'accès reste primordial.

Un utilisateur est une identité à longue durée de vie avec des identifiants permanents ; un rôle est une identité sans identifiants permanents que tout principal de confiance peut assumer pour obtenir des jetons à courte durée de vie ; une politique est le document JSON qui accorde des permissions, attaché à l'un ou l'autre. Le moindre privilège consiste à préférer les rôles aux utilisateurs, à restreindre les politiques à des actions et ressources précises, et à n'accorder que ce dont une tâche a besoin — puis à réviser et élaguer au fil du temps.

IMDS est un point d'accès link-local (169.254.169.254) qui fournit à une instance ses métadonnées, dont les identifiants temporaires de son rôle IAM attaché. La SSRF peut tromper le serveur pour qu'il récupère cette URL et fasse fuiter ces identifiants. IMDSv2 exige un PUT pour obtenir un jeton de session à courte durée de vie, définit une limite de saut (hop limit) / TTL IP par défaut de 1, et rejette les requêtes avec certains en-têtes — si bien qu'un simple GET de SSRF ne peut plus l'atteindre.

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.

Les erreurs classiques sont des ACL publiques ou des politiques de bucket autorisant un accès anonyme ou à tous les utilisateurs AWS, des principaux trop larges ou des actions avec wildcard, l'absence de chiffrement par défaut et l'absence de journalisation. On les évite en activant le Block Public Access au niveau du compte, en utilisant des politiques IAM/bucket selon le moindre privilège, en imposant le chiffrement par défaut et TLS, et en activant la journalisation des accès et des règles Config pour détecter les dérives.

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.

Les security groups sont des pare-feux à état attachés aux instances/ENI : ils n'ont que des règles d'autorisation, et le trafic de retour d'un flux autorisé est automatiquement permis. Les network ACL sont des filtres sans état à la frontière du sous-réseau : ils ont des règles ordonnées d'autorisation et de refus, et vous devez autoriser explicitement le trafic de retour sur les ports éphémères. Les security groups sont le contrôle principal ; les NACL ajoutent des garde-fous grossiers au niveau du sous-réseau, comme bloquer une plage d'IP.

Le fournisseur sécurise le cloud lui-même — centres de données physiques, matériel, hyperviseur et services gérés qu'il exploite. Vous sécurisez ce que vous mettez dans le cloud — vos données, identités, configurations, l'application des correctifs OS le cas échéant, et les contrôles d'accès. La frontière exacte se déplace : avec l'IaaS vous possédez l'OS et au-dessus, avec le SaaS vous possédez surtout les données et l'accès.

RSA est un algorithme asymétrique utilisé pour chiffrer des données ou créer des signatures numériques à l'aide d'une paire de clés. Diffie-Hellman est un protocole d'accord de clé qui permet à deux parties de dériver un secret partagé sur un canal public sans jamais le transmettre. Ils résolvent des problèmes différents : RSA prouve l'identité et peut encapsuler des clés ; DH négocie une clé de session — et sa variante éphémère assure la confidentialité persistante.

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.

Kerberos repose sur un centre de distribution de clés (KDC) de confiance. Le client s'authentifie une fois auprès du serveur d'authentification et obtient un ticket d'octroi de tickets (TGT) chiffré avec la clé du KDC. Pour atteindre un service, il présente le TGT au service d'octroi de tickets et reçoit un ticket de service chiffré avec la clé de ce service. Le service le déchiffre et lui fait confiance. Les mots de passe ne traversent jamais le réseau, et les tickets ont une durée limitée.

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.

La confidentialité persistante parfaite (PFS) signifie que chaque session dérive une clé unique d'un échange de clés éphémère jeté ensuite. Si un attaquant vole plus tard la clé privée à long terme du serveur, il ne peut toujours pas déchiffrer le trafic capturé précédemment, car cette clé n'a jamais servi à dériver les clés de session. Cela s'obtient avec un Diffie-Hellman éphémère (DHE/ECDHE).

Le client construit une chaîne du certificat serveur (feuille) en remontant par une ou plusieurs autorités de certification intermédiaires jusqu'à une autorité racine de son magasin de confiance. Il vérifie la signature de chaque certificat avec la clé publique de l'émetteur suivant, contrôle les dates de validité, la correspondance du nom/nom d'hôte, l'usage de la clé et la révocation (CRL/OCSP). La confiance se termine à une racine auto-signée pré-approuvée ; la chaîne n'est valide que si chaque maillon est correct.

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.

Le SSO centralise l'authentification chez un fournisseur d'identité (IdP). Quand un utilisateur visite un fournisseur de service (l'application), l'application redirige vers l'IdP ; l'utilisateur se connecte une fois, et l'IdP renvoie une assertion ou un jeton signé attestant son identité. SAML porte cela comme une assertion XML signée ; OIDC le porte comme un jeton d'identité JSON signé posé sur OAuth 2.0. L'application fait confiance à la signature de l'IdP plutôt que de gérer elle-même les mots de passe.

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.

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.

Traitez le pipeline comme une infrastructure de production : il détient les identifiants pour livrer le code et atteindre la prod, donc le compromettre contourne tous les contrôles en aval. Durcissez-le avec des runners isolés et éphémères ; des tokens à privilège minimal et courte durée (fédération OIDC au lieu de secrets à longue durée) ; des branches protégées et une config de pipeline revue ; des actions tierces épinglées par empreinte ; et une journalisation d'audit complète. Le pipeline est une cible de premier ordre, pas de la tuyauterie.

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.

Le client et le serveur se mettent d'accord sur un secret partagé en un seul aller-retour grâce au Diffie-Hellman éphémère (ECDHE). Le ClientHello transporte les groupes pris en charge et un key share ; le serveur répond avec son key share et son certificat, les deux parties dérivent les mêmes clés, et les données applicatives circulent immédiatement, avec la confidentialité persistante par défaut.

La triade CIA désigne les trois objectifs fondamentaux de la sécurité de l'information : la confidentialité (seules les parties autorisées peuvent lire les données), l'intégrité (les données ne sont pas modifiées sans autorisation) et la disponibilité (les utilisateurs autorisés accèdent aux systèmes quand ils en ont besoin). Presque chaque contrôle se rattache à un ou plusieurs de ces objectifs.

La défense en profondeur consiste à superposer plusieurs contrôles de sécurité indépendants afin que, si l'un échoue, les autres protègent encore l'actif. Elle suppose qu'aucun contrôle n'est parfait — par exemple en combinant pare-feu, segmentation réseau, protection des terminaux, MFA, moindre privilège et chiffrement, plutôt que de se fier au seul périmètre.

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.

Un IDS (système de détection d'intrusion) surveille le trafic et lève des alertes mais ne bloque pas — il est généralement hors bande. Un IPS (système de prévention d'intrusion) se place en ligne dans le chemin du trafic et peut activement rejeter ou bloquer le trafic malveillant. L'IPS prévient, mais un faux positif peut casser du trafic légitime.

Le moindre privilège signifie que chaque utilisateur, processus et service ne reçoit que l'accès minimal requis pour sa tâche, et rien de plus. Cela limite le rayon d'impact d'un compte compromis, réduit le risque de menace interne et diminue la surface d'attaque. On l'applique via l'accès basé sur les rôles, des revues d'accès régulières et l'élévation juste-à-temps.

La MFA exige au moins deux facteurs d'authentification de catégories différentes — quelque chose que vous savez (mot de passe), quelque chose que vous possédez (téléphone/jeton), quelque chose que vous êtes (biométrie). Elle aide car un attaquant qui vole un facteur, comme un mot de passe, ne peut toujours pas se connecter sans les autres. La MFA résistante à l'hameçonnage comme FIDO2 est la plus forte.

Le chiffrement symétrique utilise une seule clé secrète partagée pour chiffrer et déchiffrer et il est rapide, mais les deux parties doivent déjà partager la clé. L'asymétrique utilise une paire de clés publique/privée, résolvant le problème de distribution des clés mais plus lentement. De vrais protocoles comme TLS utilisent la crypto asymétrique pour échanger une clé symétrique, puis basculent vers le symétrique pour les données en masse.

TCP est orienté connexion et fiable : il utilise une poignée de main en trois temps, garantit une livraison ordonnée et retransmet les paquets perdus. UDP est sans connexion et rapide, sans garantie de livraison, d'ordre ni de congestion. On utilise TCP pour l'exactitude (web, e-mail, transfert de fichiers) et UDP pour le trafic sensible à la vitesse (DNS, VoIP, streaming, jeux).

Une vulnérabilité est une faiblesse (logiciel non corrigé). Une menace est un acteur ou un événement qui pourrait l'exploiter (un groupe de rançongiciel). Le risque est la combinaison de la probabilité qu'une menace exploite une vulnérabilité et de l'impact si elle le fait. Risque = menace x vulnérabilité x impact, et c'est ce que l'on priorise réellement.

Un pare-feu contrôle le trafic entre zones réseau en l'autorisant ou en le refusant selon des règles. Un pare-feu sans état évalue chaque paquet isolément par rapport aux règles ; un pare-feu à état suit l'état des connexions pour autoriser le trafic de retour des sessions qu'il a permises. Les pare-feu nouvelle génération ajoutent la connaissance de la couche applicative.

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.

Filtré. Un port filtré rejette silencieusement le paquet, donc le scanner n'obtient aucune réponse et doit attendre un délai d'expiration : il n'apprend rien sur l'existence même de l'hôte, et le scan est considérablement ralenti. Un port fermé renvoie un RST TCP, qui confirme que l'hôte est vivant et répond, offrant gratuitement à l'attaquant une valeur de reconnaissance.

Pas à lui seul. HTTPS empêche le MITM uniquement quand la validation du certificat est strictement appliquée et que le client atteint le site en HTTPS dès le départ. Si une AC malveillante est de confiance (proxy d'entreprise, racine installée par un logiciel malveillant), si l'utilisateur passe outre les avertissements de certificat, ou si du SSL stripping rétrograde la connexion vers HTTP avant le démarrage de TLS, un attaquant peut toujours se placer au milieu.

HTTPS n'est pas un protocole à part entière : c'est du HTTP ordinaire circulant dans un tunnel TLS chiffré. SSL est l'ancien nom : SSL 2.0/3.0 sont les prédécesseurs obsolètes et non sécurisés de TLS, qui les a remplacés (TLS 1.0 à 1.3). Quand les gens disent « certificat SSL » ou « SSL », ils désignent presque toujours en réalité TLS.

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.

Un référentiel est un modèle du comportement normal d'un hôte, d'un utilisateur, d'un compte ou d'un segment réseau — quels processus s'exécutent, qui se connecte d'où et quand, les volumes de données typiques, les intervalles normaux de beaconing. Une fois la normalité connue, les anomalies (paires processus parent-enfant rares, binaires vus pour la première fois, connexions à des heures inhabituelles, exfiltration de données inhabituelle) deviennent détectables comme des écarts. L'établissement d'un référentiel est le fondement de la détection d'anomalies, mais il exige un historique propre suffisant et une gestion soigneuse des changements légitimes pour ne pas se noyer sous les faux positifs.

Le beaconing C2 est le check-in périodique qu'un implant effectue auprès de son contrôleur. Chassez-le dans la télémétrie réseau/proxy/DNS en cherchant la régularité : connexions vers une destination à intervalles quasi fixes (même avec du jitter), petites requêtes uniformes, faibles ratios données-entrantes / données-sortantes, destinations rares de longue durée, et empreintes TLS/JA3 suspectes ou user-agents étranges. Le signal est le rythme et la rareté de la destination, pas le payload — qui est généralement chiffré.

Partez des techniques que vous voulez détecter, puis remontez jusqu'à la télémétrie qui les révèle — le mappage des sources de données d'ATT&CK y aide. En pratique, les sources à plus forte valeur sont la télémétrie endpoint des processus/lignes de commande et des chargements de modules (EDR/Sysmon), les journaux d'authentification et d'identité, le DNS et les flux proxy/réseau, et les journaux du plan de contrôle cloud. Vous auditez ensuite ce que vous collectez et conservez réellement face à ce dont chaque technique a besoin, exposant les angles morts. Une technique invisible dans tout journal n'est pas encore chassable.

L'ingénierie de détection traite les détections comme un produit logiciel doté d'un cycle de vie : identifier une menace ou technique à couvrir, étudier la télémétrie et le comportement, développer la règle, la tester face à des données de vrais positifs et bénignes, la déployer (souvent par étapes), la valider par émulation d'adversaire, puis l'ajuster en continu pour les faux positifs et retirer les règles qui ne se justifient plus. Chaque étape est documentée et versionnée, et la couverture est suivie par rapport à un cadre comme ATT&CK.

Les LOLBins (living-off-the-land binaries) sont des outils système légitimes, signés et préinstallés — comme certutil, bitsadmin, mshta, rundll32, regsvr32, wmic, powershell — que les attaquants détournent pour télécharger, exécuter ou persister tout en se fondant dans l'activité d'administration normale. Comme le binaire lui-même est de confiance, on ne peut pas détecter sur le fichier ; on détecte sur le contexte : arguments de ligne de commande anormaux, processus parents inhabituels, connexions réseau inattendues depuis ces outils, et exécution depuis des chemins étranges ou par des utilisateurs inhabituels.

La Pyramid of Pain classe les types d'indicateurs selon le coût pour un attaquant de les modifier une fois que vous détectez dessus. Les hashs sont triviaux à altérer (en bas), puis les adresses IP, les noms de domaine, les artefacts réseau/hôte, les outils, et enfin les TTP au sommet — qu'un attaquant ne peut changer qu'en réoutillant fondamentalement son comportement. Détecter aux niveaux supérieurs cause plus de « douleur » et est plus durable, donc les programmes matures investissent l'effort de détection vers les comportements et les TTP plutôt que les seuls IOC.

La chasse basée sur les TTP utilise MITRE ATT&CK comme carte : choisissez une technique pertinente pour votre modèle de menace (idéalement à faible couverture), formez une hypothèse concrète sur la façon dont elle apparaîtrait dans votre télémétrie, identifiez les sources de données qui la révèlent, interrogez-les et analysez les résultats. Une bonne chasse est délimitée, guidée par des hypothèses, liée à un comportement réel d'adversaire, reproductible, et produit un résultat durable — une nouvelle détection, une lacune de couverture documentée, ou la preuve que la technique est absente — qu'elle trouve ou non une compromission.

L'UEBA (User and Entity Behaviour Analytics) construit des référentiels comportementaux pour les utilisateurs et les entités (hôtes, comptes de service, appareils) et utilise des statistiques ou l'apprentissage automatique pour scorer les écarts comme du risque. Elle excelle face aux menaces sans signature nette : identifiants compromis, abus interne et déplacement latéral — p. ex. un utilisateur accédant soudain à des systèmes qu'il ne touche jamais, à des heures inhabituelles, ou déplaçant des volumes de données anormaux. Elle complète la détection basée sur des règles plutôt que de la remplacer, et nécessite un ajustement pour éviter les faux positifs dus aux changements de comportement légitimes.

La chasse aux menaces est la pratique proactive, guidée par des hypothèses, qui consiste à fouiller la télémétrie pour y trouver l'activité d'un adversaire que les détections existantes ont manquée. Contrairement au tri des alertes — réactif et qui attend qu'un outil se déclenche — la chasse part d'une question (« si un attaquant faisait X, quelles preuves verrais-je ? »), la teste face aux données, et soit trouve quelque chose, soit produit une nouvelle détection. Elle suppose que la prévention et les alertes sont imparfaites et qu'un adversaire déterminé est peut-être déjà à l'intérieur.

Sigma est un format YAML ouvert et neutre vis-à-vis des éditeurs pour décrire des détections SIEM. Vous définissez une logsource (product/category, par exemple Windows process_creation), un bloc detection avec des sélections nommées de correspondances champ/valeur, et une condition qui les combine. Un convertisseur (comme sigma-cli/pySigma) traduit la règle dans le langage de requête de votre backend réel — Splunk, Sentinel, Elastic — de sorte qu'une seule règle est portable. Elle porte aussi des métadonnées : title, level, status, faux positifs et tags ATT&CK.

Les revues d'accès (recertification) sont des vérifications périodiques où un propriétaire responsable confirme que l'accès de chaque personne reste justifié, et révoque ce qui ne l'est pas. Elles constituent le filet de sécurité qui détecte la dérive de privilèges, les comptes orphelins et les droits accordés pour un projet terminé. Le contrôle ne fonctionne que si un propriétaire compétent — généralement le manager ou le propriétaire de la ressource — examine réellement l'accès au lieu de le valider machinalement, et si les révocations sont appliquées.

L'accès conditionnel fait dépendre la décision d'accès du contexte plutôt que d'une règle fixe. Il évalue des signaux — qui est l'utilisateur, la conformité de l'appareil, la localisation, l'application et un score de risque calculé par détection d'anomalies — et répond proportionnellement : autoriser, bloquer ou exiger un renforcement comme la MFA ou un appareil conforme. L'accès basé sur le risque est la variante dynamique où un signal de risque en temps réel pilote la politique.

L'accès juste-à-temps accorde des privilèges élevés uniquement quand c'est nécessaire, pour une durée limitée, généralement avec approbation — puis ils expirent automatiquement, de sorte qu'il n'y a aucun privilège permanent à voler. Les comptes bris de glace sont l'exception délibérée : des comptes d'urgence très privilégiés, normalement dormants, verrouillés derrière des contrôles stricts et de fortes alertes, utilisés uniquement quand les chemins d'accès normaux échouent. Le JIT réduit la surface d'attaque quotidienne ; le bris de glace garantit que vous pouvez encore entrer en cas de crise.

Le NIST SP 800-63B moderne privilégie la longueur à la complexité : autoriser de longues phrases secrètes (au moins 8, en prendre en charge 64+), accepter tous les caractères y compris les espaces, et ne pas imposer de règles de composition comme « une majuscule, un symbole ». Filtrer les nouveaux mots de passe contre les listes de mots de passe compromis, abandonner l'expiration périodique obligatoire (renouveler uniquement en cas de preuve de compromission), et abandonner les « questions de sécurité » fondées sur la connaissance. Le but : des règles qui résistent aux vraies attaques au lieu d'agacer les utilisateurs vers des schémas prévisibles.

La MFA résistante au hameçonnage signifie que le second facteur ne peut pas être rejoué contre le vrai site même si l'utilisateur est trompé. Les passkeys FIDO2/WebAuthn y parviennent grâce à une cryptographie à clé publique liée à l'origine : l'authentificateur signe un défi lié au domaine du vrai site, de sorte qu'un identifiant capturé par un site sosie ou un attaquant-au-milieu est inutile. Les codes TOTP et les invites par notification restent hameçonnables car ils peuvent être relayés en temps réel.

Le PAM contrôle et surveille les comptes qui peuvent causer le plus de dégâts — administrateurs de domaine, root, comptes de service. Il met en coffre et fait tourner leurs identifiants pour qu'aucun secret ne soit partagé ou codé en dur, courtise les sessions pour que les administrateurs ne voient jamais le mot de passe brut, enregistre ce que font les utilisateurs privilégiés, et accorde idéalement l'élévation juste-à-temps plutôt qu'un accès permanent. L'objectif est de réduire le rayon d'impact des comptes que les attaquants convoitent le plus.

Le RBAC accorde des permissions via des rôles assignés aux utilisateurs — simple à raisonner mais sujet à l'explosion des rôles à mesure que les cas particuliers se multiplient. L'ABAC évalue des politiques sur les attributs de l'utilisateur, de la ressource, de l'action et de l'environnement, ce qui permet des décisions fines et contextuelles au prix de la complexité. La plupart des systèmes matures les combinent : des rôles pour les octrois grossiers, des attributs et des politiques pour les détails conditionnels.

SCIM (System for Cross-domain Identity Management) est une API REST/JSON et un schéma standard pour créer, mettre à jour et supprimer des comptes utilisateurs entre applications. Relié à un système RH ou à un IdP, il automatise le cycle de vie joiner-mover-leaver : les comptes et droits sont provisionnés à l'embauche, ajustés au changement de poste, et — surtout — déprovisionnés au départ, éliminant les comptes orphelins que les attaquants adorent.

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.

Le Zero Trust abandonne l'hypothèse selon laquelle être à l'intérieur du réseau vous rend digne de confiance. Chaque requête vers une ressource est authentifiée et autorisée pour elle-même — en vérifiant l'identité, l'état de santé de l'appareil et le contexte — par un point de décision de politique, accordant un accès au moindre privilège par session. Il n'y a pas de zone interne de confiance ; l'emplacement réseau d'une requête n'est qu'un signal, pas un laissez-passer.

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.

ATT&CK est une base de connaissances des tactiques (le pourquoi), techniques (le comment) et procédures adverses réelles. Vous l'utilisez pour cartographier vos détections existantes sur la matrice, repérer les lacunes de couverture et prioriser les techniques employées par les acteurs qui ciblent réellement votre secteur. Il offre un langage commun entre CTI, ingénierie de détection et réponse à incident, transformant « sommes-nous sécurisés ? » en une carte de couverture concrète et mesurable, fondée sur le comportement adverse réel.

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 gestion des vulnérabilités est une boucle continue : découvrir les actifs et vulnérabilités (scan, inventaire d'actifs), prioriser selon le risque réel (CVSS plus exploitabilité, exposition et criticité des actifs — des frameworks comme EPSS et SSVC aident), remédier ou atténuer, vérifier la correction et rapporter sur les tendances et les SLA. Le scan est la partie facile ; la discipline est de prioriser et de boucler la boucle pour que le risque baisse réellement avec le temps.

SSH utilise TCP 22, HTTP TCP 80, HTTPS TCP 443, DNS le 53 (UDP et TCP), RDP TCP 3389 et SMB TCP 445. Connaître les ports réservés permet de lire la sortie d'un scan, d'écrire des règles de pare-feu et de trier les alertes rapidement — un service sur son port attendu plutôt qu'inattendu est un signal immédiat.

Un résolveur stub demande un nom à un résolveur récursif. S'il n'est pas en cache, le résolveur récursif parcourt la hiérarchie : il interroge un serveur racine (qui pointe vers le TLD), le serveur TLD (qui pointe vers les serveurs autoritaires du domaine) et enfin le serveur autoritaire, qui détient l'enregistrement réel. La réponse est mise en cache en chemin selon son TTL. Le DNS utilise le port 53 — UDP pour la plupart des requêtes, TCP pour les volumineuses.

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

Traceroute découvre les routeurs entre vous et une destination en exploitant le champ TTL. Il envoie des paquets avec TTL=1, puis 2, puis 3, et ainsi de suite. Chaque routeur décrémente le TTL ; quand le TTL atteint zéro, ce routeur rejette le paquet et renvoie un message ICMP Time Exceeded, révélant son adresse. En augmentant le TTL, traceroute cartographie chaque saut dans l'ordre jusqu'à atteindre la destination.

Le NAT (Network Address Translation) réécrit l'IP source et/ou destination à mesure que les paquets franchissent une frontière, mappant généralement des adresses internes privées vers des publiques. Le PAT (Port Address Translation, ou NAT overload) étend cela en traduisant aussi les ports, laissant de nombreux hôtes internes partager une seule IP publique — chaque flux distingué par son port. Le PAT est ce que les routeurs domestiques et de bureau utilisent pour placer tout un LAN derrière une seule adresse.

Le modèle OSI divise le réseau en sept couches, chacune ajoutant une responsabilité : Physique (bits sur le câble), Liaison de données (trames et adressage MAC), Réseau (routage IP), Transport (TCP/UDP, ports, fiabilité), Session (gestion des connexions), Présentation (encodage, chiffrement, compression) et Application (protocoles comme HTTP). Chaque couche encapsule celle au-dessus à mesure que les données descendent la pile.

Un sous-réseau est une subdivision logique d'un réseau IP. Le masque de sous-réseau marque quels bits d'une adresse IP forment la partie réseau et quels bits forment la partie hôte — par exemple, /24 (255.255.255.0) signifie que les 24 premiers bits identifient le réseau et les 8 derniers les hôtes. Le découpage contrôle comment le trafic est routé et permet de segmenter un réseau en domaines de diffusion plus petits.

TCP ouvre une connexion en trois étapes. Le client envoie un SYN avec un numéro de séquence initial, le serveur répond par un SYN-ACK (accusant réception du numéro du client et envoyant le sien), et le client renvoie un ACK. Après cet échange, les deux parties se sont accordées sur les numéros de séquence de départ et la connexion est établie pour une livraison fiable et ordonnée des octets.

TCP est orienté connexion : il fait une poignée de main, numérote les octets, retransmet les pertes et contrôle la congestion, offrant une livraison fiable et ordonnée au prix de la latence et du surcoût. UDP est sans connexion et fonctionne en mode envoyer-et-oublier — pas de poignée de main, pas de retransmission, pas d'ordonnancement. Utilisez TCP quand l'exactitude compte (web, e-mail, transfert de fichiers) et UDP quand la vitesse prime sur la perfection (DNS, VoIP, jeux, vidéo).

Le modèle TCP/IP a quatre couches — Liaison, Internet, Transport et Application — et décrit le fonctionnement réel d'Internet. OSI en a sept. Elles correspondent étroitement : la couche Application de TCP/IP absorbe les couches Application, Présentation et Session d'OSI ; sa couche Liaison combine les couches Physique et Liaison de données d'OSI. OSI est la meilleure référence pour l'enseignement et le dépannage ; TCP/IP est la suite de protocoles réellement mise en œuvre.

Un VLAN (réseau local virtuel) partitionne logiquement un commutateur physique en domaines de diffusion de couche 2 distincts, de sorte que des appareils sur des VLAN différents ne peuvent pas se joindre directement, même sur le même matériel. Il est étiqueté par un marqueur 802.1Q sur les liens de trunk. La valeur de sécurité est la segmentation : isoler le trafic des utilisateurs, des serveurs, des invités et de l'IoT limite la portée des diffusions et le mouvement latéral, le trafic inter-VLAN étant forcé de passer par un routeur ou un pare-feu où la politique est appliquée.

Un VPN crée un tunnel chiffré au niveau réseau/OS, de sorte que tout le trafic d'un appareil y est routé et protégé de bout en bout — utilisé pour l'accès distant sécurisé. Un proxy opère au niveau applicatif, relayant le trafic d'applications ou de protocoles spécifiques sans nécessairement le chiffrer. Les grandes différences sont la portée (tout l'appareil vs par application) et le fait qu'un VPN chiffre par conception alors que de nombreux proxys ne le font pas.

Une DMZ (zone démilitarisée) est un segment réseau situé entre l'Internet non fiable et le réseau interne de confiance, hébergeant des services exposés au public comme les serveurs web, mail et DNS. Les règles de pare-feu laissent Internet atteindre la DMZ mais restreignent fortement l'accès de la DMZ au réseau interne. Le but est le confinement : si un serveur public est compromis, l'attaquant reste coincé dans la zone tampon plutôt que d'atterrir dans le LAN.

On commence par un scan complet des ports TCP, puis on énumère en profondeur chaque service ouvert — bannières, versions, identifiants par défaut, accès anonyme et contenu web — avant de toucher au moindre exploit. La plupart des machines tombent grâce à une énumération minutieuse, pas à des exploits astucieux, ce qui est le cœur de l'état d'esprit « try harder ».

Utilisez l'hôte compromis comme relais vers le sous-réseau inaccessible. Mettez en place une redirection de port pour un service unique, ou un proxy SOCKS dynamique (SSH -D ou chisel) et routez vos outils à travers lui avec proxychains, pour que votre machine d'attaque atteigne les hôtes internes via le pivot.

Énumérez les privilèges actuels (whoami /priv), les services mal configurés (permissions faibles, chemins de service non quotés), AlwaysInstallElevated, les tâches planifiées, les identifiants stockés et les correctifs manquants. WinPEAS ou PowerUp automatisent le balayage ; les abus de privilèges de jetons comme SeImpersonate sont des gains fréquents à forte valeur.

La défense en profondeur consiste à superposer plusieurs contrôles de sécurité indépendants pour que, si l'un échoue, les autres protègent encore l'actif. Aucun contrôle n'est supposé parfait, on empile donc des mesures préventives, de détection et de réponse sur les couches réseau, hôte, application et données.

Réduire la surface d'attaque (supprimer paquets et services inutilisés), imposer SSH par clé uniquement sans connexion root, maintenir le système à jour, exécuter un pare-feu en deny-par-défaut n'exposant que les ports nécessaires, appliquer le moindre privilège via sudo et les permissions de fichiers, activer auditd et la journalisation centralisée, et ajouter la surveillance d'intégrité ainsi qu'un MAC comme SELinux ou AppArmor.

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.

Le moindre privilège signifie que chaque utilisateur, processus ou service ne reçoit que l'accès minimal nécessaire à sa tâche, et rien de plus. Cela réduit le rayon d'impact de toute compromission ou erreur. On l'applique avec l'accès basé sur les rôles, l'élévation juste-à-temps, des revues d'accès régulières et la suppression des droits administrateurs permanents.

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 segmentation divise un réseau en zones isolées pour qu'une intrusion dans l'une ne puisse pas atteindre librement les autres, limitant le mouvement latéral. Le zero trust va plus loin : il supprime entièrement la confiance implicite fondée sur l'emplacement réseau, en authentifiant et autorisant chaque requête où qu'elle provienne — la microsegmentation est l'un des moyens de l'implémenter.

Le chiffrement symétrique utilise une seule clé partagée pour chiffrer et déchiffrer : c'est rapide, mais la clé doit être partagée de façon sûre. Le chiffrement asymétrique utilise une paire de clés publique/privée, ce qui résout la distribution des clés mais lentement. Les vrais systèmes utilisent la cryptographie asymétrique pour échanger une clé de session symétrique, puis le chiffrement symétrique rapide pour les données en masse.

Une PKI est le système de CA, de certificats et de politiques qui lie les clés publiques aux identités. Pour valider un certificat de serveur, un client construit une chaîne jusqu'à une racine de confiance, vérifie chaque signature, contrôle les dates de validité et le nom d'hôte, confirme l'usage de la clé, et vérifie la révocation via CRL ou OCSP.

La fatigue d'alerte est la désensibilisation qui s'installe lorsque les analystes font face à trop d'alertes peu utiles ou de faux positifs, ce qui les pousse à manquer ou à bâcler les vraies. On la combat en affinant les règles bruyantes, en priorisant par le risque, en dédupliquant et regroupant les alertes liées, en automatisant l'enrichissement répétitif avec un SOAR, et en mesurant la qualité des alertes, pas seulement leur volume.

Presque tout passe par le DNS, donc les logs DNS révèlent des menaces que d'autres sources manquent : le beaconing de command-and-control (rappels réguliers vers un domaine), le tunneling et l'exfiltration DNS (gros volume de sous-domaines longs et encodés), et les domaines générés algorithmiquement (DGA). On les détecte via des motifs comme la régularité des requêtes, l'entropie, les types d'enregistrement et le volume, plutôt que par une seule résolution suspecte.

L'EDR est centré sur l'endpoint : il enregistre et répond à l'activité des processus, fichiers et réseau sur les hôtes. Le XDR étend cette corrélation à plusieurs domaines — endpoint, réseau, identité, e-mail, cloud — en une stack intégrée par un même éditeur. Le SIEM est la couche large d'agrégation de logs qui ingère des données de n'importe quelle source, y compris non liées à la sécurité, pour la détection, la recherche et la conformité.

Comprenez d'abord pourquoi la règle se déclenche autant — trouvez le motif bénin commun derrière le bruit. Écrivez ensuite l'exclusion la plus étroite possible (hôte, compte ou comportement précis), documentez la justification, et validez qu'un vrai positif se déclencherait encore. Évitez les suppressions larges qui créent discrètement des angles morts.

ATT&CK est une base de connaissances des tactiques et techniques adverses réelles. Dans un SOC, vous mappez chaque règle de détection aux techniques qu'elle couvre, construisez une carte de couverture (souvent avec l'ATT&CK Navigator), puis priorisez la fermeture des lacunes selon les techniques les plus pertinentes pour votre modèle de menace et celles sur lesquelles vous n'avez aucune visibilité.

Un SIEM ingère et corrèle les logs de tout le parc pour générer des alertes — c'est votre couche de détection et de recherche. Un SOAR se situe en aval et automatise la réponse : il exécute des playbooks, enrichit les alertes via des intégrations, et gère les cas pour que les analystes passent moins de temps sur les étapes répétitives.

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.

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.