Comment tester la sécurité de son site soi-même, que vérifier avant un pentest ?

Très bon réflexe de faire un premier tri vous-mêmes. Si vous lancez un pentest avec des failles basiques connues sur le serveur, le rapport final fera des pages entières juste pour vous dire de faire vos mises à jour, et votre argent sera gâché. Verrouillez d'abord les portes vous-mêmes, puis payez l'expert pour tester la résistance des serrures.

On était dans le même cas l'an dernier. Impossible de sortir 4.000 EUR, du coup on a passé 3 jours à mettre à jour tous les paquets et à régler les en-têtes HTTP. Le test plus ciblé qu'on a commandé après nous a coûté 1.800 EUR parce que l'expert est intervenu sur une base propre et prête.

Faites ça dès ce soir : créez deux comptes clients B2B de test. Connectez-vous avec le premier, passez une commande, copiez l'ID dans l'URL de la commande et tentez de l'ouvrir dans la session de l'autre utilisateur. Si les données de l'autre s'affichent, vous venez de trouver votre plus grosse faille gratuitement.

Ne faites pas trop confiance aux scanners open-source tout faits trouvés sur le net. Ils génèrent souvent des milliers de faux positifs, votre dev ne saura plus où donner de la tête et risque de passer à côté des vraies failles d'autorisation critiques.

Voici la checklist minimale à faire vous-mêmes : 1) Masquez les versions du serveur et de la BDD dans les messages d'erreur. 2) Mettez un rate-limiting sur la page de login contre les attaques par force brute. 3) Vérifiez qu'aucun dump de sauvegarde de base de données ne traîne dans le dossier public.

Votre dev ne doit pas hésiter il y a d'excellents outils d'analyse gratuits en ligne qui notent les en-têtes de sécurité. Vous entrez l'URL et ça vous donne une note de A à F. Rien que de bosser pour atteindre le A permet de bien assainir le système.

les vieux comptes de test oubliés et les mdp faibles sur le panel admin ouvrent la porte à plus de la moitié des attaques, avant de scanner quoi que ce soit vérifiez les mots de passe et mettez la 2FA pour tout le monde.

Réalisez impérativement vos tests en dehors des heures ouvrées et sur une copie conforme du système en production. Des requêtes automatisées massives peuvent provoquer des blocages de base de données ou des coupures de service sur la prod.

J'aimerais poser une question. Quand on essaie de tout changer en même temps, rien ne prend.

C'est mon avis, je ne l'écris pas comme une vérité absolue.

C'est noté, merci. Tout point non écrit est un point que les deux parties se rappelleront différemment plus tard.

Le fait que la sauvegarde soit accessible sur le même réseau et avec la même identité en fait une cible potentielle.

Le point le plus souvent négligé concernant test de sécurité de site est : Ce qui nous faisait perdre le plus de temps c'était l'absence de clarté sur qui prenait les décisions.

Bien sûr, cela change si votre situation est différente.

Je vais résumer ce qui a été dit jusqu'ici. Si vous grondez les fausses alertes plus personne ne signalera rien.

Je suis aussi curieux de savoir si d'autres font autrement.

C'est noté, merci.

Je vais résumer le sujet, car plusieurs réponses différentes ont été données. Le vrai problème n'est pas le chiffre, mais la base sur laquelle il est calculé.

Si vous écrivez le résultat ici cela aidera aussi d'autres personnes.

ce qui est écrit correspond exactement à ce que nous avons vécu. si vous grondez les fausses alertes, plus personne ne signalera rien.

c'est mon avis, je ne l'écris pas comme une vérité absolue.

Je vais essayer.

je vais résumer le sujet car plusieurs réponses différentes ont été données. tout point non écrit est un point que les deux parties se rappelleront différemment plus tard.

je suis aussi curieux de savoir si d'autres font autrement.

Sujet très actuel.