Une liste de contrôle des exigences de sécurité des applications web inscrit la sécurité dans le périmètre contractuel : chaque exigence se voit attribuer un responsable, un contrôle de réussite ou d’échec, les preuves requises et un délai de correction. Placez cette annexe à côté de la liste des fonctionnalités avant le début du développement.
Le contrôle d’accès défaillant reste en tête de l’OWASP Top 10:2025. Une analyse automatisée peut néanmoins passer à côté de la règle métier qui détermine si un client peut ouvrir la facture d’un autre.
Les acheteurs savent en général quelles données doivent être protégées, mais le contrat décrit souvent les écrans bien plus précisément que les tests de sécurité. Ce guide fournit une annexe contractuelle fondée sur OWASP ASVS 5.0, avec les preuves nécessaires lors de la réception. Il attribue aussi les obligations qui se poursuivent après la remise.
- Référencez OWASP ASVS 5.0 avec sa version et son niveau. L’OWASP Top 10 explique les risques, tandis qu’ASVS fournit des exigences qui débouchent sur un résultat de réussite ou d’échec.
- Attribuez quatre champs à chaque exigence : responsable, test de réception, preuve et délai de correction.
- Testez les autorisations avec deux utilisateurs ou deux tenants. Une connexion réussie ne dit rien sur l’accès aux dossiers, exports, fichiers ou actions d’administration d’un autre client.
- Intégrez les preuves à la livraison. L’acheteur doit recevoir la matrice des exigences, les résultats des tests, les exceptions connues, les notes de déploiement et la preuve de restauration.
- Maintenez la maintenance dans le périmètre. Les correctifs de dépendances, l’assistance en cas d’incident, le transfert des identifiants et les délais de réponse prennent effet dès la mise en ligne de l’application.
Une promesse de sécurité exige un test de réception
OWASP présente son Top 10 comme un document de sensibilisation et recommande l’Application Security Verification Standard pour définir des exigences de sécurité applicative vérifiables. ASVS 5.0 compte environ 350 exigences réparties entre 17 chapitres, chacune conçue pour aboutir à une décision de réussite ou d’échec.
ASVS convient aussi à l’achat de logiciels sur mesure. L’acheteur peut fixer un niveau, sélectionner les exigences pertinentes et demander au fournisseur de prouver leur respect à l’aide de références versionnées telles que `v5.0.0-1.2.5`. Cette formulation fonctionne dans un contrat, car la référence reste valable en cas de changement de fournisseur ou de prestataire chargé des tests.
Une application réalisée par webvise en six semaines pour un service immobilier allemand combinait un parcours de collecte de données financières en 10 étapes, la génération automatisée de PDF et un tableau de bord d’administration, avec un délai de traitement inférieur à 24 heures. Ce processus soulève des questions de sécurité précises : qui peut lire un dossier, modifier son statut, générer le PDF, le télécharger et consulter l’historique d’audit ? Une ligne indiquant `authentification incluse` laisse chacune de ces décisions en suspens.
Si votre application contient ce type de processus privé, l’offre de développement d’applications sur mesure de webvise comprend l’authentification, les autorisations, la conception d’API, le CI/CD, la supervision et les tests des parcours critiques convenus. L’annexe de sécurité précise les risques que ces livrables doivent couvrir.
Choisissez un niveau ASVS avant l’estimation
ASVS comporte trois niveaux de profondeur croissante. OWASP cite un produit en phase de démarrage qui traite peu de données sensibles comme cas possible de niveau 1, tandis qu’une banque en ligne pourrait difficilement justifier un niveau inférieur au niveau 3. L’acheteur et le fournisseur choisissent le niveau selon les données et les utilisateurs de l’application, l’impact sur l’activité et les attaquants probables.
| Niveau ASVS | Cas d’usage pour l’acheteur | Instruction contractuelle |
|---|---|---|
| Niveau 1 | Produit en phase de démarrage, avec peu de données sensibles et un modèle de menace restreint | Appliquer toutes les exigences L1 pertinentes et consigner les chapitres exclus |
| Niveau 2 | SaaS B2B, portails clients, facturation, dossiers privés ou interruption notable de l’activité | Appliquer les exigences L2 pertinentes, nommer les parcours sensibles et exiger des preuves traçables |
| Niveau 3 | Banque, santé, administration critique ou systèmes dont la compromission pourrait causer de graves dommages | Définir le périmètre L3 avec un spécialiste de la sécurité et prévoir une vérification indépendante |
Ce tableau sert de guide des risques pour l’acheteur, car OWASP laisse à chaque organisation le choix du niveau final. Adaptez aussi les chapitres. Une application sans OAuth, WebSockets, GraphQL ni interface web peut exclure les sections correspondantes, à condition d’inscrire ces exclusions dans l’annexe contractuelle.
Inscrivez la version exacte d’ASVS dans le contrat. `ASVS Level 2` peut changer de portée après une version majeure, tandis que `OWASP ASVS v5.0.0, selected L2 requirements in Appendix A` offre aux deux parties une cible de test stable.
Reprenez l’annexe de sécurité en 12 exigences
Utilisez le tableau suivant comme annexe de sécurité d’un cahier des charges ou d’un énoncé des travaux. Chaque ligne exige un responsable nommé, le test final, la preuve remise à l’acheteur et le délai accordé pour corriger un échec.
| Domaine | Exigence contractuelle | Preuve de réception |
|---|---|---|
| 1. Cartographie des risques et des données | Recenser les données sensibles, les acteurs, les systèmes, les frontières de confiance, les durées de conservation et les usages interdits | Note approuvée sur les flux de données et registre des risques |
| 2. Authentification et sessions | Définir les règles de connexion, de réinitialisation, de déconnexion, d’expiration des sessions, de MFA et de récupération des comptes | Tests automatisés des parcours et relevé de configuration |
| 3. Autorisations | Définir chaque rôle, ressource protégée, action autorisée et frontière entre tenants | Matrice des accès, avec tests horizontaux, verticaux et entre tenants |
| 4. Traitement des entrées et des fichiers | Valider sur le serveur toutes les entrées provenant du client, des API, des webhooks, des requêtes et des téléversements | Tests des types non valides, des limites de taille, des entrées mal formées et des fichiers dangereux |
| 5. Secrets et cryptographie | Conserver les secrets hors du code source et définir les règles de chiffrement, de rotation et d’accès | Inventaire des secrets, configuration du stockage et procédure de rotation |
| 6. Dépendances et chaîne d’approvisionnement | Suivre les dépendances directes et transitives, les analyser et fixer les délais d’application des correctifs | Lockfile, inventaire des dépendances, rapport d’analyse et registre des exceptions |
| 7. Services externes | Définir pour chaque intégration l’authentification, les autorisations, les délais d’attente, les nouvelles tentatives, la validation et le comportement en cas d’échec | Tests d’intégration et liste des propriétaires des identifiants |
| 8. Journalisation et alertes | Journaliser les événements de sécurité sans données sensibles et adresser les alertes appelant une action à un responsable nommé | Catalogue des événements, paramètre de conservation et test de déclenchement d’une alerte |
| 9. Comportement en cas d’erreur | Définir un comportement sûr pour les requêtes échouées, les écritures partielles, les services indisponibles et les états inattendus | Tests des chemins d’échec démontrant un retour arrière ou un arrêt sûr |
| 10. Sauvegarde, restauration et suppression | Fixer la fréquence des sauvegardes, l’objectif de restauration, la conservation, l’export et les règles de suppression vérifiée | Résultat du test de restauration et test de suppression |
| 11. Pipeline de compilation et de mise en production | Protéger les branches, restreindre l’accès à la production, analyser les changements et consigner les déploiements | Configuration CI/CD, liste des accès et historique des versions |
| 12. Remise et correction | Transférer le code source, l’infrastructure, les identifiants, les problèmes connus, les objectifs de réponse et les obligations de maintenance | Liste de remise signée et tableau des corrections selon la gravité |
La ligne consacrée aux dépendances a un poids réel. Le 14 septembre 2025, le ver Shai-Hulud a pénétré l’écosystème npm par des comptes de mainteneurs compromis et des scripts post-installation malveillants. OWASP recense plus de 500 versions de paquets touchées avant que npm n’interrompe sa propagation.
Un fournisseur ne peut pas garantir chaque paquet pour toujours. Le contrat peut exiger un inventaire lors de la livraison, des contrôles automatisés pendant le développement, des exceptions écrites et un délai de réponse défini pour toute nouvelle faille critique. Ces dispositions attribuent clairement la responsabilité du risque lié au code tiers.
Ajoutez cette annexe à la partie technique du brief destiné à une agence web avant de demander une estimation. Le fournisseur pourra alors chiffrer les preuves requises et signaler les contrôles qui nécessitent un spécialiste indépendant de la sécurité.
Reformulez chaque ligne en critère de réussite ou d’échec
ASVS limite ses exigences à des résultats vérifiables. Appliquez la même règle au contrat : une autre personne qualifiée doit obtenir le même résultat après avoir lu le critère et exécuté le test indiqué.
| Exigence vague | Critère de réception avec réussite ou échec | Preuve |
|---|---|---|
| Utiliser une connexion sécurisée | Toute requête avec une session expirée, révoquée ou absente renvoie 401 ; cinq tentatives infructueuses déclenchent le contrôle convenu | Résultats des tests automatisés d’authentification |
| Préserver la confidentialité des données clients | L’utilisateur B ne peut ni lire, ni modifier, ni supprimer, ni exporter les dossiers créés dans le tenant de l’utilisateur A | Tests de requêtes sur deux tenants renvoyant 403 ou 404 |
| Protéger les fonctions d’administration | Chaque route d’administration rejette côté serveur les requêtes anonymes et celles des utilisateurs standards | Matrice des rôles et résultats des tests au niveau des routes |
| Valider les téléversements | Le serveur rejette les types interdits, les données MIME incohérentes, les fichiers trop volumineux et les noms de fichiers dangereux | Jeu de tests de téléversement et inspection des fichiers stockés |
| Surveiller les attaques | Une rafale test de connexions échouées crée une alerte destinée au responsable nommé dans le délai convenu | Événement, alerte et accusé de réception horodatés |
| Sécuriser les dépendances | La livraison ne contient aucune faille critique non résolue en dehors du registre des exceptions signé | Rapport daté sur les dépendances et exceptions approuvées |
Next.js rend ce principe concret. Son guide sur la sécurité des données, mis à jour le 27 février 2026, précise que chaque Server Action exportée crée un endpoint HTTP public et nécessite les mêmes contrôles d’autorisation qu’une API. Utilisez un test automatisé de requête comme preuve. Masquer un bouton prouve uniquement l’état de l’interface.
Les autorisations exigent plusieurs tests, car le contrôle de connexion établit uniquement l’identité. Répétez les actions protégées avec un autre utilisateur de même rôle, un rôle inférieur, un autre tenant, une session expirée et sans session. Appliquez cette matrice aux lectures, écritures, exports, fichiers, tâches en arrière-plan et outils d’administration.
Exigez les preuves avant la réception
L’OWASP Secure Software Contract Annex nomme l’ensemble des preuves finales dossier de certification. Selon OWASP, une courte évaluation des risques, quelques pages d’exigences, une note de conception de la sécurité, un plan de test et les résultats peuvent suffire à certains projets.
- Note sur les risques et les flux de données : acteurs, champs sensibles, systèmes, frontières de confiance, conservation et responsable ayant approuvé chaque décision.
- Matrice d’exigences versionnée : identifiants ASVS 5.0 sélectionnés, applicabilité, responsable, statut, référence du test et éventuelle exception.
- Matrice des autorisations : acteur, ressource, action, résultat attendu et résultat du test automatisé pour les parcours protégés.
- Relevé des dépendances : inventaire direct et transitif, analyse datée, failles non résolues et exceptions signées.
- Note de déploiement : accès à la production, emplacement des secrets, paramètres de sécurité, domaines, services externes et procédure de retour arrière.
- Preuve de restauration : un test de restauration achevé, avec sa date, sa durée, son résultat et toute lacune constatée.
- Preuve de supervision : un événement de sécurité déclenché, l’alerte créée, son destinataire et l’heure de réception.
Les scanners automatisés ne couvrent qu’une partie de ce dossier. OWASP avertit que le Top 10 ne peut pas servir de couverture complète à un outil, car la conception non sécurisée, les autorisations métier et l’efficacité des alertes exigent un examen ou une vérification en conditions réelles. Faites appel à un spécialiste pour des tests indépendants lorsque l’application traite des données réglementées, des mouvements de fonds, des dossiers médicaux ou des fonctions administratives à fort impact.
La clause de réception doit préciser qui examine le dossier et quelles failles bloquent la livraison. Une règle applicable consiste à bloquer la réception en présence de failles critiques ou graves non résolues, tout en autorisant une exception signée à reporter une faille de moindre gravité avec un responsable et une échéance. Un juriste qualifié doit examiner la formulation finale du contrat au regard du droit applicable.
Définissez les obligations de sécurité après la remise
La livraison clôt la phase de développement et ouvre la phase d’exploitation. De nouvelles failles dans les dépendances, des certificats expirés, des identifiants divulgués, des changements de personnel, des abus et des intégrations défaillantes surviennent selon leur propre calendrier. Le contrat doit attribuer un responsable à chacun.
| Clause après la remise | Décision à consigner |
|---|---|
| Canal de signalement | Où envoyer les signalements de sécurité, qui les reçoit et comment leur réception est confirmée |
| Gravité et réponse | Comment définir la gravité et l’objectif de réponse ou de correction pour chaque niveau |
| Maintenance des dépendances | Qui examine les alertes, applique les mises à jour, teste la compatibilité et déploie les correctifs |
| Assistance en cas d’incident | Disponibilité, tarifs, conservation des preuves, communication et pouvoir de décision |
| Propriété des identifiants | Quels comptes appartiennent à l’acheteur et quand effectuer la rotation des clés, domaines et jetons |
| Fin du service | Export du code source, transfert de l’infrastructure, restitution des données, suppression vérifiée et retrait des accès |
La propriété du code source n’est utile que si l’acheteur peut aussi exploiter l’application. Exigez le dépôt, la configuration CI/CD, les paramètres de l’infrastructure, l’inventaire des environnements, l’historique des migrations de la base de données, l’accès à la supervision et un processus de déploiement testé. webvise inclut dans la livraison des applications sur mesure la propriété du code source, la documentation des parcours critiques, le CI/CD, la supervision et une infrastructure opérationnelle.
webvise peut transformer cette liste de contrôle en annexe de sécurité délimitée pour une nouvelle application sur mesure, avec le niveau ASVS pertinent, les preuves et les conditions de remise intégrés au projet. Envoyez à webvise le processus et les types de données avant d’arrêter l’estimation.
Les pratiques de webvise sont alignées sur les normes ISO 27001 et ISO 42001.