Liste de contrôle de sécurité des applications web

Une liste de contrôle pratique et indépendante de tout fournisseur, destinée à toute personne qui publie une application web, qu'elle ait écrit chaque ligne à la main ou qu'elle l'ait construite en la confiant à une IA (le « vibe coding »). L'IA écrit du code qui passe le scénario nominal et livre pourtant de vraies failles, donc une fonctionnalité qui marche ne prouve rien quant à sa sécurité. Cette liste contient ce qu'il faut réellement vérifier avant et après la mise en production.

Elle est organisée par catégorie. Commencez où vous voulez, ou parcourez-les dans l'ordre. Chaque page présente des contrôles concrets : quoi tester, pourquoi c'est important et comment corriger.

Comment l'utiliser

• Traitez chaque point comme un test, pas comme une lecture. Tentez l'attaque, puis confirmez que la correction fonctionne.
• Testez avec des données invalides et en tant que mauvais utilisateur, pas seulement dans le parcours normal.
• Une fois le code correct en apparence, lancez un scan sur l'URL déployée pour détecter tout ce qui a régressé entre deux itérations.

Catégories

• Authentification et sessions : comment les personnes prouvent leur identité, et comment les garder connectées sans laisser voler le jeton.
• Autorisation et contrôle d'accès : s'assurer qu'un utilisateur connecté ne peut pas lire ou modifier des données qui ne lui appartiennent pas (IDOR, multi-locataires).
• Validation des entrées et injection : injection SQL, XSS, SSRF, désérialisation non sécurisée et envoi de fichiers.
• API et requêtes : CSRF, CORS, mass assignment et attaques sur la forme des requêtes.
• Secrets et protection des données : clés, chiffrement au repos et en transit, données personnelles et droits sur les données.
• Disponibilité et abus : limitation de débit, déni de service et consommation de ressources incontrôlée.
• Infrastructure et déploiement : ports et pare-feu, conteneurs, panneaux d'administration, en-têtes de sécurité et TLS.
• Dépendances, journalisation et processus : chaîne d'approvisionnement, secrets dans git, journalisation, tests indépendants.

La version courte

Si vous n'avez qu'une heure, vérifiez d'abord ces cinq points. Ce sont les plus fréquents et les plus dommageables lors des audits réels :

1. Contrôle d'accès défaillant. Connectez-vous en tant qu'utilisateur A, puis demandez l'objet de l'utilisateur B par son identifiant. Si l'objet est renvoyé, vous avez une faille. Voir autorisation.
2. Secrets côté client ou dans git. Recherchez les clés dans le bundle du navigateur et dans le dépôt. Tout ce qui a été commis est compromis. Voir secrets.
3. Aucune limitation de débit sur la connexion. Sans elle, les attaques par force brute sont triviales. Voir disponibilité.
4. Protection CSRF ou CSRF de connexion absente. Voir API et requêtes.
5. Ports ouverts au-delà du pare-feu. Les conteneurs publient souvent des ports en contournant le pare-feu. Voir infrastructure.

Cette liste est publiée par l'équipe Arc OS. Nous appliquons ces mêmes exigences à notre propre produit ; vous êtes libre de l'utiliser pour le vôtre. C'est une base de départ, pas une certification, et elle ne remplace pas un test d'intrusion indépendant.