Sécurité des sites web en France : le bilan chiffré

Les premiers chiffres : 3 constats marquants

En étudiant ces résultats, un premier constat est ressorti nettement : 100% de sites étaient vulnérables à au moins une faille de sécurité ! Ces failles pouvant avoir des impacts différents, nous les avons donc catégorisées en fonction du risque qu’elles pouvaient engendrer : majeur, important ou mineur.

Nous avons alors observé que 60% des sites se trouvent vulnérables à des risques majeurs, permettant d’accéder à l'ensemble du contenu et/ou de compromettre le serveur. Cette situation est vraie pour 50% des sites exposés sur Internet et pour 75% des sites internes. Nous avions déjà l’intuition que la situation n’était pas bonne, et ce, quel que soit le secteur d’activité. Notre sentiment est désormais conforté par ces chiffres.

Les 4 zones à risques à surveiller

En zoomant sur les failles spécifiques, 3 zones particulièrement sensibles ont été découvertes. Tout d’abord, le contrôle d’accès, défaillant dans 44% des cas, montre que les accès et privilèges des utilisateurs sont trop peu vérifiés. Le dépôt de fichier représente également un vecteur d’attaque : dans 37% des cas, il a rapidement permis de compromettre le serveur applicatif. De plus, la possibilité de rejouer des requêtes à l’insu d’un utilisateur (XSRF ou CSRF) touche 2 tiers des sites : l’exploitation de cette faille peut, par exemple, autoriser un site tiers à remplacer à l’insu de l’utilisateur son adresse email de contact (l’attaquant pouvant dès lors utiliser la fonction de réattribution d’un mot de passe par email). 

Enfin, le langage de développement utilisé s’avère également être un facteur de risque. En effet, 75% des sites développés en PHP sont sujets à au moins une faille grave, contre 40% pour ceux développés en Java. Cependant, le nombre total de failles reste en moyenne identique, quelque que soit le langage.

Quelles solutions ?

La gestion actuelle des projets ne laisse pas beaucoup de place à la sécurité : mise en production urgente, projet dont on apprend l’existence à sa sortie, etc. L’intégration de la sécurité dès le début du projet est l’une des clés à maîtriser pour améliorer ce chiffre.

Cependant le rythme ne cesse de s’accélérer avec l’essor des méthodes agiles, DevOps… Pourrait-on réaliser un test tous les 15 jours alors qu’il n’est pas possible aujourd’hui d’en faire un seul avant la mise en production ? Ces nouvelles méthodologies sont pourtant une opportunité d’appliquer ce qui n’a jamais été possible : intégrer la sécurité en continu dans le processus de développement en rapprochant les contrôles des développeurs.

Car la réponse ne viendra pas uniquement d’investissements sur des nouveaux composants de sécurité, de contrôles a posteriori, etc. Il est plus que jamais nécessaire d’investir dans les compétences des équipes, en particulier des développeurs, pour que la sécurité soit bien plus qu’une étape dans des processus peu suivis, mais bien une réalité de chaque instant.

Méthodologie et périmètre