Audit de sécurité de site web, vitrine, boutique ou CMS.
Un site public est exposé en permanence, et la plupart des attaques qu'il subit ne visent personne en particulier. Elles balayent, elles trouvent, elles reviennent. Cet audit examine votre site du point de vue d'un attaquant : depuis l'extérieur, sans documentation, en cherchant l'écart entre ce que vous pensez avoir publié et ce qui est réellement accessible.
Personne ne vous en veut. C'est justement le problème.
La question que j'entends le plus souvent est : « pourquoi nous ? ». La réponse est presque toujours la même : pour rien en particulier. L'immense majorité des compromissions de sites publics ne visent aucune cible précise. Des robots parcourent le web en continu, testent les versions connues, les chemins d'administration classiques, les fichiers laissés à la racine, et enregistrent ce qui répond.
Un site repéré par ce balayage ne sert pas à voler vos données, souvent inexistantes. Il sert de relais : pages de phishing hébergées chez vous, redirections vers des sites de contrefaçon, envoi de courriels frauduleux depuis votre domaine. Le coût n'est pas le vol, c'est le nettoyage, le domaine placé sur liste noire, et les semaines de référencement perdues.
Le deuxième cas est plus ciblé et plus cher : quelqu'un s'intéresse à votre espace client, à vos commandes, à votre base de contacts. Là, le robot ne suffit plus, il faut un humain. Et un humain trouve toujours ce qu'un robot ne voit pas : le formulaire qui accepte un identifiant qui n'est pas le sien, la page de suivi de commande accessible sans être connecté, le sous-domaine de recette laissé en ligne depuis la refonte.
Ce que je regarde.
Un site public, ce n'est pas seulement les pages que vous avez commandées. C'est aussi tout ce qui s'est accumulé autour.
- Surface réellement exposée : sous-domaines oubliés, environnements de recette encore en ligne, anciennes versions du site jamais coupées.
- Configuration de l'hébergement : en-têtes de sécurité, cookies, TLS, listage de répertoires, fichiers de sauvegarde et archives laissés accessibles.
- CMS et extensions : versions, composants abandonnés par leur auteur, réglages par défaut jamais durcis, interface d'administration ouverte au monde entier.
- Formulaires : contact, devis, inscription, recherche. Injection, envoi de courriels par un tiers, absence de limite de débit, exposition d'adresses.
- Espace client : création de compte, mot de passe oublié, accès aux commandes et aux documents d'un autre client.
- Tunnel de paiement : manipulation des montants et des quantités, codes promotionnels rejouables, validation de commande sans passer par la caisse.
- Téléversements : pièces jointes, photos de profil, documents. Type réellement contrôlé, emplacement de stockage, exécution possible.
- Développements sur mesure : c'est là que se trouvent les failles qui n'existent nulle part ailleurs, et donc dans aucune base de signatures.
Comment se passe une mission.
Cadrage et autorisation
On fixe par écrit ce qui entre dans le périmètre et ce qui en sort, la fenêtre pendant laquelle je peux tester, et la personne à joindre si quelque chose de critique sort. Un NDA est signé avant que vous ne me communiquiez la moindre information technique.
Cartographie de l'exposition
Avant de tester quoi que ce soit, j'établis ce qui est réellement joignable depuis internet à votre nom. Cette étape révèle presque à chaque fois quelque chose que personne n'avait en tête : un sous-domaine de préproduction, une ancienne boutique, un outil interne resté public.
Passage sur la surface publique
Configuration, en-têtes, CMS, extensions, formulaires. Cette partie s'appuie sur de l'outillage pour ne rien manquer de mécanique, mais chaque résultat est vérifié à la main. Un outil qui signale cinquante problèmes en a inventé quarante-cinq.
Recherche manuelle sur les parcours
Le cœur du travail. Je crée des comptes, je passe des commandes, je manipule les paramètres que l'interface n'est pas censée laisser toucher, et je vérifie si le serveur les accepte. C'est cette étape qui trouve ce qu'aucun scanner ne trouvera.
Rapport et restitution
Chaque faille est classée par ce qu'elle coûte réellement, pas par un score générique. Vous recevez la preuve, la marche à suivre pour reproduire, et le correctif. Un échange d'une heure permet de tout reprendre avec les personnes qui vont corriger.
Retest
Une fois les corrections déployées, je rejoue les tests concernés et vous confirme par écrit ce qui est réellement fermé. C'est inclus dans la mission, pas facturé à part.
Ce que ça donne en pratique.
Failles réelles, trouvées, signalées et corrigées. Les clients et les périmètres ne sont jamais divulgués.
Site web ou application ? Ce n'est pas la même mission.
Les deux prestations existent parce qu'elles ne cherchent pas la même chose. Voici comment trancher en une phrase.
C'est un site web
Vos visiteurs consultent, remplissent un formulaire, achètent, et éventuellement se connectent à un espace client simple. L'essentiel du risque est dans l'exposition, la configuration et les briques que vous n'avez pas écrites. C'est cette page.
C'est une application
Vos utilisateurs se connectent pour faire un travail : plusieurs rôles, des droits qui se croisent, des flux métier. Le risque se déplace vers la logique et les permissions, et demande une autre profondeur de test.
Questions fréquentes.
Mon site est une simple vitrine, ai-je vraiment quelque chose à protéger ?
Deux choses, oui. Votre réputation d'abord : un site vitrine compromis sert à héberger des pages de phishing ou à rediriger vos visiteurs, et Google le signale en rouge dans ses résultats en quelques heures. Votre infrastructure ensuite : le serveur qui héberge la vitrine héberge souvent la messagerie, un extranet ou les sauvegardes. L'attaquant ne cherche pas vos données, il cherche une machine.
Combien de temps le site est-il indisponible pendant l'audit ?
Zéro. Je ne fais ni déni de service ni test de charge, et je n'exécute jamais d'action destructrice sur des données réelles. Les requêtes sont espacées pour ne pas peser sur le serveur. Si une manipulation présente le moindre risque pour la production, je vous préviens avant et on décide ensemble.
Vous avez besoin d'un accès à mon hébergement ?
Non, pas pour l'audit lui-même : je teste depuis l'extérieur, comme un attaquant. Des comptes utilisateurs sont utiles s'il existe un espace client ou une boutique, et un accès en lecture au code accélère beaucoup la partie développements sur mesure. Rien de tout cela n'est obligatoire pour commencer.
Mon agence a déjà installé un pare-feu applicatif, est-ce suffisant ?
Un pare-feu applicatif filtre les attaques connues et génériques, ce qui élimine le bruit de fond automatisé. Il ne voit pas qu'un formulaire de devis accepte un identifiant de commande qui n'appartient pas au visiteur, parce que cette requête est parfaitement légitime de son point de vue. Il réduit le volume, pas le risque réel.
Et après, je fais quoi des corrections ?
Chaque vulnérabilité du rapport est accompagnée de la marche à suivre pour la corriger, rédigée pour être transmise telle quelle à votre agence ou à votre développeur. Quand les correctifs sont en place, je rejoue les tests concernés. Ce retest est inclus, il n'est pas facturé en supplément.
Les autres prestations.
Audit de sécurité d'API
Si votre site s'appuie sur une API pour ses formulaires, son panier ou son espace client, elle applique ses propres règles et se teste séparément.
DécouvrirAuthentification et permissions
Si votre espace client distingue plusieurs types d'utilisateurs, la question devient : qui peut vraiment atteindre quoi.
DécouvrirFaites auditer votre site.
Donnez-moi l'adresse du site, dites-moi s'il y a un espace client ou une boutique, et si des développements sur mesure ont été faits. Je vous réponds avec un cadrage et un devis. Premier échange sans engagement, confidentialité totale.