Sécurité ANSSI — Règles essentielles

Règles de sécurité pour le développement d'applications de l'État, issues du guide d'hygiène informatique ANSSI et des recommandations TLS.

Source : https://cyber.gouv.fr/reglementation/cybersecurite-systemes-dinformation/

---

Workflow d'audit

1. Analyser le projet (code source, configuration, infrastructure, CI/CD)
2. Parcourir les 12 domaines de la checklist ci-dessous
3. Pour chaque règle, attribuer un statut :
   • OK — Règle respectée
   • KO — Règle non respectée (identifier le problème et le risque)
   • NA — Non applicable (justifier)
   • Partiel — Partiellement respectée (préciser ce qui manque)
4. Produire le rapport structuré selon le format défini en fin de document
5. Exporter le rapport : écrire le rapport dans un fichier Markdown ET l'afficher dans la conversation

---

Checklist par domaine

1. TLS / HTTPS

• HTTPS obligatoire sur tous les échanges (pas de HTTP en production)
• TLS 1.2 minimum, TLS 1.3 recommandé
• Certificats valides et renouvelés avant expiration
• Désactiver les suites de chiffrement faibles (RC4, DES, 3DES, MD5)
• Header Strict-Transport-Security (HSTS) avec max-age ≥ 1 an

Strict-Transport-Security: max-age=31536000; includeSubDomains

2. Gestion des secrets

• Jamais de secret dans le code source (clés API, mots de passe, tokens)
• Utiliser des variables d'environnement ou un gestionnaire de secrets (Vault, AWS Secrets Manager)
• Fichiers .env dans .gitignore
• Rotation régulière des secrets (tous les 90 jours minimum)
• Révoquer immédiatement tout secret exposé accidentellement

3. Authentification et contrôle d'accès

• Authentification multi-facteurs (MFA) pour les accès administrateurs
• Mots de passe : 12 caractères minimum, pas de contrainte de complexité artificielle
• Verrouillage temporaire après 5 tentatives échouées
• Sessions : durée limitée, invalidation côté serveur à la déconnexion
• Principe du moindre privilège : chaque composant n'a accès qu'à ce dont il a besoin

4. Headers de sécurité HTTP

• Content-Security-Policy : restreindre les sources de scripts, styles, images
• X-Content-Type-Options: nosniff
• X-Frame-Options: DENY (ou SAMEORIGIN si iframe nécessaire)
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy : désactiver les API non utilisées (camera, microphone, geolocation)

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin

5. Validation des entrées

• Valider toutes les entrées côté serveur (ne jamais faire confiance au client)
• Utiliser des schémas de validation (Zod, Joi, Pydantic)
• Échapper les sorties HTML pour prévenir les XSS
• Requêtes SQL paramétrées (pas de concaténation de chaînes)
• Limiter la taille des requêtes (body, upload, query strings)

6. Gestion des dépendances

• Auditer les dépendances régulièrement (npm audit, pip audit, trivy)
• Mettre à jour les dépendances avec des vulnérabilités connues (CVE)
• Utiliser un fichier de lock (package-lock.json, poetry.lock)
• Minimiser le nombre de dépendances directes
• Scanner les images Docker (trivy image)

7. Journalisation et monitoring

