Sur un poste d'AppSec, la difficulté tient à la largeur du champ. Le même ingénieur mène une analyse de menace avec une équipe produit, relit le code d'authentification d'une API, écrit des exigences tirées de l'OWASP ASVS et trie les signalements d'un chercheur externe. Les questions d'entretien d'un ingénieur sécurité applicative partent des failles qui reviennent en production : contrôle d'accès cassé, jetons mal validés, données d'un client visibles par un autre.
Les CV mélangent souvent trois parcours. Un ancien pentester web connaît les attaques mais a parfois peu conçu. Un développeur passé à la sécurité lit bien le code et connaît moins le cadre normatif. Un profil DevSecOps maîtrise les outils de la chaîne de livraison et moins la logique applicative. Les exemples portent sur une application que la personne a suivie de la conception à la production.
Le candidat travaille sur du concret plutôt que sur des définitions : une route d'API, un flux de connexion, un extrait de code. Une réponse apprise se repère vite quand on demande où placer le contrôle et comment le tester. Le PDF ajoute 30 questions sur six axes, un cas de conception de 20 minutes et une grille de notation de 1 à 4.
Référentiels et outils d'un ingénieur AppSec
OWASP Top 10:2025
La liste des risques applicatifs les plus fréquents, mise à jour en 2025. Le contrôle d'accès cassé reste en tête et absorbe la SSRF, les défaillances de la chaîne d'approvisionnement logicielle entrent à la troisième place, et une catégorie sur la mauvaise gestion des conditions d'erreur apparaît. Un candidat qui cite encore uniquement la version 2021 n'a pas suivi.
OWASP ASVS 5.0
Le référentiel d'exigences de vérification de la sécurité des applications, publié en version 5.0 en mai 2025. Il sert à écrire les exigences d'un projet et à vérifier qu'elles sont tenues, avec des niveaux selon la sensibilité de l'application. Reste à savoir comment la personne le découpe pour une équipe.
OWASP API Security Top 10 2023
Les risques propres aux API : autorisation au niveau de l'objet et de ses propriétés, authentification, consommation non bornée des ressources, flux métier sensibles. La plupart des failles graves trouvées sur des applications récentes passent par une API.
Analyse de menace (STRIDE, Threat Dragon)
La revue de conception avant le code. On dessine les flux de données et les frontières de confiance, puis on cherche ce qui peut mal tourner sur chaque flux. STRIDE est la méthode la plus courante, OWASP Threat Dragon ou Microsoft Threat Modeling Tool les outils les plus cités.
OAuth 2.0, OpenID Connect et JWT
Les protocoles d'authentification et de délégation des applications modernes. La RFC 9700, publiée en janvier 2025, fixe les bonnes pratiques de sécurité d'OAuth : PKCE, abandon du flux implicite, rotation des refresh tokens. Beaucoup de failles viennent d'une validation incomplète des jetons.
SAST et règles personnalisées (Semgrep, CodeQL, SonarQube, Checkmarx)
L'analyse statique du code. L'ingénieur AppSec ne se contente pas des règles livrées : il écrit des règles pour les fonctions internes de l'entreprise et trie les résultats avec les équipes. L'administration de ces outils à grande échelle relève plutôt d'un poste d'outillage dédié.
DAST et proxy d'interception (ZAP, Burp Suite)
Les tests de l'application en fonctionnement. ZAP, autrefois projet OWASP, et Burp Suite servent aux scans automatisés comme aux vérifications manuelles d'une faille signalée. Un scan qui ne s'authentifie pas teste surtout la page de connexion.
OWASP Top 10 for LLM Applications
Les risques des applications qui intègrent un modèle de langage : injection de prompt, sortie non maîtrisée, agents aux droits trop larges. Le sujet arrive dans les revues de conception dès qu'une équipe branche un assistant sur des données internes.
Cyber Resilience Act
Le règlement européen (UE) 2024/2847 sur les produits comportant des éléments numériques. Depuis le 11 septembre 2026, les fabricants doivent signaler les vulnérabilités activement exploitées. La plupart des autres obligations s'appliquent à partir du 11 décembre 2027. Il concerne surtout les éditeurs de logiciels et de produits connectés.
Selon l'organisation, le poste s'appelle ingénieur AppSec, expert ou consultant sécurité applicative, parfois responsable de la sécurité applicative quand il anime un réseau de security champions. Chez un éditeur de logiciels, il suit quelques produits en profondeur et travaille au contact du code. Dans une grande DSI, il couvre des dizaines d'applications, intervient surtout en conception et en recette, et s'appuie sur les outils de la chaîne CI/CD gérés par une équipe DevSecOps. Les certifications comme la GWAPT, l'OSWE ou la BSCP de PortSwigger montrent un niveau offensif ; elles ne disent rien de la capacité à faire adopter une correction par une équipe.
Six compétences à contrôler chez un ingénieur sécurité applicative
- Analyse de menace en conception
- Authentification et autorisation
- Revue de code sécurisée
- Sécurité des API
- Exigences et tests de sécurité
- Gestion des signalements et nouveaux risques
Questions techniques pour un ingénieur sécurité applicative
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé à senior
Une équipe conçoit un export CSV des données clients, lancé depuis l'interface et livré par un lien envoyé par e-mail. Menez l'analyse de menace en cinq minutes.
Une bonne réponseIl dessine les flux : navigateur, API, tâche asynchrone, stockage objet, e-mail. Puis il parcourt chaque flux avec STRIDE, même sans la nommer : qui peut lancer l'export et sur quel périmètre, paramètres de filtre modifiables, formules injectées dans les cellules qu'Excel exécutera, lien devinable ou sans expiration, e-mail transféré, absence de trace des exports, exports massifs qui saturent le service. Contre-mesures : contrôle du périmètre côté serveur, lien signé à durée courte avec authentification au téléchargement, neutralisation des cellules qui commencent par =, +, - ou @, quotas et journalisation.
Signal d'alerte« On chiffre le fichier » sans jamais décrire les flux, ou une liste de menaces génériques sans contre-mesure.
Question 2 · confirmé à senior
Une application monopage React appelle une API protégée par OAuth 2.0. Quel flux recommandez-vous, et où les jetons doivent-ils vivre ?
Une bonne réponseLe flux authorization code avec PKCE. Le flux implicite est à proscrire, comme le dit la RFC 9700 sur les bonnes pratiques de sécurité OAuth. Il préfère un backend for frontend qui garde les jetons côté serveur et ne donne au navigateur qu'un cookie de session HttpOnly, Secure et SameSite. À défaut, des jetons en mémoire, de courte durée, et des refresh tokens avec rotation. Le localStorage reste lisible par n'importe quel script injecté.
Signal d'alerteLe flux implicite, ou un jeton valable une semaine rangé dans le localStorage.
Question 3 · junior à confirmé
En revue de code Java, vous voyez une requête SQL construite par concaténation, mais la valeur vient d'une liste déroulante. Est-ce une faille ?
Une bonne réponseOui. La valeur part du navigateur, et la liste ne contraint que l'interface : un proxy comme Burp la modifie sans effort. Correction : requête paramétrée (PreparedStatement, paramètres nommés JPA). Pour un nom de colonne ou un ORDER BY qu'on ne peut pas paramétrer, une liste d'autorisation côté serveur. Il remonte le flux de la source jusqu'à l'appel SQL pour confirmer.
Signal d'alerte« Pas exploitable, l'utilisateur ne peut choisir que dans la liste. »
Question 4 · confirmé
Une API REST renvoie l'objet utilisateur complet alors que le front n'affiche que le nom. Quel problème voyez-vous, et que demandez-vous à l'équipe ?
Une bonne réponseUne exposition de propriétés, la catégorie API3 de l'OWASP API Security Top 10 2023 : le rôle, l'e-mail, des champs internes ou un hash circulent en clair dans la réponse. En écriture, le même défaut donne l'affectation de masse, où un PUT avec "role": "admin" passe. Il demande des objets de sortie et d'entrée explicites, une liste des champs modifiables et des tests qui vérifient l'absence des champs sensibles.
Signal d'alerte« Le front ne les affiche pas, donc pas de souci. »
Question 5 · confirmé à senior
Un projet démarre. Comment transformez-vous l'OWASP ASVS en exigences que l'équipe appliquera vraiment ?
Une bonne réponseIl part de l'ASVS 5.0, publiée en mai 2025, choisit le niveau selon l'exposition et les données, et ne retient que les chapitres utiles au projet. Les exigences deviennent des critères d'acceptation dans les user stories et, quand c'est possible, des tests automatisés. Ce qui ne se teste pas automatiquement passe en revue de code ou en recette sécurité, avec une trace de ce qui a été vérifié.
Signal d'alerteEnvoyer le PDF de l'ASVS à l'équipe en lui demandant de s'y conformer.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Ingénieur sécurité applicative : les questions fréquentes
Quelle différence entre un ingénieur sécurité applicative et un ingénieur DevSecOps ?
L'ingénieur DevSecOps construit la chaîne : scanners branchés dans la CI, signature des artefacts, gestion des secrets. L'ingénieur sécurité applicative travaille sur ce que fait l'application : conception, autorisation, logique métier, revue de code, exigences. Les deux postes se recoupent sur le tri des résultats des outils. Dans une petite équipe, une seule personne tient souvent les deux rôles, et l'entretien doit alors couvrir les deux.
Un développeur peut-il devenir ingénieur AppSec ?
Oui, c'est même un des parcours les plus fréquents. Un développeur expérimenté lit vite le code, comprend les contraintes des équipes et propose des corrections réalistes. Il lui manque souvent la vision de l'attaquant et la connaissance des référentiels. Il doit savoir exploiter lui-même une faille simple avec Burp, et pas seulement la décrire, et qu'il a déjà mené une analyse de menace.
Quel test technique est donné à un ingénieur sécurité applicative ?
Une revue de code d'une heure fonctionne bien. Le support est un petit service de quelques centaines de lignes avec trois failles réalistes : une IDOR, une validation de JWT incomplète, une injection dans un tri. La personne les trouve, les cote et propose la correction. L'exercice se termine par cinq minutes d'analyse de menace sur une nouvelle fonction du même service.
Faut-il maîtriser le langage de développement de l'équipe ?
Il doit lire couramment au moins un langage du parc et comprendre son framework principal, car les failles se nichent dans la façon dont Spring, Django ou Express gèrent l'authentification et la sérialisation. Passer d'un langage à un autre prend quelques semaines pour un bon profil. Ne pas lire de code du tout, en revanche, limite le poste aux outils et aux référentiels.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
