robcsaszar/sentinel

Compétence d'audit de sécurité

Effectue un audit de sécurité statique rigoureux d'une base de code d'application web. Produit un tableau récapitulatif (PASS / FAIL / MANUAL-REVIEW) et des blocs par constat avec preuves fichier:ligne, description du risque et code de correction.

---

Phase 1 — Tri de la pile

Avant de scanner le code, répondez à ces questions en lisant package.json, les fichiers de configuration et le README :

1. Framework : SvelteKit / Next.js / Express / FastAPI / etc.
2. Pilote de base de données : paramétré (libsql, pg, prisma) vs. chaîne brute (pilotes bas niveau)
3. Mécanisme d'authentification : JWT / jetons HMAC / sessions / OAuth
4. Cible de déploiement : Fly.io / Cloudflare / Vercel / Node nu — détermine quel en-tête IP utiliser pour la limitation de débit et les journaux d'audit (Fly-Client-IP vs CF-Connecting-IP vs X-Forwarded-For) ; se fier au mauvais en-tête permet à un attaquant d'usurper son IP source.
5. Téléchargements de fichiers : oui/non — si oui, où sont-ils stockés (système de fichiers local, S3-compatible, CDN)
6. Appels sortants externes : API email, webhooks, récupération de médias — surfaces potentielles de falsification de requête côté serveur (SSRF)

Résumez votre analyse de la pile en un paragraphe avant la Phase 2. Des hypothèses erronées ici produisent des résultats faux.

---

Phase 2 — Analyse

LECTURE OBLIGATOIRE : references/security-checklist.md

Ne CHARGEZ PAS references/security-checklist.md pour des revues ciblées sur un seul point de terminaison — cela élargirait le périmètre au-delà de la tâche. Chargez-le uniquement pour des audits complets de la base de code.

Parcourez chaque catégorie de la checklist dans l'ordre — sauter un groupe nécessite une raison écrite dans le rapport.

Pour chaque catégorie :

• Lisez le(s) fichier(s) source concerné(s). Ne marquez pas PASS de mémoire.
• Si le fichier n'existe pas, marquez MANUAL-REVIEW avec une note.
• Enregistrez le verdict (PASS / FAIL / MANUAL-REVIEW) et une note de preuve d'une ligne.

Si le dépôt est trop volumineux pour lire chaque fichier, priorisez par risque : flux d'authentification et gestion des jetons d'abord, puis limites d'entrée/sortie, puis configuration des dépendances. Notez les fichiers qui ont été ignorés.

---

Phase 3 — Classification

Relisez vos notes brutes d'analyse. Pour chaque élément, appliquez les règles de verdict :

• PASS — vous avez lu le code concerné et confirmé que le contrôle est en place. Citez fichier:ligne.
• FAIL — vous avez trouvé une faille confirmée et exploitable. Vous avez un extrait. Vous pouvez écrire un correctif.
• MANUAL-REVIEW — le verdict nécessite du contexte d'exécution, un accès à l'infrastructure ou un jugement humain (ex. « vérifier que ce jeton a une portée en lecture seule sur le tableau de bord Turso »).

Avant d'assigner un verdict, demandez-vous : « Puis-je écrire le code de correction tout de suite, en utilisant uniquement ce que j'ai lu ? » Oui → FAIL. Non → MANUAL-REVIEW.

N'abaissez pas un FAIL en MANUAL-REVIEW pour adoucir le rapport.

---

Phase 4 — Rapport

Tableau récapitulatif en premier :

#	Catégorie	Statut	Notes
1	Injection SQL	PASS	Paramétré partout
2	XSS	FAIL	{@html} sur un champ contrôlé par l'utilisateur — voir constat
…	…	…	…

Ensuite, pour chaque FAIL et MANUAL-REVIEW, un bloc de constat :

### [N]. CATÉGORIE — FAIL
**Fichier :** `src/lib/example.ts:42`
**Extrait :**
  cookies.set(name, token, { httpOnly: true })   // ← drapeau Secure manquant
**Risque :** Cookie transmis en texte clair sur HTTP en dehors de la production ; intercepté par un MITM passif.
**Correctif :**
  cookies.set(name, token, {
    httpOnly: true,
    secure: process.env.NODE_ENV === "production",
    sameSite: "lax",
  });

Les blocs MANUAL-REVIEW utilisent le même format mais remplacent Correctif par Action décrivant ce que l'humain doit vérifier et où.

Les éléments PASS apparaissent uniquement dans le tableau récapitulatif — pas de blocs.

---

À NE JAMAIS FAIRE

• NE JAMAIS marquer PASS sans avoir lu le fichier À la place : Lisez le fichier, citez fichier:ligne dans la note de preuve. Pourquoi : Les verdicts PASS basés sur la mémoire produisent une fausse assurance — le but de l'audit est la preuve.

• NE JAMAIS marquer FAIL sans un extrait de code À la place : Citez la ou les lignes exactes vulnérables. Si vous ne trouvez pas d'extrait, c'est MANUAL-REVIEW. Pourquoi : Un FAIL sans preuve est du bruit ; les développeurs ont besoin de l'emplacement exact pour corriger.

• NE JAMAIS confondre FAIL et MANUAL-REVIEW À la place : FAIL = vous pouvez écrire le correctif tout de suite. MANUAL-REVIEW = vous ne pouvez pas, et vous dites pourquoi. Pourquoi : Les mélanger détruit la capacité d'action du rapport.

• NE JAMAIS sauter la Phase 1 de tri de la pile À la place : Lisez package.json et un fichier de configuration avant d'analyser quoi que ce soit. Pourquoi : L'en-tête IP à faire confiance, l'approche CSP valide et le modèle d'authentification applicable dépendent de la pile — des hypothèses erronées se répercutent en verdicts faux.

• NE JAMAIS rapporter un code de correction qui ne correspond pas au framework/bibliothèque du projet À la place : Écrivez les correctifs en utilisant les API exactes déjà en place (ex. cookies.set de SvelteKit, pas res.setHeader). Pourquoi : Les correctifs génériques qui ne compilent pas sont ignorés ; les correctifs spécifiques au framework sont fusionnés.

• NE JAMAIS écrire un bloc de constat pour une catégorie dont vous n'avez pas lu le fichier source À la place : Ouvrez le fichier, lisez-le, puis écrivez le bloc. Pourquoi : Un bloc de constat sans preuve de fichier est une assertion, pas un audit — cela érode la confiance dans l'ensemble du rapport lorsqu'il s'avère faux.

• NE JAMAIS ignorer silencieusement des fichiers dans un grand dépôt À la place : Priorisez par risque (authentification/gestion des jetons → limites d'entrée/sortie → configuration des dépendances) et listez explicitement chaque fichier ignoré dans le rapport. Pourquoi : Les omissions silencieuses rendent les affirmations de couverture de l'audit invérifiables — un rapport propre sur une analyse incomplète est interprété comme un faux feu vert.