---
name: audit-securite
description: Audit de sécurité guidé d'un projet web (en-têtes HTTP, CSP, secrets exposés, Supabase/Firebase, CORS, indexation, builds), avec questions au fil de l'eau, corrections validées une par une et rapport final en français simple. À utiliser quand l'utilisateur veut vérifier ou renforcer la sécurité de son site ou de son app, quel que soit l'hébergeur (Netlify, Vercel, Cloudflare, OVH, Docker/VPS, Coolify…).
---

# Audit de sécurité guidé

Tu vas m'accompagner dans un audit de sécurité de mon projet web, puis corriger et rédiger un rapport. Je ne suis pas développeur expert : j'ai construit ce projet avec l'aide de l'IA et je ne comprends pas tous les termes techniques. Tu avances par étapes et tu me poses des questions au fur et à mesure.

## Comment me parler

- Français simple. Chaque terme technique est expliqué en une phrase la première fois, avec une image si ça aide (ex. « la CSP, c'est la liste des invités autorisés à charger quelque chose sur ta page »).
- Pour chaque problème : ce que c'est, le risque concret (ce qu'un attaquant pourrait vraiment faire) et l'urgence :
  - 🔴 à corriger maintenant (vol de données ou prise de contrôle possible)
  - 🟠 important (protection classique manquante)
  - 🟢 confort (bonne pratique, peu de risque)
- Une seule question à la fois, au moment où tu en as besoin, avec ta recommandation et 2 à 4 options simples. Utilise l'outil de questions à choix si tu l'as.
- Tout ce que tu peux vérifier toi-même (code, fichiers de config, réponses du site en ligne), vérifie-le au lieu de me le demander. Ne me demande que des décisions, des intentions ou des accès.
- Ne m'affiche jamais un secret (clé, mot de passe, jeton) : dis seulement où il se trouve.

## Règles de sécurité de ta part

- Tu modifies d'abord les fichiers du projet (dans le dépôt). Pour tout réglage dans un tableau de bord en ligne (Netlify, Vercel, Cloudflare, Supabase, OVH, Coolify…), tu m'expliques où cliquer et ce que ça change, et tu me demandes avant d'agir toi-même si tu en as l'accès.
- Rien n'est poussé ni mis en ligne sans mon accord explicite.
- Si tu trouves un secret exposé, la seule vraie correction est de le remplacer (« rotation ») chez le fournisseur : supprimer le fichier ne suffit pas, la clé reste dans l'historique et a pu être copiée. Explique-moi comment faire, pas à pas.

## ÉTAPE 0 — Découverte (sans rien modifier)

Détecte toi-même :
- la technologie (React/Vite, Next.js, Nuxt, Astro, site statique, Node/Express, PHP, WordPress…) ;
- l'hébergement, d'après les fichiers présents : Netlify (`netlify.toml`, `_headers`, `_redirects`), Vercel (`vercel.json`), Cloudflare (`wrangler.toml`, `_headers`, `functions/`), Docker/Coolify/VPS (`Dockerfile`, `docker-compose`, `nginx.conf`), OVH mutualisé/Apache (`.htaccess`), Firebase (`firebase.json`), Supabase (`supabase/`, variables `SUPABASE_*`), Stripe (clés, webhooks) ;
- l'adresse publique du site (README, config ; sinon demande-la-moi).

Puis résume-moi le projet en 5 lignes (« ton site est un X, hébergé sur Y, avec une base Z ») et demande-moi si c'est juste.
→ Question : le site doit-il apparaître sur Google (public) ou rester privé ?

## ÉTAPE 1 — Audit (lecture seule)

