On va faire un test d'intrusion sur notre appli web et on veut se préparer — vous avez une checklist à faire en interne ?

On a payé 5 000 livres l'an dernier pour un audit sur un SaaS B2B similaire. Comme on n'avait rien préparé, sur les 22 vulnérabilités du rapport, 14 concernaient de simples headers HTTP manquants et des bannières de serveur par défaut. Voir qu'au moins 1 500 livres du budget sont parties là-dedans, ça nous a bien dégoûtés.

Le point le plus critique reste la stabilité de votre environnement de test. Ne les laissez jamais bosser sur la prod : montez une instance dédiée avec une copie anonymisée des données. Si l'auditeur balance des payloads qui corrompent la base ou saturent les files d'attente (queues), votre activité réelle ne doit pas s'arrêter. Et évidemment, interdiction formelle pour les devs de déployer du nouveau code pendant toute la durée du pentest.

Regardez aussi du côté de la validation des entrées et du chiffrement. Vérifiez l'échappement des caractères spéciaux dans vos formulaires et paramètres d'URL. Assurez-vous que toutes les entrées utilisateurs soient correctement assainies avant stockage et que les tokens de session soient bien invalidés côté serveur lors de la déconnexion. Ces failles de base gâchent vite un pentest.

Attention quand même à ne pas trop simplifier votre environnement sous prétexte de faciliter le test. Certains devs désactivent complètement le pare-feu ou certains middlewares pour que ce soit plus simple, puis tout pète une fois en production. Votre environnement de test doit être une copie conforme de la config de prod.

Fournissez aux auditeurs au moins deux comptes valides par niveau de privilège : deux utilisateurs classiques et deux administrateurs. Ajoutez aussi un compte invité/démo restreint. Comme ça, ils peuvent tester dès la première heure l'élévation de privilèges horizontale et verticale sans perdre de temps.

Vous avez signé pour du white-box ou du black-box ? Si vous prévoyez de leur donner le code source et les schémas d'API votre priorité numéro un doit être de blinder la documentation. Si vous ne leur donnez aucun accès au code, concentrez tous vos efforts sur les endpoints exposés publiquement.

Excellente démarche. Cette phase de préparation va aussi faire monter votre équipe en compétences sur la sécurité. Organisez une demi-journée d'atelier interne pour passer en revue les points du top 10 OWASP directement sur votre base de code, c'est le meilleur moyen de rentabiliser l'audit.

mettez direct son ip en liste blanche sur le firewall... du coup pendant notre pentest le gars etait blooque toute la premiere matinee il a fallu echanger des mails pendant des heures l argent jete par les fenetres quoi.

Je suis d'accord.

Chez moi, c'est l'inverse qui s'est passé c'est pourquoi j'écris. Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant, j'ai appris cela trop tard.

Plus il est difficile de revenir sur une décision plus il faut la prendre lentement. C'est confirmé par l'expérience.

Si vous partez dans cette direction, réglez cela dès le départ. Aucun processus sans suivi ne s'améliore, car vous ne savez pas quoi corriger.

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

Je vais résumer ce qui a été dit jusqu'ici. Un rapport de scan automatique n'est pas la même chose qu'un test d'intrusion.

Bon courage.

Ce sujet est archivé.

Chez nous, ça s'est passé comme ça. Si vous ne formalisez pas cela par écrit dès le départ des disputes éclateront plus tard.

Les environnements de test oubliés sont plus souvent des portes d'entrée que les systèmes de production. Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

Je pense différemment. Quand on décide sans mesurer, on revient toujours au même point.

Une sauvegarde non testée n'est pas une sauvegarde. Si vous avez des questions, écrivez-moi, je répondrai au mieux.

Je n'ai aucune expérience en test d'intrusion application web, c'est pourquoi je pose la question. Le fait que la sauvegarde soit accessible sur le même réseau et avec la même identité en fait une cible potentielle.

Si vous avez des questions, écrivez-moi, je répondrai au mieux.

Sujet très actuel.

Ma question va paraître un peu novice, désolé d'avance. La plupart des incidents ne viennent pas d'une faille, mais d'un mot de passe divulgué.