📋 Liste de contrôle avant développement

Éléments à vérifier avant de développer un nouveau point d'accès à l'API.

  • La spécification de l'API (OpenAPI) a été créée.
  • Les méthodes d'authentification et d'autorisation ont été déterminées
  • Les types de paramètres d'entrée et les contraintes ont été définis
  • Les champs à inclure dans les réponses ont été clairement définis
  • Le format de réponse aux erreurs est normalisé
  • Des exigences en matière de limitation des taux ont été établies
  • Le traitement des données personnelles et sensibles a été confirmé
  • La méthode d'authentification a été déterminée (OAuth 2.0, JWT, API Key)
  • Les autorisations requises (scopes/roles) ont été définies pour chaque point d'extrémité.
  • Des contrôles d'autorisation au niveau des ressources ont été conçus (contre-mesure BOLA).
  • Les fonctions administratives sont clairement séparées
  • Les méthodes d'expiration et de rafraîchissement des jetons ont été déterminées.
  • La communication utilise TLS 1.2 ou plus
  • La méthode de cryptage des données stockées a été déterminée
  • Les politiques de masquage et d'anonymisation des informations personnelles ont été déterminées
  • Les informations sensibles (jetons, mots de passe) ne sont pas incluses dans les journaux.
  • Les informations de débogage et les traces de pile ne sont pas incluses dans les réponses de l'API.

👀 Perspectives d'examen du code

Perspectives de sécurité à vérifier lors des examens du code de l'API.

Vérifier l'articleImportanceExplication
L'intergiciel d'authentification est appliqué à tous les points d'extrémité.ExigéeS'assurer qu'aucune vérification d'authentification n'est manquante, sauf pour les API publiques.
Il existe des contrôles d'autorisation au niveau de l'objetExigéeVérifier que les ressources demandées appartiennent à l'utilisateur demandeur
Les fonctions d'administration font l'objet d'une vérification des rôlesExigéeS'assurer que les utilisateurs ordinaires ne peuvent pas appeler les API d'administration
L'algorithme est spécifié lors de la vérification du JWTExigéePrévention de l'alg : aucune attaque
L'expiration du jeton est correctement configuréeRecommandéJeton d'accès : dans les 15 minutes
Vérifier l'articleImportanceExplication
Le corps de la demande est validé par le schémaExigéeValidation du type, de la longueur et du format
Les requêtes SQL sont paramétréesExigéeS'assurer que les requêtes ne sont pas construites avec une concaténation de chaînes de caractères
La validation du format des paramètres du chemin d'accès existeExigéeVérifier le format attendu tel que UUID
Les paramètres de pagination ont des limites supérieuresRecommandéEmpêcher les demandes excessives comme limit=999999
Les téléchargements de fichiers sont soumis à des restrictions de type et de tailleRecommandéValidation du type de contenu et de la taille du fichier
Vérifier l'articleImportanceExplication
Les réponses ne contiennent pas de champs inutilesExigéeEmpêcher les fuites de password_hash, d'identifiants internes, etc.
Les réponses d'erreur ne contiennent pas de trace de pileExigéeNe pas exposer d'informations internes dans la production
Les en-têtes de sécurité sont configurésRecommandéX-Content-Type-Options, HSTS, etc.
Content-Type est correctement définiRecommandéSpécifier explicitement application/json
Vérifier l'articleImportanceExplication
La limitation du débit est appliquéeExigéeEn particulier pour les points finaux d'authentification et de paiement
Les registres appropriés sont enregistrésRecommandéTraçabilité : qui a fait quoi et quand
Les secrets ne sont pas codés en durExigéeUtiliser des variables d'environnement ou des gestionnaires de secret
Les paramètres CORS sont appropriésRecommandéÉviter l'utilisation de caractères génériques
Les dépendances ne présentent aucune vulnérabilité connueRecommandéVérifier les résultats de l'audit npm / Snyk

📜 Modèles de politique de sécurité

Modèles de politiques de base pour le développement d'API internes. Personnalisez-les pour les adapter à votre projet.

1. Politique d'authentification

PolicyModèle
■ Méthodes d'authentification
  - API orientées vers l'utilisateur : OAuth 2.0 (code d'autorisation + PKCE)
  - API de serveur à serveur : OAuth 2.0 (Client Credentials) ou mTLS
  - API d'intégration externe : Clé API + signature HMAC

