Développement Système Sécurisé / Secure System Development

Si l'environnement d'exécution comporte une interdiction globale d'actifs (attaquer/scanner certains actifs propres), la configuration globale prévaut ; cette compétence ne la remplace pas. Pour un modèle générique, voir references/internal-policy.example.md (la version publiée ne contient aucune adresse interne réelle).

Mode d'emploi

Avant d'écrire du code, lisez la « Liste des lignes rouges » ; après l'écriture, faites une auto-vérification. Pour la conception et la révision, lisez la « Phase 1 ». Lorsque vous traitez un module spécifique, ouvrez le fichier correspondant dans references/. Avant la mise en production, exécutez la « Revue pré-mise en production » ; après la mise en production, lisez la section « Exécution et atténuation des 0-day ».

Si la tâche ne concerne qu'une partie spécifique (par exemple, écrire une interface de connexion ou concevoir une table de commandes), lisez uniquement les sections et références correspondantes, sans tout mémoriser.

Auto-vérification exécutable (recommandé)

python scripts/scan_redlines.py <répertoire_cible> --format text            # Lecture humaine
python scripts/scan_redlines.py <répertoire_cible> --format sarif --fail-on high   # Blocage CI
python scripts/scan_redlines.py <répertoire_cible> --code-only              # Ignorer la documentation, ne scanner que le code

Bibliothèque standard Python uniquement, aucune dépendance à installer. Couvre 18 catégories de règles : concaténation SQL, innerHTML/eval, caractères génériques et réflexion CORS, fallback global vers la page d'accueil, clés codées en dur, stockage de mots de passe en MD5, injection de commandes, désactivation de la vérification des certificats, commutateurs de débogage, champs sensibles dans les journaux, chemins de téléchargement non vérifiés, etc. Les résultats pointent vers les références correspondantes.

Gestion des faux positifs : ajoutez un commentaire redline: ignore à la fin de la ligne (ignore toute la ligne) ou redline: ignore SQL001 (ignore une règle spécifique). Ne désactivez pas une règle entière pour éliminer une alerte – notez la raison et expliquez-la lors de la revue.

Deux modèles : assets/threat-model-template.md (modélisation des menaces en phase de conception), assets/review-checklist.md (liste de contrôle par type de projet avant mise en production).

Déterminez d'abord le type de projet (décide quelles règles s'appliquent)

