projet_gestion_commande/.claude/skills/securite-projet/SKILL.md

name, description

name	description
securite-projet	Checklist de sécurité spécifique à ce projet (JWT multi-rôles, 2FA Telegram, webhook crypto NowPayments, VPN, WAF, création de comptes admin-only). À invoquer avant de merger tout code touchant à l'authentification, aux paiements, aux endpoints admin/livreur/cabine, ou à l'infrastructure serveur — en complément du skill générique security-review, pas à sa place.

Sécurité — spécifique à ce projet

Cette checklist complète (ne remplace pas) le skill générique security-review. Elle encode les règles de sécurité propres à cette plateforme, qui ne sont pas détectables par une revue générique OWASP.

Authentification et autorisation

• Deux familles de JWT strictement séparées : USER_JWT_SECRET (client) et ADMIN_JWT_SECRET (admin/livreur/cabine). Ne jamais faire valider un token d'une famille par le middleware de l'autre.
• Sessions actives trackées dans Redis (session:{token}, TTL 5h client / 2h admin) — la révocation d'un token doit supprimer la clé Redis correspondante, pas seulement compter sur l'expiration JWT.
• Aucun endpoint d'auto-inscription client ne doit exister. Si une tâche demande d'ajouter un moyen de créer un compte client hors du panel admin, c'est un signal d'alerte à soulever explicitement avant d'implémenter.
• Pour tout nouvel endpoint livreur/cabine : vérifier le rôle et la propriété de la ressource (livreur_assign == username), jamais le rôle seul. C'est l'erreur la plus fréquente dans ce code : un livreur authentifié valide ne doit agir que sur ses propres commandes.
• 2FA : le session_token de vérification (TTL 5 min) et le code à 6 chiffres doivent rester rate-limités (429 après trop de tentatives) — ne jamais retirer ce rate limiting pour "simplifier" un flux.

Paiements crypto (NowPayments)

• Le webhook POST /api/v1/webhooks/nowpayments est un endpoint public par nécessité (appelé par NowPayments, pas par un utilisateur authentifié). Sa seule protection est la vérification HMAC-SHA512 de l'en-tête x-nowpayments-sig — ne jamais traiter un payload dont la signature ne vérifie pas, quel que soit le contenu.
• Ne jamais faire confiance à un statut de paiement transmis par le client (ex: un champ payment_status dans une requête utilisateur) — seul le webhook signé ou un appel serveur-à-serveur à l'API NowPayments (GetPaymentStatus) fait foi.
• Toute transition pending_payment → cancelled doit être gardée par une vérification du statut courant (WHERE status = 'pending_payment') pour éviter un double remboursement de stock si le webhook est reçu plusieurs fois (NowPayments peut renvoyer le même événement).

Requêtes base de données

• Toutes les requêtes utilisent des paramètres liés GORM (? binding) — jamais de concaténation de chaînes dans une requête Raw/Exec, y compris pour des valeurs qui semblent "internes" (statuts, IDs). Une seule exception acceptable : les noms de colonnes/tables provenant d'une liste blanche fixe dans le code, jamais d'une entrée utilisateur.
• Toute opération qui lit puis modifie un compteur/solde partagé (stock, solde de parrainage, compteur d'annulations) doit se faire dans une transaction avec FOR UPDATE si une décision (ex: "stock suffisant ?") dépend de la valeur lue — sinon condition de course exploitable (survente, sur-crédit).

Infrastructure

• PostgreSQL et Redis ne sont jamais exposés publiquement — accessibles uniquement via le VPN WireGuard (10.0.0.0/24) depuis prod-uber. Ne jamais suggérer d'ouvrir ces ports sur l'IP publique, même temporairement pour du debug.
• Les secrets (.env, clés JWT, NOWPAYMENTS_IPN_SECRET, TELEGRAM_WEBHOOK_SECRET) ne doivent jamais apparaître dans un commit, un log applicatif, ou une réponse API d'erreur.
• Le WAF (nginx + ModSecurity OWASP CRS) est le point d'entrée public — toute modification de routes ou de headers doit rester compatible avec ses règles (CSP, HSTS, TLS 1.2/1.3).
• SSH restreint au VPN sur les serveurs sensibles (monitoring-uber, backup-mln, bdd-redis-prod) — jump host via vpn-uber. Ne jamais recommander de désactiver cette restriction.

Checklist rapide avant de merger un changement sensible

Pour tout endpoint touchant argent, stock, statut de commande, ou compte utilisateur :

• Rôle et propriété de la ressource vérifiés (pas l'un sans l'autre)
• Entrées validées (bornes numériques, longueur de chaîne, whitelist de statuts)
• Requêtes paramétrées, aucune concaténation SQL
• Opération idempotente si l'action peut être rejouée (retry réseau, double-tap, webhook dupliqué)
• Transaction + verrou (FOR UPDATE) si lecture-puis-décision-puis-écriture sur une valeur partagée
• Pas de nouveau secret ou donnée sensible loggé en clair
• Si paiement crypto impliqué : signature webhook vérifiée avant tout traitement