La sécurité doit être définie avant le premier développement
La sécurité d’un site web ne se limite pas à l’installation d’un certificat HTTPS. Elle doit être intégrée dès la conception, puis maintenue pendant toute la durée de vie du projet. Un prestataire sérieux doit commencer par identifier les données traitées, les comptes sensibles, les fonctionnalités exposées et les conséquences d’une compromission.
Le cahier des charges doit notamment préciser :
- les données collectées et leur niveau de sensibilité ;
- les rôles et droits d’accès des utilisateurs et administrateurs ;
- les exigences de disponibilité et de sauvegarde ;
- les navigateurs, appareils et environnements à prendre en charge ;
- les obligations liées au RGPD et, lorsque cela s’applique, aux référentiels de la CNIL.
Cette approche rejoint les recommandations de l’
OWASP, dont le Top 10 recense les principales vulnérabilités des applications web, comme les défauts de contrôle d’accès, les injections ou les erreurs de configuration.
Exiger un développement sécurisé et traçable
Le prestataire doit appliquer des règles de développement sécurisé, et pas seulement corriger les problèmes découverts après la mise en ligne. Le code doit notamment protéger les formulaires, filtrer les entrées, gérer correctement les erreurs et empêcher l’exécution de contenus non fiables.
Les exigences peuvent être formulées de manière vérifiable :
- validation des données côté serveur, même si un contrôle existe déjà dans le navigateur ;
- protection contre les injections SQL, les failles XSS et les requêtes intersites frauduleuses ;
- mots de passe stockés avec un algorithme de hachage adapté, jamais en clair ;
- sessions sécurisées, expiration des connexions et protection contre les tentatives répétées ;
- séparation stricte entre les environnements de développement, de test et de production ;
- journalisation des événements importants, sans enregistrer inutilement de données personnelles.
Demandez également une gestion du code source avec historique des modifications, revue de code et procédure de validation avant déploiement. Cette traçabilité permet de comprendre qui a modifié quoi, quand et pourquoi.
Contrôler les accès, les comptes et les dépendances
De nombreux incidents ne proviennent pas d’une faille spectaculaire, mais d’un compte trop puissant, d’un mot de passe réutilisé ou d’une extension obsolète. Le prestataire doit donc fournir une matrice des habilitations et appliquer le principe du moindre privilège : chaque intervenant ne dispose que des accès nécessaires à sa mission.
Il est pertinent d’imposer :
- l’authentification multifacteur pour les comptes d’administration, d’hébergement et de gestion du code ;
- des comptes nominatifs plutôt qu’un identifiant partagé entre plusieurs personnes ;
- la révocation immédiate des accès lors du départ d’un intervenant ;
- un inventaire des frameworks, extensions, bibliothèques et services tiers utilisés ;
- une procédure de veille et de correction des vulnérabilités affectant ces composants.
Un site construit avec un CMS ou des composants open source n’est pas moins sûr par nature. En revanche, il devient risqué si les mises à jour, les extensions et les accès d’administration ne sont pas suivis dans le temps.
Ne pas séparer le site de son hébergement
La sécurité applicative doit être complétée par une infrastructure correctement configurée. Le contrat doit identifier l’hébergeur, la localisation des données, les responsabilités de chacun et les mesures prévues en cas d’incident.
Le prestataire doit pouvoir documenter au minimum :
- le chiffrement des échanges avec HTTPS et le renouvellement des certificats ;
- la mise à jour du système, du serveur web et des composants techniques ;
- la limitation des services et ports accessibles depuis Internet ;
- la protection contre les attaques courantes, avec pare-feu applicatif ou mécanismes équivalents lorsque cela est justifié ;
- la surveillance des erreurs, des connexions anormales et de la disponibilité.
Les sauvegardes méritent une clause spécifique. Elles doivent être automatisées, conservées sur un emplacement distinct et régulièrement restaurées à titre de test. Une sauvegarde dont personne ne vérifie la restauration ne constitue pas une garantie suffisante.
Prévoir des tests avant et après la mise en ligne
Une recette fonctionnelle ne remplace pas un contrôle de sécurité. Avant la mise en production, le prestataire doit réaliser des tests adaptés au niveau de risque du site. Pour une application exposée, cela peut inclure une analyse automatisée, une revue de configuration, des tests de droits et, pour les projets sensibles, un audit ou un test d’intrusion réalisé par un intervenant compétent.
Le livrable ne doit pas se limiter à la mention « site sécurisé ». Demandez plutôt :
- la liste des contrôles effectués et leur périmètre ;
- les vulnérabilités détectées, leur criticité et leur état de correction ;
- les éventuelles réserves connues ;
- la date du prochain contrôle ;
- les conditions dans lesquelles un audit indépendant est autorisé.
Le référentiel de l’ANSSI constitue une base utile pour cadrer les exigences de sécurité, notamment lorsqu’un site traite des données sensibles ou constitue un service essentiel à l’activité.
Contractualiser la maintenance et la réponse aux incidents
La sécurité se dégrade rapidement si le site n’est pas maintenu. Le contrat doit préciser la durée de support, les délais de prise en compte et les engagements de correction selon la gravité de la vulnérabilité. Il doit aussi indiquer qui reçoit les alertes et qui peut prendre la décision de mettre temporairement un service hors ligne.
Une procédure d’incident doit prévoir les étapes suivantes :
- détection et qualification de l’événement ;
- confinement de la compromission ;
- préservation des journaux et éléments utiles à l’analyse ;
- restauration depuis une version saine ;
- information du client et, si nécessaire, notification aux autorités ou aux personnes concernées ;
- retour d’expérience et mesures de prévention.
Le RGPD impose au responsable de traitement de notifier certaines violations de données à la CNIL dans un délai de 72 heures après en avoir pris connaissance, lorsque les conditions prévues par le règlement sont réunies. Le prestataire doit donc être capable d’alerter rapidement son client.
FAQ : sécurité d’un site web et prestataire
Le HTTPS suffit-il à sécuriser un site ?
Non. HTTPS chiffre les échanges entre le navigateur et le serveur, mais ne corrige ni une faille dans le code, ni un compte compromis, ni une mauvaise configuration de l’hébergement.
Faut-il demander un test d’intrusion pour chaque site ?
Pas nécessairement. Le niveau de contrôle doit dépendre des données traitées, de l’exposition du service et des conséquences d’un incident. Une application métier ou un espace client justifie généralement des tests plus poussés qu’un site vitrine statique.
Qui est responsable de la sécurité : le client ou le prestataire ?
La responsabilité dépend du rôle de chaque partie et du contrat. Le client reste responsable de ses choix, de ses comptes et de ses données, tandis que le prestataire doit respecter ses obligations techniques et signaler les risques identifiés. Ces responsabilités doivent être écrites précisément.
Quelle question poser avant de signer ?
Demandez : « Que se passe-t-il si une vulnérabilité est découverte après la mise en ligne ? » La réponse doit couvrir la surveillance, les délais de correction, l’information du client, les sauvegardes et les coûts éventuels. Une sécurité crédible repose sur des engagements mesurables, pas sur une promesse générale.