Scénario	Forme typique	Règles de sécurité	Exigence d'intégrité	Indexation (SEO)
Site public	Site officiel, page d'accueil, blog, documentation, vitrine	Ensemble complet	Faible (contenu public)	Obligatoire : vraie 404, sitemap, canonical, données structurées
Produit après connexion	SaaS, site utilitaire, portail utilisateur	Ensemble complet + système de compte complet	Moyenne (signature des opérations sensibles)	Soumettre uniquement les pages publiques (marketing/centre d'aide) ; pages privées noindex
Panneau d'administration	Admin, tableau de bord opérationnel, système de service client/révision	Ensemble complet + entrée indépendante + MFA + journal d'audit	Élevée (signature de toutes les opérations d'écriture + audit)	Interdit d'indexation : noindex complet du site + authentification obligatoire
Système interne/personnel	Plateforme interne, outil personnel, panneau de script, NAS familial	Authentification + exposition minimale + limitation de débit + mises à jour rapides	Moyenne (selon la surface d'exposition)	Interdit d'indexation ; ne pas mettre sur des chemins par défaut sur le réseau public, ne pas compter sur la « dissimulation » pour la sécurité
API pure	REST / GraphQL / Appels inter-services	Authentification + validation des entrées + limitation de débit + gestion des versions	Selon le métier (paiement/finance obligatoire)	Non applicable (pas de pages générées)

Il n'y a qu'une seule question à déterminer : Cette URL devrait-elle apparaître dans les moteurs de recherche ?

Oui → Exécuter comme un site public, la section SEO s'applique entièrement.
Non → Appliquer « Interdit d'indexation » : X-Robots-Tag: noindex sur tout le site, robots interdire l'exploration, authentification obligatoire. Ne pas appliquer l'optimisation SEO (sitemap, canonical, données structurées) aux systèmes internes ou aux panneaux d'administration – c'est un gaspillage et cela expose la surface d'attaque.
Quel que soit le scénario, « Un chemin inexistant doit retourner une vraie 404 » doit être respecté – c'est une question de correction HTTP, pas de SEO.

Cinq principes fondamentaux

Toute entrée n'est pas fiable : URL, query, body, header, cookie, fichier téléchargé, Webhook, file d'attente, valeur de retour d'API tierce, et même les données historiquement corrompues dans la base de données.
Refus par défaut (fail closed) : En cas d'erreur d'authentification/validation/analyse, retourner un refus, pas une autorisation ; les chemins d'exception ne doivent pas aboutir à une branche « d'ignorer la validation ».
Moindre privilège : Les comptes de base de données doivent être répartis par fonction (lecture/écriture séparée, pas de DDL), les IAM cloud/stockage d'objets doivent être autorisés par préfixe, le processus doit s'exécuter avec un utilisateur non root, le système de fichiers du conteneur doit être en lecture seule.
Défense en profondeur : Lorsqu'une couche échoue, la suivante reste active. La validation côté client est une question d'expérience, la validation côté serveur est une question de sécurité ; le WAF est un filet de sécurité, pas un substitut.
Limiter le rayon d'explosion : Les 0-day ne peuvent pas être éliminés par les règles de code, mais seulement par l'isolement, la limitation des privilèges, la liste blanche des sorties, et des canaux de correctifs rapides pour minimiser les dégâts.

Liste des lignes rouges (obligatoire, vérifier ligne par ligne)

Authentification et sessions

Les mots de passe doivent être hachés avec Argon2id/bcrypt(cost≥12)/scrypt. Interdiction du MD5/SHA1/chiffrement réversible.
Limiter le nombre de tentatives de connexion par double dimension « compte + IP », avec une temporisation progressive, et si nécessaire, un CAPTCHA ou un verrouillage temporaire.
Les messages de réponse et les temps de réponse pour la connexion, l'inscription et la récupération de mot de passe doivent être uniformes, sans révéler si le compte existe.
Après une connexion réussie, le session ID doit être renouvelé (pour empêcher la fixation de session). Le cookie doit être accompagné de HttpOnly + Secure + SameSite.
Le serveur JWT doit utiliser une liste blanche d'algorithmes fixes, rejeter alg:none et la confusion d'algorithmes. L'expiration doit être courte, le rafraîchissement doit être renouvelé et révocable.
Authentification ≠ autorisation : chaque interface doit explicitement vérifier « L'utilisateur actuel peut-il opérer sur cet objet » (pour prévenir l'IDOR/l'autorisation excessive).

Injections et sorties

Toutes les requêtes SQL doivent utiliser des requêtes paramétrées ou des liaisons ORM. La concaténation de chaînes est interdite. Les noms de table et les champs de tri doivent passer par une liste blanche.
Interdiction d'injecter des entrées utilisateur dans un shell/une commande ; utiliser la série execFile avec des tableaux de paramètres.
Les sorties doivent être encodées selon le contexte. dangerouslySetInnerHTML/v-html/innerHTML doivent passer par un sanitizer comme DOMPurify.
Les contenus riches, Markdown et les paramètres d'URL doivent être soumis à une liste blanche ; ne pas faire confiance à un filtrage côté client.
Les requêtes sortantes (SSRF) doivent passer par une liste blanche. Interdiction de suivre des redirections arbitraires. Bloquer les adresses internes/de métadonnées (169.254.169.254, 127.0.0.1, 10/8, 172.16/12, 192.168/16, ::1, file://, gopher://).
Les chemins de fichiers doivent être vérifiés après path.resolve pour s'assurer qu'ils commencent par le préfixe attendu. Interdiction du ... Les fichiers téléchargés doivent être renommés aléatoirement, leur type doit être détecté par inspection du contenu, ils doivent être stockés de manière isolée et sans droits d'exécution.

Données et concurrence

Les opérations d'écriture critiques doivent être idempotentes (index unique / clé d'idempotence). La passation de commande, le paiement et les rappels doivent être idempotents.
Les champs comme le stock, le solde et le nombre d'utilisations doivent utiliser une mise à jour conditionnelle : UPDATE ... WHERE stock >= ?. Interdiction de « lire puis modifier ».
Les transactions doivent être courtes ; à l'intérieur d'une transaction, interdiction d'appeler un réseau, d'envoyer un message ou de rendre un modèle.
Toute nouvelle requête doit être passée par EXPLAIN. Interdiction des grandes paginations avec OFFSET, SELECT *, et des requêtes N+1.
Les montants doivent être en centimes entiers ou en DECIMAL ; interdiction du float/double.

Asynchronisme et stabilité

Tous les appels externes (HTTP/DB/Redis/MQ) doivent avoir un timeout explicite. Interdiction d'attendre indéfiniment.
Les tentatives ne doivent être utilisées que pour des opérations idempotentes, avec backoff exponentiel + jitter + limite de nombre.
La consommation de messages doit être idempotente (table de déduplication avec message_id). En cas d'échec, le message doit aller dans une file d'attente de lettres mortes (DLQ) avec alerte.
Les modifications d'état critiques doivent d'abord être écrites dans la base de données avant d'envoyer un message (Outbox/transaction message). La double écriture est interdite.

Logique métier et conditions de course (la catégorie la plus souvent oubliée)

Les prix, montants, réductions et niveaux de permission doivent toujours être calculés côté serveur. La valeur soumise par le client ne sert qu'à l'affichage.
Les coupons, codes de réduction, codes d'invitation doivent être liés à un utilisateur et à un nombre d'utilisations, et être consommés de manière atomique (mise à jour conditionnelle ou contrainte unique).
La machine d'état doit être vérifiée explicitement : une transition invalide doit être refusée directement (par exemple, un pending ne doit pas devenir paid en contournant le rappel de paiement).
Les interfaces de paiement/rappel doivent vérifier la signature + le timestamp + la clé d'idempotence pour prévenir la relecture et la falsification.
Les limites d'achat et le contrôle de fréquence doivent être déterminés par une combinaison « utilisateur + appareil + IP », sans pouvoir être contournées par une seule dimension.
Les interfaces d'exportation, de traitement par lots et de recherche doivent être limitées en débit + en volume de données + avec un audit.

Secrets et opérations

Les secrets ne doivent être placés que dans les variables d'environnement ou les services de gestion des secrets. Interdiction de les mettre dans le dépôt, la couche d'image, le bundle frontend, les journaux ou les rapports d'erreur.
Les identifiants CI/CD doivent avoir le moindre privilège. Les déploiements en production nécessitent une approbation. Les dépendances tierces doivent être verrouillées en version + scannées.
Les opérations sensibles (connexion, changement de permission, exportation, suppression, remboursement) doivent être enregistrées dans un journal d'audit que le code métier ne peut pas modifier.

Intégrité des API (anti-packet sniffer/modification / rejeu / falsification de réponse)

Les requêtes sensibles (paiement, finances, autorisation, changement de mot de passe) doivent être signées : HMAC(secret, method+path+sortedQuery+sha256(body)+timestamp+nonce). Le serveur recalcule la signature.
Le nonce doit faire l'objet d'une déduplication (TTL = fenêtre de temps). Fenêtre de temps ±300s. Rejeter les requêtes expirées ou rejouées.
Les réponses sensibles (résultat de paiement, résultat d'autorisation, solde) doivent être signées par le serveur, et vérifiées par le client. Mais la vérité doit toujours être vérifiée à nouveau côté serveur.
Toute « marque de vérification », prix ou rôle soumis par le client ne doit pas être considéré comme la source de vérité. Le serveur doit recalculer/re-vérifier.
Certificat fixe (certificate pinning) côté mobile. La version release doit interdire la confiance aux certificats utilisateur, interdire le débogage et les commutateurs de sniffing de paquets.
Le renforcement côté client (obfuscation/renforcement/anti-débogage) ne fait qu'augmenter le coût, ne doit pas être considéré comme une frontière de sécurité. Ne pas distribuer les clés côté client.

Applications IA / LLM

La sortie du modèle est considérée comme une entrée non fiable : ne pas eval, ne pas concaténer directement dans du HTML/SQL/commande, ne pas exécuter directement les paramètres d'outil.
Les appels d'outils/fonctions doivent avoir le moindre privilège + validation du schema des paramètres + confirmation humaine pour les actions à haut risque.
Les documents récupérés par RAG sont considérés comme du contenu non fiable, isolés des instructions système, pour prévenir l'injection indirecte de prompts.
Les instructions système et les entrées utilisateur doivent être séparées. Ne pas placer de clés ou de règles internes dans un endroit qui pourrait être induit en sortie.
Limiter les coûts et la fréquence par utilisateur/locataire. Les journaux doivent être anonymisés (ne pas enregistrer de données sensibles contenues dans les prompts complets).

Mobile / Mini-programme

Les données sensibles doivent être stockées dans le Keychain (iOS) / Keystore (Android), pas dans des SharedPreferences en clair.
Le transport doit être en TLS obligatoire + fixation de certificat. InsecureSkipVerify/verify=False sont strictement interdits.
WebView : désactiver l'accès aux fichiers et limiter la surface d'exposition des ponts JS. onShouldStartLoadWithRequest doit faire une liste blanche de domaines.
La session_key du mini-programme ne doit être utilisée que côté serveur, jamais distribuée au frontend. Après code2session, délivrer sa propre session.
La détection de root/jailbreak ne sert que de signal de risque, pas de base d'authentification.

HTTP et routage (tous les scénarios)

Les chemins inexistants doivent retourner un vrai HTTP 404 + une page 404. Interdiction de faire une redirection 302/200 vers la page d'accueil.
Le fallback history des SPA ne doit s'appliquer qu'aux « routes frontend connues ». /api et les ressources statiques avec extension doivent retourner un 404.
CORS : utiliser une liste blanche d'origines exacte. Interdiction de Access-Control-Allow-Origin: * avec des identifiants, et interdiction de refléter une origine arbitraire.
En production, activer les en-têtes de réponse de sécurité : HSTS, CSP, X-Content-Type-Options, Referrer-Policy, frame-ancestors.
Les réponses des interfaces authentifiées/sensibles doivent inclure Cache-Control: no-store.
Les réponses d'erreur ne doivent pas révéler de stack, de SQL, de version de framework ou de chemin interne.

Indexation (uniquement pour les sites publics ; inversé pour les systèmes internes/backends)

Site public : le sitemap ne doit lister que les pages 200, canonical pour la déduplication, robots ne doit pas exposer les chemins du backend, le site de préproduction doit être entièrement noindex.
Systèmes backend/internes/personnels : tout le site doit avoir X-Robots-Tag: noindex + robots Disallow: /, ne pas générer de sitemap, et doit obligatoirement être authentifié (robots n'est pas un contrôle d'accès).

Phase 1 : Conception

Avant de commencer, prenez 5 minutes pour une modélisation légère des menaces :

Définissez le scénario : Référez-vous au tableau des types de projet ci-dessus pour déterminer s'il s'agit d'un site public, d'un backend, d'un système interne ou d'une API. Décidez en conséquence si la section SEO doit être exécutée et quelle est la surface d'exposition.
Dessinez le flux de données : Utilisateur → Passerelle → Service → Base de données/Cache/MQ/Tiers, identifiez chaque point de franchissement de la frontière de confiance.
Listez et classez les actifs : Comptes, identifiants, paiements, données personnelles, panneaux d'administration. Demandez-vous « Qui peut lire ? Qui peut écrire ? Quelles sont les conséquences d'une falsification ? Combien de temps doivent-ils être conservés ? ».
Pour chaque frontière, posez trois questions : Qui peut y accéder ? L'entrée est-elle validée ? En cas d'échec, refuse-t-on par défaut ?
Définissez le modèle de permissions : Rôle → Ressource → Action, à enforce côté serveur. Les boutons cachés côté client ne comptent pas. Pour les systèmes multi-locataires, définissez en plus une politique d'isolation.
Définissez les limites asynchrones : Quelles opérations doivent être synchrones (connexion, confirmation de paiement), et lesquelles peuvent être asynchrones (notifications, rapports, exportations).

Le document de conception doit au minimum préciser : le type de projet et la stratégie d'indexation, la méthode d'authentification, le modèle d'autorisation, la classification et le chiffrement des données sensibles, la politique de limitation de débit, la clé d'idempotence, la manière de dégrader en cas d'échec, et le périmètre des journaux et de l'audit.

Phase 2 : Implémentation

Authentification et connexion (priorité la plus élevée)

La connexion est le point d'entrée le plus sujet au brute force, au credential stuffing et au contournement. Voir les règles complètes dans references/auth-and-session.md. Points non négociables :

Limitation de débit en couches : IP unique, compte unique, empreinte unique d'appareil. Utilisez des clés Redis avec expiration pour le comptage des échecs, ne vous fiez pas uniquement à la mémoire.
Messages d'erreur uniformisés en « Nom d'utilisateur ou mot de passe incorrect », avec des temps de réponse alignés (même pour un compte inexistant, effectuez un faux hachage pour éviter l'énumération temporelle).
Après une connexion réussie, renouvelez le jeton de session. Déconnectez les anciennes sessions.
Les opérations sensibles (changement de mot de passe, changement d'informations liées, retrait, suppression) nécessitent une vérification secondaire ou une vérification du temps écoulé depuis la dernière authentification (fenêtre de ré-authentification).
Token de réinitialisation de mot de passe : grande entropie, à usage unique, courte durée de validité (≤15 minutes), lié à l'utilisateur et à l'action.
Le panneau d'administration doit avoir une entrée indépendante, un nom de domaine indépendant ou une liste blanche d'IP, et ne pas partager la session avec le portail utilisateur.

Entrées, injections et sorties

Voir references/web-vulnerability-prevention.md. Principe : Validation unifiée à l'entrée (schema), encodage contextuel à la sortie.

// Entrée : utiliser un schema pour valider, rejeter les champs inconnus, plutôt que de « prendre ce qui est nécessaire »
const LoginBody = z.object({ email: z.string().email(), password: z.string().min(8).max(128) }).strict();

// SQL : paramétré, jamais de concaténation
await db.query('SELECT id, password_hash FROM users WHERE email = $1', [email]);
// Pour les positions non paramétrables comme le tri/les noms de table : liste blanche
const orderBy = { created_at: 'created_at', amount: 'amount_cents' }[sort] ?? 'created_at';

XSS : Le rendu par défaut de React/Vue est suffisant, mais les API dangereuses doivent être sanitizées. CSP comme deuxième ligne de défense.
Autorisation excessive : Inclure owner_id = $currentUser dans les conditions de requête, ne pas « récupérer puis juger côté client ».
Désérialisation/injection de template : Ne pas eval, ne pas injecter d'entrée utilisateur dans un template/expression/règle.
Téléchargement : Limiter la taille et le type (détection par magic bytes), renommer aléatoirement, stocker dans un stockage d'objets, ré-encoder les images.

Base de données et haute concurrence

Voir references/database-concurrency.md. Points clés :

Index avant optimisation : Avant de mettre en production une nouvelle requête, lancez EXPLAIN. Surveillez type=ALL, filesort, tables temporaires.
Pagination par curseur (keyset), pas de deep offset. Les interfaces de liste doivent avoir un ordre stable + une limite.
Écriture à chaud : utiliser « mise à jour conditionnelle + verrou de ligne ». Exemple pour la déduction de stock :

UPDATE sku SET stock = stock - $1, version = version + 1
WHERE id = $2 AND stock >= $1;
-- Nombre de lignes affectées = 0 → stock insuffisant ou conflit de concurrence, réessai/échec selon le métier

Triplet du cache : Anti-pénétration (cache de valeurs nulles/filtre Bloom), anti-écrasement (verrouillage mutuel/singleflight), anti-avalanche (TTL avec jitter aléatoire).
La taille maximale du pool de connexions doit être inférieure à max_connections / nombre d'instances de la base de données, et configurer un timeout d'obtention.
Envisagez le sharding/partitionnement une fois que l'échelle augmente ; commencez par les index, le cache, la séparation lecture/écriture et la séparation données chaudes/froides.

Logique métier et conditions de course

Voir references/business-logic-and-race-conditions.md. Ces vulnérabilités n'ont pas de scanner universel ; elles ne peuvent être évitées qu'en les envisageant une par une lors de la conception : les prix et les montants sont calculés côté serveur, les coupons sont consommés de manière atomique, la machine d'état est vérifiée, la relecture est empêchée, les dimensions des limites d'achat sont définies, les exportations sont limitées. Les « lire puis écrire » en concurrence doivent être transformés en mises à jour conditionnelles ou en ajout d'un verrou + idempotence.

Architecture asynchrone prioritaire

Voir references/async-architecture.md. Par défaut, le système est conçu en asynchrone :

Toutes les IO sont non bloquantes. Dans Node, interdiction d'utiliser des fs/crypto synchrones et des calculs CPU lourds dans le chemin de la requête (utiliser worker_threads).
Chaque appel externe doit avoir un timeout. Transmettre un trace id dans la chaîne d'appels.
La consommation de file d'attente = au moins une livraison, donc doit être idempotente. Les tentatives ont une limite, au-delà de laquelle le message va dans la DLQ avec alerte.
La cohérence inter-services utilise Outbox/CDC, pas de double écriture.
Les tâches longues (exportation, traitement par lots, révision) sont placées dans une file d'attente, l'interface retourne immédiatement un task id, le frontend interroge ou reçoit un push SSE de l'état.
Arrêt gracieux : Arrêter de recevoir de nouvelles requêtes → attendre la fin des en-cours → fermer les consommateurs de files d'attente → fermer les connexions.

HTTP, routage, CORS et SEO

Voir references/http-routing-cors-seo.md. Les trois pièges les plus courants :

La 404 doit être une 404. Ne faites pas de fallback global vers la page d'accueil : les SPA ne doivent faire le fallback vers index.html que pour les routes frontend connues lors de la construction. /api/* et les chemins avec extension doivent retourner un 404 directement.
Liste blanche CORS précise : comparez l'Origin avec les éléments de configuration par égalité d'ensemble. N'utilisez pas includes, de correspondance de préfixe, ou de réflexion directe de l'en-tête request.
Codes d'état sémantiques corrects : 401 non authentifié, 403 pas de permission, 404 n'existe pas, 409 conflit, 422 échec de validation, 429 limitation de débit.

Le SEO ne s'applique qu'aux sites publics ; pour les systèmes backend et internes, suivez les règles « Interdit d'indexation » du tableau de scénarios ci-dessus. Ne leur ajoutez pas de sitemap, canonical ou données structurées – cela ajoute une surface d'attaque pour les crawlers.

Secrets, opérations et courrier électronique

Voir references/operations-and-secrets.md. Points clés : stockage et rotation des secrets par niveau, moindre privilège CI/CD, conteneur non root, stockage d'objets et IAM cloud minimisés, journal d'audit non modifiable, domaine email configuré avec SPF/DKIM/DMARC pour prévenir la contrefaçon, durée de conservation des données et processus de suppression.

Intégrité des API et anti-altération

Voir references/api-integrity-and-tampering.md. Le sniffing/la modification de paquets et la relecture sont les problèmes n°1 pour les applications mobiles et les API ouvertes : signature de requête (HMAC + timestamp + nonce + body hash), recalcul côté serveur, signature des réponses sensibles, déduplication du nonce, fenêtre de temps, fixation de certificat. Rappelez-vous : tout ce que le client peut modifier n'est pas fiable. La signature ne fait qu'augmenter la barrière ; le recalcul côté serveur est la vérité.

Sécurité des applications IA / LLM

Voir references/ai-llm-security.md. La sortie du modèle est équivalente à une entrée externe : ne pas exécuter, ne pas concaténer directement, ne pas l'utiliser comme SQL/commande. Les appels d'outils doivent avoir le moindre privilège + validation du schema + confirmation humaine pour les actions à haut risque. Le contenu RAG n'est pas fiable. Limiter le débit par locataire pour contrôler les coûts.

Mobile et mini-programme

Voir references/mobile-and-miniprogram.md. Keychain/Keystore, fixation de certificat, renforcement WebView, session_key du mini-programme non distribuée, détection de root uniquement comme signal.

Phase 3 : Revue pré-mise en production

Passez en revue dans l'ordre. Tout élément « incertain » est considéré comme non conforme :

La liste des lignes rouges doit être cochée à 100 %. Vérifiez ensuite par type de projet : site public = vérifier les éléments SEO ; système backend/interne = vérifier noindex et l'isolement de l'entrée ; métier sensible = vérifier l'intégrité de l'API.
Lancez python scripts/scan_redlines.py <répertoire> --fail-on high. Les alertes critiques doivent être éliminées.
Analyse des dépendances (npm audit / pip-audit / govulncheck / OWASP Dependency-Check). Les alertes critiques doivent être traitées.
Vérification des clés : aucun secret ne doit apparaître dans le dépôt, l'image, les journaux ou le bundle frontend. .env ne doit pas être versionné. Vérifiez également les journaux CI.
Conteneur/hôte : non root, système de fichiers racine en lecture seule, exposition de ports minimale, liste blanche des sorties.
Surveillance et alertes : taux d'échec de connexion, 5xx, accumulation dans la file d'attente, requêtes lentes, demandes sortantes anormales.
Exercice de sauvegarde et de restauration. Moindre privilège pour les comptes de base de données.
Test de charge sur les chemins critiques (connexion, commande, liste) pour confirmer que la limitation de débit et le cache fonctionnent.
Domaine email : SPF/DKIM/DMARC configurés, limitation de débit de l'interface d'envoi, pour éviter d'être utilisé pour des courriels de phishing ou d'être considéré comme une source de spam.
Cycle de vie des données : définir la collecte minimisée, la durée de conservation, le processus d'exportation et de suppression. Les journaux doivent être anonymisés avant conservation.
Plan de réponse aux incidents de sécurité : qui est responsable, comment isoler, comment notifier les utilisateurs, comment faire le bilan.
Cartographie de conformité (si nécessaire) : Référez-vous à references/compliance-mapping.md pour vérifier les éléments OWASP/ASVS/等级保护/PIPL.

Phase 4 : Exécution et atténuation des 0-day

Les règles de code ne peuvent pas prévenir les vulnérabilités inconnues. Les moyens suivants limitent leur impact :

Refus par défaut des sorties + liste blanche (première barrière contre le SSRF et les rappels de supply chain).
Isolation par bac à sable/conteneur pour les services critiques. Réduction des privilèges des processus. Activer seccomp/AppArmor si nécessaire.
Verrouiller les versions des dépendances + pouvoir reconstruire rapidement une image. Surveiller les bulletins de sécurité, réserver un canal pour les correctifs d'urgence.
WAF/passerelle pour le blocage générique et la limitation de débit, mais ne pas se fier uniquement à cela.
Surveillance comportementale : changement anormal de géographie/appareil pour les connexions, lectures/écritures en masse, trafic sortant anormal.
Classification des données : chiffrement des champs sensibles (AES-GCM/KMS), anonymisation des journaux, approbation requise pour l'exportation.

Index des références

Fichier	Quand lire
`references/auth-and-session.md`	Connexion, inscription, mot de passe, JWT, 2FA, récupération de mot de passe, CSRF, autorisation excessive, panneau d'administration
`references/web-vulnerability-prevention.md`	Injection SQL, XSS, SSRF, téléchargement, path traversal, désérialisation, en-têtes de réponse, risques spécifiques aux API
`references/business-logic-and-race-conditions.md`	Prix/montants, coupons, stock, machine d'état, TOCTOU/conditions de course, limite d'achat, abus d'exportation
`references/database-concurrency.md`	Création de table, index, transaction, verrou, idempotence, cache, séparation lecture/écriture, sharding/partitionnement
`references/async-architecture.md`	Timeout, tentatives, consommation de file d'attente, Outbox, backpressure, arrêt gracieux, observabilité
`references/http-routing-cors-seo.md`	404, codes d'état, CORS, cache, robots/sitemap, distinction d'indexation entre site public et backend
`references/operations-and-secrets.md`	Secrets, CI/CD, conteneur cloud, domaine email, journal d'audit, cycle de vie des données, urgence
`references/api-integrity-and-tampering.md`	Sniffing de paquets/modification, signature de requête/réponse, protection anti-rejeu, fixation de certificat, limite du renforcement client
`references/ai-llm-security.md`	Injection de prompts, permissions d'appel d'outils, empoisonnement RAG, traitement des sorties de modèle, limitation des coûts
`references/mobile-and-miniprogram.md`	Stockage local, fixation de certificat, WebView, état de connexion du mini-programme, détection root
`references/compliance-mapping.md`	OWASP Top 10 / ASVS / 等级保护 2.0 / PIPL, pour l'audit ou la présentation de revue
`references/internal-policy.example.md`	Lorsque vous avez besoin d'un modèle d'interdiction d'actifs personnalisé (domaines de substitution, sans adresse réelle)

Convention de livraison

À chaque remise de code, fournissez dans la réponse un résumé de 3 à 6 lignes expliquant les décisions de sécurité prises pour cette fois (points de validation, points d'authentification, clé d'idempotence, limitation de débit, gestion des erreurs). Ne les omettez pas.
Commencez par préciser le type de projet : si la livraison concerne un backend ou un système interne, indiquez clairement « Pas de SEO, noindex sur tout le site ». Seuls les sites publics doivent produire une configuration d'indexation.
Si vous découvrez une violation des lignes rouges dans le code existant, indiquez directement l'emplacement et proposez un correctif. Ne vous contentez pas de dire « Il est recommandé de renforcer ».
Pour les parties impossibles à vérifier (par exemple, si aucun test d'attaque réel n'a été effectué), indiquez clairement « Non vérifié ». Ne prétendez pas que le test de sécurité a été réussi.

bucai2417/sécurité-développement-système

Qu'est-ce que sécurité-développement-système ?

Demander à votre IA préférée

Documentation