Guide
Audit de sécurité de site web : à quoi ça sert, comment ça se passe
Un audit de sécurité, c'est un état des lieux. Quelqu'un d'indépendant regarde votre site comme le ferait un attaquant à la recherche d'une entrée, puis vous dit ce qu'il faut corriger, et dans quel ordre. Voici ce qu'il couvre, comment il se passe et comment le choisir.
À quoi sert un audit de sécurité
Un site web repose sur trois couches. Le code, écrit par une agence, un freelance ou votre équipe, souvent complété d'extensions toutes faites. Le serveur, la machine sur laquelle ce code tourne. Et les accès : comptes, mots de passe, clés. Il suffit d'une faiblesse dans l'une des trois pour qu'un attaquant entre.
L'audit sert à trouver ces faiblesses avant les autres, et à les classer : ce qui est urgent, ce qui peut attendre, ce qui ne pose pas de vrai problème. Vous savez enfin où vous en êtes, et votre prestataire sait par où commencer.
Les moments où il est le plus utile
- Avant la mise en ligne d'un nouveau site ou d'une refonte.
- Quand vous reprenez un site développé par un autre prestataire.
- Après un incident, ou au moindre doute sur un piratage.
- Quand un client ou un partenaire vous demande comment vous protégez ses données.
- Tout simplement quand personne n'a regardé depuis longtemps.
Ce qu'un audit regarde
Le code du site
Les failles, ces erreurs qui permettent de détourner le site. Les secrets laissés en clair, comme un mot de passe de base de données ou une clé de paiement écrits dans le code. Les dépendances, ces briques écrites par d'autres sur lesquelles votre site s'appuie : quand l'une d'elles a une faille connue, votre site en hérite. Et le code inutile, qui alourdit le projet et rend chaque évolution plus chère.
Le serveur
Les logiciels qui ne sont plus à jour. Les fichiers oubliés en accès libre, comme une sauvegarde ou un fichier de configuration. Les ports exposés, c'est-à-dire des entrées ouvertes sur Internet sans raison. Et ce qui n'a rien à faire là : fichiers malveillants, portes dérobées laissées par un pirate.
Les accès
Qui peut se connecter, avec quels droits ? Il n'est pas rare de retrouver le compte d'un ancien prestataire toujours actif, ou un mot de passe partagé par toute l'équipe depuis des années.
Comment ça se passe chez nous
Notre approche part de l'intérieur : nous lisons votre code et votre serveur plutôt que d'attaquer votre site en service. Nous trouvons ainsi les causes, pas seulement les symptômes, et rien ne risque de perturber votre site.
- Un premier échange de 20 minutes : votre site, qui l'a développé, où il est hébergé, ce qui vous inquiète.
- Une proposition chiffrée, selon la taille du code et le nombre de serveurs.
- Les accès. Pour le code, un simple accès en lecture (GitHub, GitLab, Bitbucket, ou une archive). Pour le serveur, un compte en lecture seule, installé en 30 minutes avec votre administrateur, en visioconférence.
- L'analyse. Des outils d'analyse automatisée font le gros du travail, et chaque résultat est vérifié par un expert avant de vous être remis. Votre code est analysé dans un environnement isolé, détruit à la fin de l'audit.
- Le rapport. Pour l'audit de code, nous vous le présentons aussi de vive voix, en 30 minutes, et répondons à vos questions.
Concrètement, cela correspond à nos deux services. L'audit de code examine le site lui-même ; son rapport vous est remis sous 10 jours ouvrés après réception des accès. La surveillance de sécurité commence par l'inventaire de vos logiciels et un audit approfondi du serveur, dont le rapport arrive sous 5 jours ouvrés, puis continue au fil de l'eau. Le Pack Sérénité réunit les deux.
Ce que vous recevez
Pas une liste de trois cents alertes en anglais. Une synthèse pour la direction, qui dit en quelques pages ce qui ne va pas, ce que vous risquez et par quoi commencer. Et une partie technique pour vos développeurs, où chaque problème est situé et expliqué, avec la correction proposée. En option, nous préparons nous-mêmes les corrections du code sur une copie séparée : votre équipe les relit et décide de ce qu'elle applique.
Bien choisir son auditeur
Quel que soit le prestataire, voici ce que vous êtes en droit d'attendre :
- un interlocuteur qui explique sans jargon, à vous comme à votre équipe ;
- un périmètre écrit : ce qui est audité, et ce qui ne l'est pas ;
- une autorisation d'accès signée, qui fixe précisément ce que l'auditeur a le droit de faire ;
- aucune modification de vos systèmes sans votre accord écrit ;
- un engagement clair sur ce que deviennent vos données et la copie de votre code à la fin.
Vos questions
Un audit, est-ce la même chose qu'un test d'intrusion ?
Non. Un test d'intrusion simule une attaque depuis l'extérieur pour voir jusqu'où un attaquant pourrait aller. Notre audit examine le code et le serveur de l'intérieur, pour trouver les causes des failles. Les deux approches sont complémentaires.
Faut-il arrêter le site pendant l'audit ?
Non. L'audit de code se fait sur une copie, dans un environnement isolé : rien ne s'exécute sur vos serveurs. Le compte installé pour la surveillance ne fait que lire.
Mon site est sur Wix ou Shopify : un audit est-il utile ?
Sur ces plateformes, le serveur et une grande partie du code sont gérés par l'éditeur : nos services ne peuvent pas s'y installer. Contactez-nous, nous verrons ensemble ce qui est possible.
Un audit suffit-il une fois pour toutes ?
Non. C'est une photo à une date donnée. De nouvelles failles sont publiées régulièrement sur des logiciels que vous utilisez déjà : c'est ce que la surveillance suit dans la durée.