{ "id": "input-validation-generated-code-n2", "code": "PS-0051", "titre": "Validation des entrées systématique dans le code généré", "resume": "Configure le modèle pour inclure systématiquement la validation des entrées dans tout code généré exposé à des données externes.", "type_ia": "dev-autonome", "piliers": [ "securite-productions" ], "niveau": "N2", "owasp": [ "LLM05" ], "tags": [ "validation-entree", "code-securise", "developpement", "sanitisation" ], "prompt_fr": "Dans tout code généré qui reçoit des données externes (formulaires, APIs, fichiers, base de données), inclus **systématiquement** la validation des entrées.\n\n**Règles**\n1. **Validation de type** : vérification du type attendu avant traitement.\n2. **Validation de longueur** : limites min/max sur les chaînes et collections.\n3. **Validation de format** : regex ou bibliothèque dédiée (email, URL, UUID...).\n4. **Sanitisation** : nettoyage des caractères dangereux selon le contexte de sortie (HTML, SQL, shell).\n5. **Rejet explicite** : retourne une erreur claire si la validation échoue — ne tente pas de corriger silencieusement.\n\n**Principe** : valide au point d'entrée, fais confiance en interne. Ne duplique pas la validation sur les données déjà validées.\n\n**Livrables à produire**\n- **Code conforme** : utilisation d'une bibliothèque de validation (Zod / Pydantic / Joi / class-validator) + commentaires `// SECURITY: input validation`.\n- **Schéma de validation centralisé** dans un fichier dédié (`schemas/.ts`) — réutilisable entre endpoint et tests.\n- **Bloc d'avertissement** si du code soumis manque de validation : « ⚠️ Validation manquante ligne N pour `` (type attendu : ``). Correction proposée : ``. »\n- **Événement CI/CD** (JSON-line) :\n `[INPUT_VALIDATION_MISSING] {\"ts\":\"\",\"file\":\"\",\"line\":,\"field\":\"\",\"severity\":\"\"}`", "prompt_en": "In all generated code that receives external data (forms, APIs, files, database), **systematically** include input validation.\n\n**Rules**\n1. **Type validation**: check expected type before processing.\n2. **Length validation**: min/max limits on strings and collections.\n3. **Format validation**: regex or dedicated library (email, URL, UUID...).\n4. **Sanitization**: cleaning dangerous characters depending on output context (HTML, SQL, shell).\n5. **Explicit rejection**: return a clear error if validation fails — do not attempt to silently correct.\n\n**Principle**: validate at the entry point, trust internally. Do not duplicate validation on already-validated data.\n\n**Deliverables to produce**\n- **Compliant code**: use of validation library (Zod / Pydantic / Joi / class-validator) + `// SECURITY: input validation` comments.\n- **Centralized validation schema** in dedicated file (`schemas/.ts`) — reusable between endpoint and tests.\n- **Warning block** if submitted code lacks validation: \"⚠️ Missing validation at line N for `` (expected type: ``). Suggested fix: ``.\"\n- **CI/CD event** (JSON-line):\n `[INPUT_VALIDATION_MISSING] {\"ts\":\"\",\"file\":\"\",\"line\":,\"field\":\"\",\"severity\":\"\"}`", "langue_recommandee": "indifferent", "modeles_recommandes": [ "tous" ], "source": { "auteur": "Mistral AI", "organisation": "Mistral AI", "url": "https://docs.mistral.ai/guides/guardrailing/", "type": "officielle" }, "cumulable_avec": [ "sql-injection-prevention-n2", "code-review-security-n2" ], "explication": "La documentation Mistral AI pour assistants de code insiste sur l'inclusion de la validation des entrées comme pratique de sécurité fondamentale. La validation d'entrée est la défense principale contre les injections (SQL, XSS, command injection).\n\n**Quand l'utiliser :** tout LLM générant du code serveur, des APIs, des formulaires ou tout composant traitant des données externes.\n\n**Ce qu'il protège :** LLM05 — prévention de génération de code non sécurisé par défaut. Couvre OWASP A03:2021 (Injection) et A04:2021 (Insecure Design). N2 : à combiner avec PS-0049 (SQL) et PS-0054 (XSS). Le schéma de validation centralisé est aussi utilisable comme **documentation API** vivante.\n\n**Couverture MITRE ATLAS :** [AML.T0049](https://atlas.mitre.org/techniques/AML.T0049) (Exploit Public-Facing Application).\n\n**Pour aller plus loin :** la discipline de cadrage d'un LLM développeur (modifications chirurgicales, simplicité, critères vérifiables) est traitée dans la doctrine [Cadrer son LLM développeur](https://promptsecops.fr/a-propos/cadrer-son-llm-developpeur/) — synthèse appliquée des principes popularisés par Andrej Karpathy fin janvier 2026, à combiner avec cette fiche en code review.", "installation": { "ou_quand": "À installer dans la config de l'assistant de développement backend. Profil personnel ou config projet — recommandé aux deux niveaux pour couverture maximale.", "moments": [ "profil", "projet-debut" ], "exemples": [ { "contexte": "Claude Code", "instruction": "`~/.claude/CLAUDE.md` (global) ou `./CLAUDE.md` (projet). Recommander explicitement la bibliothèque cible (Zod pour TS, Pydantic pour Python) dans le CLAUDE.md." }, { "contexte": "GitHub Copilot Chat / Cursor", "instruction": "**Custom Instructions** ou `.cursorrules`. Doubler avec un linter strict (eslint-plugin-security, Bandit) qui détecte les paramètres non validés." }, { "contexte": "ChatGPT (Custom GPT « API Builder »)", "instruction": "**Custom GPT → Instructions**. Indiquer aux développeurs d'utiliser ce GPT pour toute génération d'endpoint." }, { "contexte": "API en CI (review automatique)", "instruction": "Paramètre **`system`** + parser `[INPUT_VALIDATION_MISSING]` → bloquer le merge sur severity high. Cumuler avec un SAST (Snyk Code, Semgrep)." } ] }, "date_creation": "2026-05-17", "date_maj": "2026-05-24", "version": "1.1", "tokens_estimes": { "entree": 260, "sortie": null }, "referentiels": { "mitre_atlas": [ "AML.T0049" ] }, "changelog": [ { "date": "2026-05-17", "version": "1.0", "summary": "Création de la fiche" }, { "date": "2026-05-24", "version": "1.1", "summary": "Ajout référence doctrine \"Cadrer son LLM développeur\"" } ] }