■ Gestion des jetons
  - Expiration du jeton d'accès : 15 minutes
  - Expiration du jeton de rafraîchissement : 7 jours (rotation requise)
  - Stockage du jeton : HttpOnly + Secure + SameSite Cookie

■ Politique en matière de mot de passe
  - 12 caractères minimum, au moins une majuscule, une minuscule, un chiffre et un symbole
  - Hachage avec bcrypt (facteur de coût 12 ou plus)
  - Protection contre les attaques par liste de mots de passe (intégration de l'API Have I Been Pwned)

2. Politique de conception de l'API

PolicyModèle
■ Versioning
  - Gestion des versions via le chemin URL : /api/v1/resources
  - Période de support de 6 mois minimum pour les anciennes versions
  - Notification de la dépréciation via l'en-tête Deprecation

■ Limitation du débit (valeurs par défaut)
  - API générales : 100 requêtes/15 min
  - API d'authentification : 5 demandes/15 min
  - API publiques : 30 requêtes/min
  - Renvoie toujours les en-têtes RateLimit-*.

■ Réponses
  - Content-Type : application/json (fixe)
  - Réponses d'erreur au format RFC 7807 (détails du problème)
  - Ne jamais renvoyer de traces d'erreur en production
  - Pagination : par défaut 20 éléments, max 100 éléments

3. Politique d'enregistrement et d'audit

PolicyModèle
■ Champs d'enregistrement obligatoires
  - Horodatage (ISO 8601, UTC)
  - ID de la demande (UUID pour la traçabilité)
  - ID de l'utilisateur / ID du client API
  - Méthode HTTP + point de terminaison
  - Code d'état
  - IP de la source
  - Temps de réponse

■ Champs d'enregistrement interdits (données sensibles)
  - Mots de passe / jetons / clés API
  - Numéros de carte de crédit
  - Affichage complet des IIP (masquage requis)

■ Alertes de surveillance
  - Échecs d'authentification : Alerte à 5+/min
  - Erreurs 403 : Alerte à 10+/min
  - 500 erreurs : Alerte immédiate dès la première occurrence
  - Dépassement de la limite de vitesse : Analyse des schémas

🚨 Flux de réponse aux incidents

Phase 1 : Détection

Détecter les incidents par le biais d'alertes de surveillance, de rapports d'utilisateurs ou de notifications externes. Déterminer la gravité de l'incident par un triage initial.

0-30 minutes

Phase 2 : Confinement

Prévenir l'escalade des dommages. Invalider les clés API, suspendre temporairement les points d'accès affectés et identifier l'étendue de l'impact.

30 min - 2 heures

Phase 3 : Eradication et rétablissement

Corriger les vulnérabilités, appliquer les correctifs et rétablir les services. Notifier les utilisateurs concernés.

2-24 heures

Phase 4 : Analyse post-incident

Procéder à un examen rétrospectif. Effectuer une analyse des causes profondes, élaborer des mesures de prévention des récidives et documenter les résultats.

1-5 jours ouvrables

🤖 AI / LLM Security Checklist

Additional checklist items for systems integrating AI models and LLM-powered features.

  • Model provider has been evaluated for security and compliance (SOC 2, data processing agreement)
  • System prompts are stored securely and not exposed to end users
  • Token budget and cost limits are configured per request and per user
  • Data classification policy defines what data can be sent to external LLM APIs
  • LLM outputs are validated and sanitized before rendering or downstream processing
  • Fallback behavior is defined for model unavailability or degraded responses
  • Model version pinning strategy is documented to prevent unexpected behavior changes
  • Agent permissions follow least privilege principle — only necessary tools and APIs are accessible
  • Tool/function calling uses an explicit allowlist (not a denylist)
  • Human-in-the-loop approval is required for high-impact actions (payments, deletions, external communications)
  • Agent memory scope is bounded — conversation history does not leak across tenants or sessions
  • Inter-agent communication is authenticated and uses signed messages
  • Goal drift detection is implemented — agents are monitored for deviation from intended objectives
  • Emergency kill switch exists to halt agent execution immediately
  • Training data provenance is documented with lineage tracking
  • Data integrity checks exist for training and fine-tuning datasets (hash verification)
  • Model artifacts are versioned and stored in a tamper-proof registry
  • Model drift monitoring is in place to detect performance degradation
  • Third-party models and embeddings have been evaluated for known vulnerabilities
  • PII and sensitive data scrubbing is applied to training datasets

🧐 AI / LLM Code Review Perspectives

Security check items specific to code that integrates LLMs, AI agents, and ML models.

Vérifier l'articleImportanceExplication
System prompts are not exposed in client-side code or API responsesExigéePrompt leakage enables targeted prompt injection attacks
LLM outputs are validated before rendering (HTML/JS/SQL)ExigéeLLM-generated content may contain XSS payloads or injection vectors
User input and system instructions are clearly separated in promptsExigéePrevents direct prompt injection by maintaining instruction-data boundary
Tool/function call permissions are scoped per user roleExigéePrevent privilege escalation through agent tool access
Token count limits are enforced per request and per sessionRecommandéPrevents cost explosion and denial-of-wallet attacks
RAG retrieval results are sanitized before insertion into promptsExigéeRetrieved documents may contain indirect prompt injection payloads
Agent actions and tool calls are logged with full audit trailRecommandéEssential for incident investigation and compliance in AI systems

📑 AI / LLM Security Policy Templates

Policy templates for organizations deploying AI models and LLM-powered applications.

4. AI Model Access Control Policy

PolicyModèle
■ Model Access Tiers
  - Tier 1 (Restricted): GPT-4 class / fine-tuned models — requires team lead approval
  - Tier 2 (Standard): GPT-3.5 class / embeddings — available to all developers
  - Tier 3 (Open): Open-source models (local inference) — no approval required

■ API Key Management for LLM Providers
  - One API key per service/environment (never share across projects)
  - Monthly spend alerts at 50%, 80%, 100% of budget
  - Hard spending caps enforced at the provider level
  - Key rotation: every 90 days or immediately upon team member departure

■ Data Sent to External Models
  - NEVER send: PII, credentials, internal IP, source code, customer data
  - ALLOWED with review: anonymized logs, public documentation, synthetic data
  - All prompts to external APIs must be logged (excluding PII)

5. AI Data Handling Policy

PolicyModèle
■ Training Data Requirements
  - All training data must have documented provenance and licensing
  - PII must be removed or anonymized before use in training/fine-tuning
  - Data poisoning checks: validate data integrity with hash verification
  - Retain training data snapshots for reproducibility and audit

■ RAG (Retrieval-Augmented Generation) Data
  - Document ingestion pipeline must sanitize content (strip scripts, injections)
  - Access control on vector store must mirror source document permissions
  - Embedding models must be versioned and pinned

■ Model Output Data
  - LLM outputs must not be trusted as authoritative — always verify facts
  - Generated code must pass the same security review as human-written code
  - Outputs containing PII must be flagged and redacted before storage

6. AI Incident Classification Policy

PolicyModèle
■ Severity Levels for AI-Specific Incidents
  - P1 (Critical): Prompt injection leading to data exfiltration or unauthorized actions
  - P1 (Critical): Model serving compromised or returning manipulated outputs
  - P2 (High): Training data poisoning detected, jailbreak bypass discovered
  - P2 (High): Agent performing unintended actions outside approved scope
  - P3 (Medium): Model drift causing degraded accuracy below threshold
  - P4 (Low): Cost overrun due to excessive token usage

■ Response Procedures
  - P1: Immediately disable affected model endpoint, notify security team
  - P2: Quarantine affected model version, roll back to last known good
  - P3: Trigger retraining pipeline, increase monitoring frequency
  - P4: Adjust rate limits and budget caps, review usage patterns

■ Post-Incident Requirements
  - Root cause analysis within 48 hours for P1/P2
  - Update prompt injection test suite with new attack vectors
  - Review and update guardrails configuration

Référence rapide : Codes d'état HTTP

Codes d'état HTTP liés à la sécurité utilisés dans la conception des API.

CodeSignificationCas d'utilisation
400Bad RequestErreur de validation des données
401UnauthorizedAuthentification requise ou jeton invalide
403ForbiddenAuthentifié mais autorisations insuffisantes
404Not FoundLa ressource n'existe pas (peut également être utilisé à la place de 403)
405Method Not AllowedMéthode HTTP non autorisée
413Payload Too LargeDépassement de la taille du corps de la requête
422Unprocessable EntityLa syntaxe est correcte mais la sémantique est erronée
429Too Many RequestsLimite de taux dépassée
500Internal Server ErrorErreur de serveur interne (cacher les détails)