Skip to content

Latest commit

 

History

History
48 lines (40 loc) · 4.75 KB

checklist.md

File metadata and controls

48 lines (40 loc) · 4.75 KB

Checklist(s)

Cette checklist n'est pas exhaustive mais permet de se prémunir déjà contre de nombreuses failles

Checklist sécurité pour les Développeur·ses web

  • Tous les inputs sont vérifiés (validés, filtrés) avant d'être utilisés []
  • Tous les inputs sont échappés de manière appropriée au contexte (HTML, SQL, etc.) []
  • Tout test de validité fait côté client est également fait côté serveur []
  • Aucune requête SQL n'est construite par concaténation avec des inputs mais utilise des requêtes préparées et paramétrées []
  • Aucune donnée sensible (nom de serveur, nom d'utilisateur, mot de passe, token, etc.) n'est présente dans le code []
  • Aucune donnée sensible n'est publiée sur un dépôt et n'est présente dans l'historique des commits []
  • Aucune donnée sensible n'est présente dans le web root folder (dossier hébergeant le site web) []
  • Les messages d'erreur ne donnent pas trop d'informations à un agent malveillant []
  • Les exceptions sont toutes interceptées []
  • Aucun composant ne se connecte à un serveur SQL en utilisant le compte administrateur []
  • L'utilisateur SQL utilisé par l'application dispose des privilèges minimum (base de données, tables, instruction SQL) []
  • L'octroi de privilège pour réaliser une opération est justifié, il n'y a pas d'alternative []
  • Une clef secrète de chiffrement n'est pas accessible
  • Les solutions de chiffrement sont basées sur des bibliothèques vendor valides et non sur du code fait maison []
  • Aucune stacktrace n'est fournie à des utilisateur inconnus []
  • La génération de nombre aléatoire (par exemple pour la génération de mot de passe) doit générer des nombres équitablement distribués et être imprévisible. Voir le tableau des fonctions à éviter et à utiliser pour chaque environnement []
  • Toute opération nécessitant les privilèges est journalisée (ce qui inclue les tentatives d'authentification réussies et échouées) []
  • Une nouvelle demande d'authentification (par exemple délivrance d'un nouveau token) est émise lorsqu'une action demande un privilège plus élevé []
  • Tout usage de secret est journalisé (par qui, quand, pourquoi) []
  • Si des données sensibles sont échangées entre le serveur et le client, la communication utilise le protocole TLS (SSL) []
  • Tout formulaire de soumission de données sur une URL protégée par authentification utilise un token CSRF unique et imprévisible []
  • Les cookies sensibles (ex : identifiant de session) sont déposés par défaut avec les attributs SameSite=Strict, HttpOnly et Secure []
  • Aucun input n'est donné directement à une fonction de l'API du système de fichiers []
  • Les valeurs des attributs des balises HTML sont encodés et placés entre quotes []
  • Aucune donnée sensible n'est conservée en claire en base de données []
  • Le système utilise des algorithmes de hashage robustes comme Argon2, scrypt ou bcrypt []
  • Le système utilise des algorithmes de chiffrement robustes comme AES 256 bits (128 minimum) []
  • Le système utilise un salt (dynamique ou statique) pour ses opérations de hashage []
  • Le système n'utilise pas de générateur aléatoire non sécurisé (ex: rand() en C, Math.random() en Java, random() en Python, etc.) []
  • Etc.

Références utiles