Un audit applicatif ressemble peu à un test d'infrastructure. Pas d'Active Directory ni de réseau à cartographier : le pentester web passe ses journées dans Burp Suite, sur des parcours d'inscription, de paiement ou d'administration, et sur les API qui les servent. Les questions d'entretien pour un pentester web dépendent des applications auditées (SaaS, sites clients, applications internes, API pour le mobile), car le niveau attendu sur OAuth, GraphQL ou la lecture de code en dépend.
Beaucoup de candidats connaissent par cœur l'injection SQL et le XSS, travaillés sur la Web Security Academy de PortSwigger ou en CTF. Les profils qui ont fait de vraies missions parlent d'autre chose : un utilisateur qui lit les factures d'un autre client, un code promo appliqué deux fois, un jeton OAuth qui fuit vers un site tiers. L'entretien porte sur ces cas, et sur la façon de prouver l'impact sans toucher aux données réelles.
La BSCP de PortSwigger et l'OSWE d'OffSec sont les deux certifications les plus ciblées sur ce métier. Le PDF reprend l'entretien en six axes avec un cas d'audit d'API de 20 minutes.
Outils et référentiels d'un audit web
Burp Suite Professional
Le proxy d'interception de PortSwigger, outil central du métier. Il sert à rejouer et modifier chaque requête, à automatiser des variations, à envoyer des requêtes simultanées et à scanner. Les extensions (Autorize pour les contrôles d'accès, JWT Editor, Logger++) en font un atelier complet. Le candidat doit dire lesquelles il utilise et pourquoi.
OWASP WSTG et ASVS
Le Web Security Testing Guide décrit comment tester une application web, catégorie par catégorie. L'Application Security Verification Standard, en version 5.0 depuis mai 2025, liste les exigences de sécurité qu'une application doit respecter, sur trois niveaux. Le premier sert de méthode, le second de check-list d'audit et de référence pour les recommandations.
OWASP Top 10 et API Security Top 10
Deux classements des risques les plus courants. Le Top 10 web de 2025 place le contrôle d'accès défaillant en tête. Le Top 10 API de 2023 commence par l'autorisation au niveau des objets et inclut la consommation non bornée des ressources. Ce sont des repères pour le client, pas des méthodes de test.
OAuth 2.0 et OpenID Connect
Les protocoles derrière « Se connecter avec Google ou Microsoft » et derrière la plupart des API modernes. Le RFC 9700, publié en janvier 2025, fixe les bonnes pratiques de sécurité : correspondance exacte des adresses de redirection, PKCE obligatoire pour les clients publics, abandon du flux implicite. Un pentester web doit connaître ces flux et leurs défauts classiques.
JWT
Le format de jeton signé le plus utilisé par les API. Les erreurs de vérification de signature, d'algorithme ou de durée de vie sont fréquentes. Le RFC 8725 regroupe les bonnes pratiques. Un candidat doit savoir qu'un JWT signé n'est pas chiffré : son contenu se lit.
GraphQL
Un langage de requête d'API où le client choisit les champs qu'il veut. Il pose des problèmes propres : schéma exposé par l'introspection, autorisation à vérifier champ par champ, requêtes imbriquées très coûteuses. Les candidats qui n'ont audité que du REST le découvrent souvent en mission.
ZAP et Nuclei
ZAP (ex-OWASP ZAP, aujourd'hui « ZAP by Checkmarx ») est le proxy open source alternatif à Burp. Nuclei lance des modèles de détection de vulnérabilités connues sur de nombreuses cibles. Ils aident à couvrir vite les configurations et les versions, sans remplacer le test manuel.
Certifications BSCP et OSWE
La Burp Suite Certified Practitioner de PortSwigger est un examen pratique sur des applications vulnérables, valable cinq ans. L'OSWE d'OffSec porte sur l'audit en boîte blanche, avec lecture de code source et écriture de preuves de concept. La première montre la pratique de Burp, la seconde la capacité à lire du code.
Le pentester web travaille en cabinet d'audit, en prestation, chez un prestataire qualifié PASSI ou dans l'équipe sécurité d'un éditeur de logiciel qui audite ses propres produits à chaque version majeure. Une mission dure souvent de trois à dix jours sur une application, en boîte noire, grise (avec des comptes) ou blanche (avec le code). Le poste demande une bonne compréhension du développement web : HTTP, frameworks, sessions, API REST et GraphQL, OAuth. Les profils viennent du pentest généraliste, du développement ou du bug bounty. Un ancien développeur lit vite le code et comprend la logique métier, un ancien chasseur de primes trouve vite les failles mais doit parfois apprendre la rigueur du rapport et du périmètre.
Les points attendus d'un pentester applicatif
- Méthode d'audit et maîtrise de Burp Suite
- Contrôles d'accès et logique métier
- Authentification, sessions, OAuth et JWT
- Vulnérabilités côté serveur
- Audit d'API REST et GraphQL
- Sécurité côté navigateur et rapport
Logique métier, OAuth, SSRF : cinq questions d'entretien
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é
Sur un site marchand, un code promo de 10 % doit s'appliquer une seule fois par commande. Comment testez-vous la logique autour de ce code ?
Une bonne réponseIl commence par comprendre le parcours complet, puis vérifie si le code peut être réutilisé, appliqué plusieurs fois par des requêtes envoyées en même temps (condition de course), cumulé avec d'autres remises ou conservé après modification du panier. Il regarde aussi si le prix ou la remise sont calculés ou modifiables côté client. Tout se fait sur des comptes de test, sans vraie commande payée.
Signal d'alerteLancer le scanner sur la page panier, ou ne tester que l'injection dans le champ du code.
Question 2 · confirmé à senior
L'application propose « Se connecter avec » en OAuth 2.0 et OpenID Connect. Quels défauts cherchez-vous ?
Une bonne réponseUne adresse de redirection qui n'est pas comparée exactement à celle enregistrée, un paramètre state ou nonce absent ou non vérifié, le flux implicite encore utilisé, l'absence de PKCE pour un client public, un jeton qui fuit dans l'en-tête Referer ou les journaux, des droits demandés trop larges et une liaison de compte fondée sur une adresse e-mail non vérifiée. Il cite le RFC 9700 comme référence pour ses recommandations.
Signal d'alerte« C'est Google qui gère, donc c'est sûr », sans voir que l'intégration côté application est le point faible.
Question 3 · confirmé
L'API authentifie chaque appel par un JWT. Que vérifiez-vous sur ce jeton ?
Une bonne réponseQue la signature est vraiment vérifiée, que le serveur impose l'algorithme attendu au lieu de lire celui du jeton (familles d'attaque « alg none » et confusion d'algorithmes), que le secret de signature n'est pas faible, que l'audience, l'émetteur et l'expiration sont contrôlés, et qu'aucune donnée sensible n'est dans le contenu, lisible par tous. Il regarde aussi comment un jeton est révoqué. Il cite le RFC 8725.
Signal d'alerte« Le jeton est chiffré, on ne peut pas le lire », ou aucune notion de vérification de l'algorithme.
Question 4 · confirmé
Une fonction importe une image depuis une URL saisie par l'utilisateur. Quel risque testez-vous, et comment prouvez-vous l'impact sans danger ?
Une bonne réponseUne SSRF : le serveur peut être amené à appeler des adresses internes ou le service de métadonnées du cloud. Il prouve d'abord la requête sortante vers un serveur qu'il contrôle (interaction hors bande, par exemple avec Burp Collaborator), puis l'accès à un service interne sans effet. Il ne récupère pas de vrais identifiants cloud sans accord explicite. Il recommande une liste d'adresses autorisées côté serveur, le blocage des plages internes et IMDSv2 sur AWS.
Signal d'alerteIgnorer le risque parce que « c'est juste une image », ou aller chercher les identifiants cloud du client pour faire impression.
Question 5 · confirmé à senior
L'application expose une API GraphQL. Que testez-vous de différent par rapport à une API REST ?
Une bonne réponseL'introspection laissée active en production, qui livre tout le schéma. L'autorisation vérifiée sur chaque champ et chaque résolveur, et pas seulement sur la requête principale. Les requêtes très imbriquées ou regroupées, qui consomment beaucoup de ressources ou contournent la limitation des tentatives. Les messages d'erreur trop bavards. Il utilise des extensions Burp dédiées à GraphQL.
Signal d'alerteTester GraphQL comme une seule route REST, ou ignorer ce qu'est l'introspection.
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
Pentest applicatif : les questions fréquentes
Pentester web ou pentester généraliste : quelle différence ?
Si les missions portent surtout sur des applications, des API et du SaaS, un spécialiste web ira plus loin sur la logique métier, OAuth et la lecture de code. Pour des tests internes, externes et applicatifs enchaînés chez des clients variés, un généraliste sera plus facile à placer. Les entretiens diffèrent aussi : pour un profil web, l'Active Directory passe au second plan et l'entretien s'attarde sur les contrôles d'accès et les API.
Un ancien développeur peut-il devenir pentester web ?
C'est un parcours fréquent et souvent réussi. Un développeur comprend les frameworks, les sessions et les API, et lit vite du code en boîte blanche. Ce qu'il doit apprendre, c'est la méthode d'audit, les familles de vulnérabilités, la prudence en production et la rédaction d'un rapport pour un client. Une certification pratique comme la BSCP ou un historique de bug bounty montrent qu'il a franchi le pas.
Quel test technique est donné à un pentester web ?
Une petite application volontairement vulnérable, avec deux comptes de rôles différents, à auditer en deux ou trois heures. L'application comporte une faille de logique métier et un défaut de contrôle d'accès, pas seulement des injections classiques. Le candidat rédige une fiche de vulnérabilité pour la faille la plus grave. On voit la méthode dans Burp, la priorisation et l'écriture, ce que les entretiens oraux montrent mal.
Le bug bounty compte-t-il comme expérience professionnelle ?
Oui, si les rapports sont réels et vérifiables : profil public sur une plateforme comme YesWeHack, HackerOne ou Bugcrowd, vulnérabilités acceptées, programmes connus. Le bug bounty prouve la capacité à trouver des failles sur des applications de production. Il ne prouve ni le respect d'un cadrage client, ni la couverture méthodique d'une application, ni la qualité d'un rapport de mission complet. L'entretien vérifie ces trois points.
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.