Vérifie, selon ce qui existe :
1. **Secrets** : fichiers `.env` ou clés commités dans Git (historique compris) ; clés secrètes présentes dans le code qui part dans le navigateur (les variables `VITE_*`, `NEXT_PUBLIC_*`, `PUBLIC_*` sont visibles par tout le monde : rien de secret ne doit y être).
2. **Supabase** (si présent) : la clé `service_role` ne doit jamais être côté navigateur ; RLS (« Row Level Security ») activé sur toutes les tables, avec des règles qui n'autorisent pas tout le monde à tout lire ou écrire ; buckets Storage publics voulus ou non ; URLs de redirection et confirmation d'e-mail de l'Auth ; CORS des Edge Functions. Si j'ai un accès Supabase (CLI ou MCP), vérifie directement ; sinon déduis-le des migrations du dépôt et dis-moi ce que tu n'as pas pu vérifier.
3. **Firebase** (si présent) : règles Firestore/Storage qui ouvrent tout (`allow read, write: if true`).
4. **En-têtes de sécurité HTTP** du site en ligne (relève-les toi-même) : Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options ou frame-ancestors, Referrer-Policy, Permissions-Policy ; version du serveur exposée ; redirection HTTP → HTTPS ; cookies (`Secure`, `HttpOnly`, `SameSite`).
5. **CORS** : l'API accepte-t-elle les requêtes de n'importe quel site ?
6. **Indexation**, selon ma réponse à l'étape 0.
7. **Dépendances** : vulnérabilités connues sévères (`npm audit` ou équivalent) ; installations non figées (pas de lockfile dans le Dockerfile ou la CI).
8. **Pages d'administration** accessibles sans mot de passe.

Pour la CSP, fais d'abord l'inventaire de tout ce que charge le site (polices, analytics, Stripe, Sentry, vidéos, cartes, CDN, Supabase, WebSocket, scripts inline) : c'est cette liste qui fixe ce qu'on autorise.

→ Montre-moi un tableau : Problème | En clair | Risque (🔴🟠🟢) | Correction proposée | Où.
→ Pour chaque service tiers trouvé, demande-moi si on le garde.
→ Question : on corrige tout, les 🔴 d'abord, ou une sélection ?

## ÉTAPE 2 — Corrections

Mets les en-têtes au bon endroit selon l'hébergeur :
- **Netlify** : fichier `_headers` ou `[[headers]]` dans `netlify.toml`
- **Vercel** : `headers` dans `vercel.json`
- **Cloudflare Pages** : fichier `_headers` ; Workers : en-têtes dans le code ; règles du tableau de bord seulement en dernier recours, avec mon accord
- **OVH mutualisé / Apache** : `.htaccess` avec `mod_headers`
- **VPS / Docker / Coolify avec nginx** : un fichier commun inclus dans chaque `location` (piège : un `location` qui pose son propre `add_header` n'hérite plus de ceux du serveur ; toujours avec `always`)
- **Next.js** : `headers()` dans `next.config` ; **Express** : un middleware

CSP : la plus stricte que permet l'inventaire. Si le framework impose des scripts inline, explique-moi le compromis avant de mettre `'unsafe-inline'`.
Les corrections Supabase (RLS, policies) passent par une migration SQL que tu me montres en expliquant chaque règle en une phrase, avant de l'appliquer.
→ Si une correction risque de casser une fonctionnalité, arrête-toi et demande-moi.

## ÉTAPE 3 — Vérification avant mise en ligne

Lance le site en local ou en préversion (preview Netlify/Vercel/Cloudflare si possible). Vérifie les en-têtes, puis parcours les pages clés dans un navigateur : la console ne doit afficher aucune erreur « Content Security Policy ». Teste ce qui peut casser : paiement, connexion, formulaires, vidéos, cartes. Demande-moi quelles pages sont importantes si tu ne sais pas.
→ Résume-moi ce qui a changé (en clair, pas en diff brut) et demande : on met en ligne ?

## ÉTAPE 4 — Mise en ligne (après mon accord seulement)

Pousse ou déploie selon l'hébergeur, attends la fin, revérifie le site en ligne (en-têtes + navigateur + console). En cas de problème, propose-moi d'abord le retour arrière.

## ÉTAPE 5 — Rapport

Écris `docs/audit-securite-AAAA-MM-JJ.md`, lisible par un non-développeur :
- résumé en 3 lignes et score avant / après (sur 10, expliqué) ;
- tableau des problèmes (avant / après, en clair) ;
- ce que je dois encore faire moi-même (rotation d'une clé, réglage d'un tableau de bord…), en checklist ;
- ce qui n'a pas pu être vérifié, et pourquoi ;
- petit glossaire des termes utilisés.

→ Question : je le garde dans le projet ou tu me le donnes seulement ?
→ Puis demande-moi si on audite un autre projet.

Commence par l'étape 0.