BlogCybersécurité
La sécurité d’un logiciel métier se vérifie domaine par domaine : authentification, autorisations, traitement des saisies, secrets, dépendances, protection des données, journaux, pipeline de livraison et API. Cette checklist reprend les contrôles essentiels, alignés sur l’OWASP Top 10 et l’OWASP ASVS, avec pour chacun une façon concrète de le vérifier.
Sommaire de l’article
Comment utiliser cette checklist
Elle s’applique aux applications web, aux API et aux outils internes, ceux qu’on croit à l’abri parce qu’ils ne sont « pas publics », alors qu’un compte compromis ou un poste infecté suffit à les exposer. Parcourez-la avec l’équipe qui développe et celle qui exploite l’application : chaque point doit recevoir une réponse claire (fait, partiel, non fait) et, pour les écarts, un responsable et une échéance.
Deux référentiels ouverts structurent l’exercice : l’OWASP Top 10, qui décrit les catégories de risques les plus répandues dans les applications web, et l’OWASP ASVS (Application Security Verification Standard), qui détaille des exigences vérifiables par niveau d’exigence. Cette checklist ne remplace ni l’un ni l’autre, et cocher toutes les cases ne garantit pas l’absence de faille : c’est une base de revue, pas une certification.
Important : tout test actif (scan de vulnérabilités, test d’intrusion, tentative de contournement) doit être réalisé uniquement sur des systèmes dont vous êtes responsable, dans un périmètre écrit et autorisé, de préférence sur un environnement de test.
Authentification et sessions
- Authentification multifacteur (MFA) au minimum pour les comptes administrateurs et les accès distants, idéalement pour tous.
- Mots de passe stockés avec un algorithme de hachage moderne et salé (Argon2id, scrypt ou bcrypt), jamais en clair ni avec un simple MD5 ou SHA-1.
- Protection contre les tentatives répétées : limitation, temporisation ou verrouillage progressif, sans permettre de deviner quels comptes existent.
- Sessions : identifiant régénéré à la connexion, expiration après inactivité et durée maximale, déconnexion qui invalide réellement la session côté serveur, cookies marqués Secure, HttpOnly et SameSite.
- Réinitialisation de mot de passe par lien à usage unique et à durée limitée.
Autorisations et contrôle d’accès
- Chaque contrôle d’accès est fait côté serveur, à chaque requête. Masquer un bouton dans l’interface ne protège rien.
- Moindre privilège : chaque utilisateur, compte de service et accès à la base de données n’a que les droits nécessaires.
- Rôles définis (contrôle d’accès basé sur les rôles) et documentés, revus quand une personne change de poste ou quitte l’entreprise.
- Références directes non sécurisées (IDOR) : changer un identifiant dans l’URL ou la requête (/factures/1042 en /factures/1043) ne doit jamais donner accès aux données d’un autre client ou d’une autre filiale.
- Refus par défaut : une route ou une action sans règle explicite est interdite.
Traitement des saisies et des fichiers
- Validation côté serveur de toutes les entrées : type, longueur, format, valeurs autorisées. La validation dans le navigateur n’est qu’un confort pour l’utilisateur.
- Requêtes paramétrées ou ORM pour tous les accès à la base de données ; aucune concaténation de saisie utilisateur dans une requête SQL ou une commande système.
- Encodage des sorties selon le contexte (HTML, attribut, JavaScript, URL) pour éviter le cross-site scripting ; une politique de sécurité du contenu (CSP) en renfort.
- Téléversement de fichiers : liste de types autorisés vérifiée sur le contenu et pas seulement l’extension, taille maximale, renommage, stockage hors de la racine web, jamais exécutables.
Secrets, configuration et dépendances
Secrets et configuration
- Aucun secret dans le code ni dans l’historique Git : mots de passe, clés d’API, jetons et certificats sont injectés par l’environnement ou un gestionnaire de secrets.
- Secrets différents par environnement (développement, recette, production) et rotation planifiée, immédiate en cas de départ ou de fuite suspectée.
- Configuration de production durcie : mode debug désactivé, messages d’erreur génériques, comptes et pages d’exemple supprimés, en-têtes de sécurité HTTP activés.
Dépendances
- Inventaire des bibliothèques et composants utilisés, avec leurs versions (fichiers de verrouillage versionnés, idéalement une nomenclature logicielle).
- Mises à jour régulières, et rapides pour les correctifs de sécurité.
- Analyse automatique des vulnérabilités connues à chaque build et sur la branche principale.
- Retrait des dépendances inutilisées ou abandonnées par leurs mainteneurs.
Protection des données, journaux et supervision
Données
- TLS partout, y compris entre services internes quand ils traversent un réseau partagé.
- Chiffrement au repos là où c’est pertinent : bases de données, sauvegardes, stockage de documents sensibles.
- Minimisation : ne collecter et ne conserver que les données nécessaires, avec une durée de conservation définie.
- Sauvegardes testées : une restauration réelle, régulière, est la seule preuve qu’une sauvegarde fonctionne.
Journaux et alertes
- Journalisation des événements de sécurité : connexions réussies et échouées, changements de droits, accès refusés, actions d’administration, exports de données.
- Aucune donnée sensible dans les journaux : ni mots de passe, ni jetons, ni numéros de carte, ni contenu personnel inutile.
- Journaux centralisés, horodatés, protégés contre la modification, avec des alertes sur les comportements anormaux (pics d’échecs de connexion, erreurs d’autorisation répétées).
Pipeline de livraison et API
Pipeline sécurisé
- Revue de code obligatoire avant fusion sur la branche principale, branche protégée.
- Analyse statique (SAST) et analyse des dépendances intégrées à la CI ; un échec bloque la livraison selon des règles convenues.
- Analyse des images de conteneurs et images de base minimales, mises à jour régulièrement.
- Environnements séparés : pas de données de production réelles en développement sans anonymisation, accès à la production limité et tracé.
API
- Authentification sur chaque point d’accès (jetons à durée limitée, clés révocables) et vérification des autorisations objet par objet.
- Limitation de débit par client et par point d’accès pour freiner les abus et l’énumération.
- Validation par schéma des requêtes et des réponses : refus des champs inattendus, pour éviter qu’un client modifie un attribut qu’il ne devrait pas voir (assignation de masse).
- Inventaire des API exposées, y compris les anciennes versions qu’on oublie de retirer.
Si vos applications échangent avec d’autres systèmes, ces contrôles font partie de la conception de l’intégration : voir notre service API et intégration de systèmes. Les assistants et agents IA connectés à vos outils ajoutent leurs propres risques, détaillés dans sécuriser un agent IA : permissions, validation et injection.
Préparation aux incidents
- Contacts et rôlesQui décide, qui intervient techniquement, qui communique, y compris en dehors des heures ouvrées.
- Procédures écritesRévoquer un compte ou un secret, isoler un serveur, mettre l’application en maintenance, restaurer une sauvegarde.
- Conservation des preuvesJournaux conservés assez longtemps et hors de portée d’un attaquant pour comprendre ce qui s’est passé.
- Obligations de notificationIdentifier à l’avance qui prévenir (clients, autorité de protection des données, partenaires) selon votre situation contractuelle et réglementaire.
- Retour d’expérienceAprès chaque incident ou exercice, corriger la cause et mettre à jour cette checklist.
Récapitulatif : contrôle, pourquoi, comment vérifier
| Contrôle | Pourquoi | Comment vérifier |
|---|---|---|
| MFA sur les comptes à privilèges | Un mot de passe volé ne suffit plus à prendre le contrôle. | Lister les comptes administrateurs et vérifier que chacun a un second facteur actif. |
| Hachage moderne des mots de passe | Une fuite de base ne révèle pas directement les mots de passe. | Lire le code d’inscription et le format des empreintes stockées. |
| Contrôle d’accès côté serveur | Empêche l’accès aux données d’autrui (IDOR) en modifiant une requête. | Avec deux comptes de test, rejouer les requêtes de l’un avec la session de l’autre. |
| Requêtes paramétrées | Bloque l’injection SQL. | Revue de code et analyse statique ciblant les requêtes construites par concaténation. |
| Aucun secret dans le dépôt | Un dépôt partagé ou divulgué n’ouvre pas la production. | Outil de détection de secrets sur le code et l’historique Git. |
| Dépendances à jour et analysées | Les vulnérabilités connues sont les plus exploitées. | Rapport d’analyse des dépendances dans la CI, sans alerte critique ouverte. |
| Sauvegardes restaurables | Permet de repartir après une erreur ou un rançongiciel. | Restauration complète sur un environnement de test, avec date et résultat consignés. |
| Journaux de sécurité sans données sensibles | Permet d’enquêter sans créer une nouvelle fuite. | Provoquer des échecs de connexion et contrôler l’entrée générée. |
| Limitation de débit des API | Freine force brute, scraping et énumération. | Envoyer une rafale de requêtes sur l’environnement de test et constater les refus. |
Pour un site WordPress, plusieurs de ces points prennent une forme spécifique (extensions, comptes, mises à jour) : voir comment sécuriser un site WordPress.
Sources et références
Vous voulez passer un logiciel métier ou une API au crible de cette checklist ? Décrivez votre application et son contexte : nous définissons ensemble un périmètre de revue autorisé et les corrections prioritaires.
Présenter votre projet Cybersécurité et sécurité applicative