• Logger les événements de sécurité : authentifications, erreurs d'accès, modifications critiques
• Jamais de données sensibles dans les logs (mots de passe, tokens, données personnelles)
• Horodatage UTC sur tous les logs
• Centraliser les logs (ELK, Loki, CloudWatch)
• Alertes sur les événements anormaux (pics d'erreurs 401/403, tentatives brute force)

8. Protection des API

• Authentification sur tous les endpoints (sauf santé/métadonnées publiques)
• Rate limiting pour prévenir les abus
• Pagination obligatoire sur les endpoints de liste
• Ne pas exposer de détails techniques dans les messages d'erreur en production
• Versionner les API (/v1/, /v2/)

9. Sécurité des conteneurs et du déploiement

• Images Docker basées sur des images minimales (Alpine, distroless)
• Ne pas exécuter les processus en root dans les conteneurs
• Scanner les images avant déploiement
• Séparer les environnements (dev, staging, prod) avec des accès distincts
• Health checks et readiness probes configurés

10. Sécurité du poste de développement

• Chiffrement du disque dur activé (FileVault, LUKS)
• Verrouillage automatique après 5 minutes d'inactivité
• VPN pour les accès aux ressources internes
• Pas de compte administrateur pour l'usage quotidien

11. Sauvegarde et continuité

• Sauvegardes régulières des données et configurations critiques
• Tester la restauration des sauvegardes périodiquement
• Documenter la procédure de reprise d'activité

12. Gestion des incidents

• Procédure de signalement des incidents de sécurité documentée
• Contact CERT ministériel identifié
• Capacité à révoquer des accès et rotater des secrets en urgence

---

Format du rapport d'audit

## Audit Sécurité ANSSI — Rapport de conformité

**Date :** AAAA-MM-JJ
**Périmètre audité :** [description du projet / service / composant]
**Résultat global :** X/Y règles conformes (Z% conforme)
(X conformes, X non conformes, X partielles, X non applicables)

---

### Tableau de synthèse

| # | Domaine | Statut | Détail |
|---|---------|--------|--------|
| 1 | TLS / HTTPS | OK / KO / Partiel / NA | résumé en une ligne |
| 2 | Gestion des secrets | OK / KO / Partiel / NA | résumé en une ligne |
| 3 | Authentification et contrôle d'accès | OK / KO / Partiel / NA | résumé en une ligne |
| 4 | Headers de sécurité HTTP | OK / KO / Partiel / NA | résumé en une ligne |
| 5 | Validation des entrées | OK / KO / Partiel / NA | résumé en une ligne |
| 6 | Gestion des dépendances | OK / KO / Partiel / NA | résumé en une ligne |
| 7 | Journalisation et monitoring | OK / KO / Partiel / NA | résumé en une ligne |
| 8 | Protection des API | OK / KO / Partiel / NA | résumé en une ligne |
| 9 | Sécurité des conteneurs et du déploiement | OK / KO / Partiel / NA | résumé en une ligne |
| 10 | Sécurité du poste de développement | OK / KO / Partiel / NA | résumé en une ligne |
| 11 | Sauvegarde et continuité | OK / KO / Partiel / NA | résumé en une ligne |
| 12 | Gestion des incidents | OK / KO / Partiel / NA | résumé en une ligne |

---

### Non-conformités détectées

**[KO] Domaine {#} — {Nom du domaine}**
- **Règle concernée :** description de la règle non respectée
- **Constat :** ce qui a été observé dans le code / la configuration
- **Risque :** impact sécurité si non corrigé (ex : fuite de données, compromission)
- **Correction :** action concrète à mener
- **Priorité :** 🔴 Critique / 🟠 Élevée / 🟡 Modérée

### Conformités partielles

**[Partiel] Domaine {#} — {Nom du domaine}**
- **Règles respectées :** liste des points OK
- **Règles manquantes :** liste des points restants à traiter
- **Correction :** actions à mener pour atteindre la conformité complète

---

### Domaines conformes

{liste compacte des domaines OK}

### Domaines non applicables

- **Domaine {#}** — {justification courte}

Grille de priorités

Priorité	Définition	Exemples
🔴 Critique	Vulnérabilité exploitable, risque immédiat de compromission	Secret dans le code source, pas de TLS, injection SQL possible
🟠 Élevée	Faiblesse significative, exploitation possible sous conditions	Headers de sécurité manquants, pas de rate limiting, pas de MFA admin
🟡 Modérée	Bonne pratique non respectée, risque limité	Logs non centralisés, pas de scan d'images Docker, rotation des secrets non planifiée

Export du rapport

Après avoir produit le rapport, toujours :

1. Créer le dossier audits/ à la racine du projet s'il n'existe pas
2. Écrire le rapport complet dans audits/securite-anssi-AAAA-MM-JJ.md (date du jour, format ISO)
3. Afficher également le rapport dans la conversation

Si un fichier du même nom existe déjà, ajouter un suffixe incrémental : securite-anssi-2026-03-26-2.md.

Exemple : audits/securite-anssi-2026-03-26.md