Audit de sécurité avant mise en production : checklist pragmatique

Avant une mise en production, la question n’est pas “sommes-nous parfaits”, mais “quels risques acceptons-nous et lesquels devons-nous réduire maintenant”. Un audit pré-prod sert à éviter les incidents prévisibles : comptes compromis, fuite de données, fraude, indisponibilité, ou erreurs d’autorisation.

Cette checklist est conçue pour une équipe produit/engineering. Elle est pragmatique : vous pouvez l’utiliser en interne, ou comme base de cadrage avec un prestataire.

Objectif et périmètre (avant de vérifier quoi que ce soit)

Clarifier l’objectif

Choisissez un objectif principal :

• réduire les risques sur les parcours critiques (paiement, accès admin, exports)
• valider une refonte (auth, API, IAM, multi-tenant)
• sécuriser une intégration à risque (SSO, webhooks, PSP)
• répondre à une exigence client/assureur (rapport, preuves, traçabilité)

Un audit “général” sans objectif produit souvent une liste longue et peu priorisée.

Définir le périmètre

Documentez :

• URL(s) et domaines concernés
• API (REST/GraphQL), webhooks, endpoints sensibles
• back-office et rôles
• composants tiers (paiement, anti-fraude, analytics, support)
• environnements (staging, preprod, prod)

Si vous avez une application web, commencez par : https://obveron.com/pentest-application-web

Checklist : authentification et sessions

Identité et parcours d’accès

• login : erreurs non verboses, protection brute force, rate limits
• reset password : token à durée de vie courte, invalidation après usage
• MFA : support, fallback, récupération sécurisée
• SSO : validation des audiences, signatures, replay, gestion des logout

Sessions

• cookies : HttpOnly, Secure, SameSite cohérent, scope de domaine minimal
• rotation de session après login et après actions sensibles
• invalidation : logout réel, révocation côté serveur si applicable
• stockage de tokens : éviter localStorage pour les tokens longue durée

Contrôles de base

• pas d’énumération d’utilisateurs via messages d’erreur
• pas de secrets dans les URLs (logs, referrers)
• pas de endpoints “debug” exposés

Checklist : autorisation (RBAC/ABAC) et multi-tenant

Les incidents sérieux viennent souvent d’un contrôle d’autorisation manquant, pas d’un bug “technique”.

• règles d’accès documentées par rôle (qui peut lire, modifier, supprimer)
• contrôle côté serveur systématique (pas seulement UI)
• vérification des objets : accès à un projet/tenant uniquement si appartenance
• actions sensibles : double validation (ex: suppression, virement, export)
• endpoints admin séparés et protégés

Tests utiles :

• changer des IDs dans l’URL/les payloads (IDOR)
• rejouer une requête avec un rôle plus faible
• modifier un paramètre de tenant/organisation

Checklist : API (REST/GraphQL) et validation des entrées

Validation

• validation stricte (types, formats, tailles, listes d’énumération)
• erreurs de validation non verboses côté client
• normalisation cohérente (trim, case, unicode)

Auth et rate limiting

• auth obligatoire sur endpoints sensibles
• rate limiting par IP et par compte sur endpoints d’auth et de paiement
• quotas et protections contre abus (exports, recherches, invitations)

GraphQL (si applicable)

• introspection désactivée ou contrôlée selon contexte
• limitation de profondeur/complexité
• contrôle d’autorisation sur chaque resolver

Pour cadrer un audit API dédié : https://obveron.com/audit-api

Checklist : fichiers, uploads et contenu riche

• types de fichiers autorisés et vérifiés côté serveur
• antivirus ou sandboxing si besoin (selon risque)
• stockage : URLs signées, TTL, pas d’objets publics par défaut
• prévention XSS : sanitation des HTML, CSP, encodage côté template
• previews/conversions : traitements isolés, timeouts, taille max

Checklist : configuration, headers et surface d’attaque

Headers de sécurité

• CSP adaptée (pas de “unsafe-inline” par défaut, exceptions justifiées)
• HSTS (inclure subdomains si maîtrisés)
• X-Content-Type-Options, Referrer-Policy, Permissions-Policy

Exposition

• ports et services exposés minimaux
• admin panels non exposés, ou protégés (IP allowlist, SSO)
• pages d’erreur sans stack traces

Dépendances et supply chain

• dépendances à jour sur les packages critiques
• suppression des packages inutiles
• scans SCA intégrés au CI si possible

Checklist : secrets, logs et observabilité

Secrets

• aucun secret en repo, ni en variables publiques
• rotation possible (process documented)
• moindre privilège (principle of least privilege)

Logs

• pas de données sensibles (tokens, secrets, PII inutiles)
• corrélation (request id)
• accès aux logs restreint

Monitoring

• alertes sur erreurs 5xx, pics de 401/403, latence, timeouts
• détection d’abus (brute force, scraping, anomalies)

Checklist : incident response et retest

• procédure d’incident courte (qui fait quoi, comment isoler)
• plan de patch (délai de correction par sévérité)
• retest cadré sur les failles corrigées

Checklists “décision” (pour les CTO/Head of Eng)

Avant go-live, vous voulez pouvoir répondre clairement :

• quels sont les 3 risques majeurs et leur impact ?
• quelles mesures réduisent le risque rapidement ?
• qu’est-ce qui reste acceptable et pourquoi ?
• comment validons-nous les corrections ?

Liens internes utiles

• Audit de sécurité web : https://obveron.com/audit-securite
• Pentest application web : https://obveron.com/pentest-application-web
• Audit API : https://obveron.com/audit-api
• Échange 15 minutes : https://obveron.com/book-a-call

Conclusion

Une checklist pré-prod ne remplace pas un test d’intrusion, mais elle réduit fortement les risques “évidents” et accélère un audit externe. Si vous voulez cadrer un audit pré-prod et sécuriser les parcours critiques, vous pouvez réserver un échange : https://obveron.com/book-a-call