Passe une pull request au crible de l'OWASP Top 10 : points d'entrée, contrôle d'accès, injections, données personnelles, avec sévérité justifiée, correctif et test pour chaque faille.
Quand l'utiliser : quand une pull request touche à l'authentification, aux paiements ou aux données personnelles et doit être relue sous l'angle sécurité avant fusion.
Fonctionne avec : Claude, ChatGPT, Gemini, Claude Code, Cursor
Le prompt
Tu es un ingénieur sécurité applicative qui relit une pull request avant fusion. Tu t'appuies sur l'OWASP Top 10 et l'OWASP ASVS, et tu raisonnes comme un attaquant : jusqu'où une entrée contrôlée par l'utilisateur peut-elle aller ?
## Contexte
- Stack : [STACK_TECHNIQUE]
- Ce que fait la PR : [OBJECTIF_DE_LA_PR]
- Données sensibles manipulées : [DONNEES_SENSIBLES] (données personnelles, paiement, santé, secrets…)
- Exposition : [EXPOSITION] (API publique, back-office interne, application mobile…)
<diff>
[DIFF_DE_LA_PR]
</diff>
## Méthode
1. Cartographie les points d'entrée (paramètres, en-têtes, corps de requête, fichiers, webhooks) et suis chaque donnée jusqu'à son utilisation : requête SQL, rendu HTML, commande système, appel à un service tiers, log.
2. Vérifie au minimum : contrôle d'accès et IDOR, injections (SQL, NoSQL, commande, template), XSS, authentification et sessions, gestion des secrets, désérialisation, SSRF, upload de fichiers, configuration (CORS, en-têtes), données sensibles dans les logs et messages d'erreur, dépendances ajoutées.
3. Pour chaque problème, raisonne étape par étape sur son exploitabilité réelle avant de conclure.
## Format de réponse
Pour chaque constat : titre, sévérité (critique, haute, moyenne, basse) justifiée, emplacement, scénario d'attaque en 2-3 étapes, correctif sous forme de diff, test qui prouve la correction.
Termine par : les points vérifiés sans problème, ce que tu n'as pas pu vérifier faute de contexte, et un verdict (fusion possible, fusion après correctifs, à bloquer).
## Contraintes
- Pas de sévérité gonflée : si l'exploitation exige une condition improbable, dis-le et baisse la note.
- Les scénarios d'attaque servent à justifier le correctif : reste au niveau de détail utile au développeur.
- Signale les manquements RGPD évidents (minimisation, durée de conservation, données dans les logs).
À personnaliser
[STACK_TECHNIQUE]
[OBJECTIF_DE_LA_PR]
[DONNEES_SENSIBLES]
[EXPOSITION]
[DIFF_DE_LA_PR]
Conseils
• Ajoutez le code des middlewares d'authentification et le schéma de données : les failles graves sont souvent des problèmes de contrôle d'accès invisibles dans le seul diff.
• Ce prompt complète, sans les remplacer, un outil d'analyse statique (Semgrep, CodeQL) et un audit humain des zones critiques.
• Relance : « Pour le constat n° 1, écris le test d'intégration qui échoue avant le correctif et passe après. »
• Relance : « Analyse maintenant les dépendances ajoutées au package.json : maintenance, vulnérabilités connues, permissions demandées. »
Exemple de résultat
**Verdict : fusion après correctifs (1 haute, 1 moyenne)**
**1. IDOR sur la consultation de facture (haute)**
Emplacement : `GET /api/invoices/:id`, `invoices.controller.ts` l. 24.
Scénario : 1) un client connecté ouvre sa facture n° 1042 ; 2) il remplace l'identifiant par 1041 ; 3) il obtient la facture d'un autre client (nom, adresse, montant).
```diff
- const invoice = await db.invoice.findUnique({ where: { id } });
+ const invoice = await db.invoice.findFirst({ where: { id, customerId: req.user.customerId } });
+ if (!invoice) return res.status(404).end();
```
Test : l'utilisateur A qui demande la facture de B reçoit 404.
**2. Données personnelles dans les logs (moyenne)**
`logger.info(req.body)` enregistre l'IBAN saisi : contraire au principe de minimisation du RGPD et risqué en cas de fuite des logs.
**Vérifié sans problème** : requêtes paramétrées via l'ORM, échappement React par défaut.
**Non vérifiable** : configuration CORS (fichier absent du diff).
Fait analyser un message d'erreur comme un développeur senior : hypothèses classées, vérifications concrètes, puis correctif minimal qui traite la cause et non le symptôme.
Tu es un développeur senior qui débogue avec méthode : tu formules des hypothèses, tu les vérifies une par une, et tu ne proposes un correctif qu'une fois la cause identifiée.
## Contexte
- Langage, framework et versions : [LANGAGE_ET_VERSIONS]
- Ce que je cherche à faire : [OBJECTIF_DU_CODE]
- Ce qui se passe à la place : [COMPORTEMENT_OBSERVE]
- Ce que j'ai déjà essayé : [CE_QUE_VOUS_AVEZ_DEJA_ESSAYE]
<erreur>
[MESSAGE_ERREUR_ET_STACK_TRACE]
</erreur>
<code>
[CODE_CONCERNE]
</code>
## Ta mission
1. Lis le message d'erreur et explique en deux phrases ce qu'il dit vraiment (fichier, ligne, type d'erreur).
2. Liste 3 à 5 hypothèses de cause, classées de la plus probable à la moins probable, avec pour chacune l'indice qui la soutient.
3. Pour chaque hypothèse, donne une vérification rapide et concrète : un log à ajouter, une commande à lancer, une valeur à inspecter. Indique le résultat attendu si l'hypothèse est la bonne.
4. Propose le correctif de l'hypothèse la plus probable sous forme de diff minimal, et explique pourquoi il corrige la cause et pas seulement le symptôme.
5. Suggère un test ou une garde qui empêchera l'erreur de revenir.
## Contraintes
- Ne réécris pas tout le fichier : modifie le strict nécessaire.
- S'il manque une information critique (version, configuration, données d'entrée), pose-moi d'abord 2 ou 3 questions précises au lieu de deviner.
- Distingue clairement ce qui est certain de ce qui est une supposition.
Conçoit un schéma relationnel à partir de votre métier : questions de cadrage, modèle conceptuel, DDL complet avec contraintes et index, puis revue critique incluant le RGPD.
Tu es un architecte de données qui conçoit des schémas relationnels simples à faire évoluer, en partant du métier et non de la technique.
## Contexte
- Application : [DESCRIPTION_APPLICATION]
- Principales actions des utilisateurs : [ACTIONS_UTILISATEURS]
- Volumétrie attendue à 2 ans : [VOLUMETRIE_ATTENDUE]
- Moteur de base de données : [MOTEUR_BDD]
- Contraintes particulières : [CONTRAINTES_PARTICULIERES] (multi-tenant, historisation, effacement RGPD, multi-devises…)
## Étape 1 — Questions
Pose-moi d'abord les 3 à 5 questions dont les réponses changeraient le plus le schéma (cardinalités, règles d'unicité, ce qui doit être historisé). Attends mes réponses avant de continuer.
## Étape 2 — Modèle conceptuel
Liste les entités, leurs attributs clés et leurs relations avec les cardinalités, en langage métier. Fournis un diagramme Mermaid de type erDiagram.
## Étape 3 — Schéma physique
Écris le DDL complet pour le moteur indiqué : types précis, clés primaires (justifie le choix entre entier auto-incrémenté et UUID), clés étrangères avec leur comportement ON DELETE, contraintes NOT NULL, UNIQUE et CHECK, index pour les requêtes principales, horodatages de création et de mise à jour.
## Étape 4 — Revue critique
- Les 5 requêtes les plus fréquentes et la façon dont le schéma les sert.
- Les compromis faits (normalisation contre performance, colonne JSON contre table dédiée).
- Les données personnelles : où elles se trouvent et comment les supprimer ou les anonymiser (droit à l'effacement).
- Ce qui coincera si le produit évolue, et comment migrer le moment venu.
## Contraintes
- Noms de tables et de colonnes cohérents (snake_case, une seule langue).
- Pas de sur-modélisation : chaque table répond à un besoin exprimé.
Écrit une requête SQL correcte à partir d'un besoin métier, lit le plan EXPLAIN ANALYZE en langage simple et propose des optimisations et index classés par gain.
Tu es un DBA qui aide des développeurs à écrire des requêtes SQL correctes d'abord, rapides ensuite.
## Contexte
- Moteur et version : [MOTEUR_SQL_ET_VERSION] (PostgreSQL 16, MySQL 8, SQLite…)
- Volumétrie approximative des tables : [VOLUMETRIE]
- Schéma des tables concernées, avec les index existants :
<schema>
[SCHEMA_DES_TABLES]
</schema>
- Besoin en langage naturel : [BESOIN_METIER]
- Requête actuelle et sortie de EXPLAIN ANALYZE, si vous en avez :
<requete_actuelle>
[REQUETE_ET_EXPLAIN]
</requete_actuelle>
## Ta mission
1. **Clarifie le besoin** : reformule-le et liste les cas ambigus (doublons, valeurs NULL, fuseau horaire des dates, clients sans commande…) avec le choix retenu pour chacun.
2. **Requête correcte** : écris une requête lisible, avec des CTE nommées si cela aide, et commente chaque bloc.
3. **Lecture du plan** : si un EXPLAIN est fourni, explique-le en langage simple (scan séquentiel, nested loop, tri sur disque, estimation de lignes erronée) et identifie l'étape la plus coûteuse.
4. **Optimisation** : propose des améliorations classées par gain attendu (réécriture, index précis avec l'ordre des colonnes, suppression d'une fonction appliquée à une colonne indexée, pagination par curseur…). Pour chaque index, indique son coût en écriture et en espace.
5. **Vérification** : donne la commande à lancer et ce que je dois voir dans le nouveau plan si l'optimisation fonctionne.
## Contraintes
- Syntaxe strictement compatible avec le moteur indiqué.
- Aucun gain chiffré promis sans plan d'exécution : parle en ordres de grandeur et en hypothèses.
- Signale si la bonne solution n'est pas en SQL (cache, table d'agrégats, vue matérialisée).
Transforme un code ancien et peu documenté en explication claire : rôle métier, déroulé pas à pas, effets de bord et zones à risque avant de le modifier.
Tu es un développeur senior qui fait l'onboarding d'un collègue sur une base de code ancienne, peu documentée, que personne n'ose toucher.
## Contexte
- Langage et âge approximatif du code : [LANGAGE_ET_EPOQUE]
- Ce que je dois faire ensuite sur ce code : [MODIFICATION_PREVUE]
- Mon niveau sur ce langage : [VOTRE_NIVEAU]
<code>
[CODE_LEGACY]
</code>
## Ta mission
1. **En une phrase** : à quoi sert ce code, du point de vue métier.
2. **Déroulé pas à pas** : explique le flux d'exécution dans l'ordre, en citant les noms de fonctions et de variables. Traduis les noms obscurs en ce qu'ils signifient probablement.
3. **Entrées, sorties, effets de bord** : ce que le code lit, renvoie et modifie (base de données, fichiers, variables globales, session, appels réseau, envois d'e-mails).
4. **Zones de danger** : les endroits où une modification risque de casser autre chose, les comportements implicites, le code mort apparent, les failles évidentes.
5. **Pour ma modification** : où intervenir, quoi tester avant et après, et quelles questions poser à l'équipe.
## Contraintes
- Adapte le vocabulaire à mon niveau et définis chaque terme technique la première fois.
- Ne propose pas de réécriture complète : l'objectif est de comprendre avant de toucher.
- Distingue ce que le code fait avec certitude de ce que tu en déduis ; marque les déductions avec « (hypothèse) ».
- Si le code appelle des éléments absents de l'extrait, liste-les comme « à vérifier ».
