01
Tests d'intrusion d'applications web
Tests en boîte noire et en boîte grise de votre application web, face à l'OWASP Top 10 et à vos propres règles métier.
Évaluer · Valider · Rapporter · Corriger · Durcir · Surveiller
Tests d'intrusion web et services de cybersécurité
Nous identifions les vraies vulnérabilités de votre application web et de vos API, nous vous aidons à les corriger et nous maintenons vos défenses après le lancement. Vous recevez des preuves et des correctifs, pas un export de scanner.
Toujours sur autorisation écrite et dans le périmètre convenu.
Le cycle de vie de la sécurité
Une boucle complète, pas un rapport isolé
Six étapes. Choisissez une étape pour voir ce qu'elle contient. La plupart des équipes commencent par l'évaluation ; certaines rejoignent la boucle plus tard.
Étape 01 sur 06
Évaluer
Nous cartographions la surface d'attaque dans le périmètre convenu : routes, rôles, API, services tiers et infrastructure exposée.
- Inventaire des actifs et des endpoints
- Rôles utilisateurs et frontières de confiance
- Couverture outillée des problèmes connus
Services principaux
Ce que nous testons, corrigeons et mettons en place
Prenez un service ou plusieurs. Chaque mission commence par un périmètre écrit.
02
Tests de sécurité d'API
API REST et GraphQL testées pour les défauts d'autorisation, l'exposition de données et les abus, comme le ferait une application cliente.
03
Évaluation des vulnérabilités et rapport
Un rapport clair que votre équipe peut exploiter, puis un nouveau test pour confirmer que les correctifs fonctionnent.
04
WAF, CDN et protection en périphérie
Contrôles en périphérie configurés avec un fournisseur adapté, p. ex. Cloudflare, pour filtrer les abus avant qu'ils n'atteignent votre application.
Un WAF complète un code sécurisé. Il ne remplace pas les tests.
05
Supervision et alertes
Les signaux de sécurité sont réunis en un seul endroit et envoyés à la bonne personne, avec les outils que vous utilisez déjà.
06
Durcissement
Le travail de configuration qui élimine des classes entières de problèmes, et les tests qui les maintiennent fermées.
Correction : vous choisissez qui corrige
Deux types de mission. Nous convenons de l'un d'eux avant le début des tests.
Nous faisonsTester le périmètre convenu et valider les constatsRemettre le rapport et un plan de correction prioriséPrésenter les constats à votre équipeRetester les correctifs livrés par votre équipe
Votre équipe faitAppliquer les correctifs dans votre code et votre infrastructureNous prévenir quand les correctifs sont prêts pour le nouveau test
Scanner ou test d'intrusion manuel
Les deux sont utiles. Ils répondent à des questions différentes.
Un scanner demande « quelque chose de connu est-il cassé ? ». Un test d'intrusion demande « que pourrait réellement faire quelqu'un avec cette application ? ».
Scan automatisé
Ce qu'il vérifieVulnérabilités connues, composants obsolètes et mauvaises configurations courantes.
Logique métierNe peut pas savoir si une remise, un remboursement ou un changement de rôle devrait être autorisé.
Contrôle d'accèsDétecte rarement qu'un utilisateur accède aux données d'un autre.
Faux positifsFréquents. Quelqu'un doit encore trier les vrais problèmes du bruit.
RésultatUne longue liste d'alertes, classées par des scores génériques.
Idéal pourDes contrôles d'hygiène fréquents et la non-régression entre deux tests.
Test d'intrusion manuel
Ce qu'il vérifieLe comportement réel de votre application, y compris les failles propres à votre produit.
Logique métierVérifie que des règles comme « seuls les propriétaires peuvent rembourser » résistent aux abus.
Contrôle d'accèsConfronte chaque rôle à chaque objet et action sensibles.
Faux positifsChaque constat est reproduit et appuyé par des preuves.
RésultatUn rapport classé par risque, avec impact et correctifs pour votre application.
Idéal pourAvant un lancement, après des changements majeurs et quand l'enjeu est élevé.
Nous utilisons des scanners dans chaque test d'intrusion pour la couverture, puis nous consacrons le temps à ce qu'ils manquent.
Livrables
Ce que vous recevez à la fin
- Document de périmètreCibles, environnements, rôles, limites et dates, signés avant les tests.
- Constats et classement des risquesChaque problème avec sa gravité, ses preuves et son impact métier.
- Plan de correctionQuoi corriger en premier, comment, et qui en est responsable.
- Recommandations de configurationEn-têtes, WAF, règles d'accès et gestion des secrets.
- Accompagnement à la mise en œuvreCorrectifs réalisés avec votre équipe, si convenu.
- Nouveau testConfirmation que les constats convenus sont corrigés.
- Mise en place de la supervisionJournaux, alertes et acheminement, si inclus.
Structure illustrative
Exemple de structure de rapport[Nom de l'application] évaluation de sécurité
Critique-
Élevée-
Moyenne-
Faible-
F-XX[Gravité]
[Titre du constat]PreuvesImpact métier[Ce que cela signifie pour les utilisateurs et les données]Correction[Correctif précis et responsable]Nouveau test[Statut après le nouveau test]
Déroulé d'une mission
Six étapes, convenues avant que nous touchions à quoi que ce soit
- ÉTAPE 01
Cadrage et autorisation écrite
Nous convenons des cibles, des limites et des dates, et vous signez l'autorisation.
- ÉTAPE 02
Évaluation encadrée
Les tests se déroulent dans la fenêtre, les limites de débit et les exclusions convenues.
- ÉTAPE 03
Revue des constats
Présentation de chaque constat avec votre équipe, classé par risque.
- ÉTAPE 04
Plan de correction
Correctifs ordonnés par risque et effort, avec des responsables clairs.
- ÉTAPE 05
Mise en œuvre des contrôles
Correctifs, durcissement et supervision, par nous ou par votre équipe.
- ÉTAPE 06
Nouveau test et suivi
Nous confirmons les correctifs, puis convenons d'éventuels tests complémentaires.
Qui nous aidons
Les équipes dont l'application ne peut pas se permettre une mauvaise semaine
SaaS
Applications multi-locataires où un client ne doit jamais voir les données d'un autre.
Fintech
Flux de paiement, soldes et actions sur les comptes, où une faille de logique coûte de l'argent réel.
E-commerce
Paiement, codes promo, comptes clients et interfaces d'administration qui attirent les abus.
Startups avant lancement
Un test avant le lancement, pour que vos premiers utilisateurs ne soient pas vos premiers testeurs.
Applications et API critiques
Outils internes et API dont d'autres systèmes et équipes dépendent chaque jour.
Confiance et limites
Les règles qui encadrent notre travail, en termes simples
- Aucun test sans autorisation écrite du propriétaire du système.
- Un périmètre défini avec des limites sûres : cibles, horaires, limites de débit et actions exclues.
- La production n'est testée qu'avec une autorisation documentée.
- Aucun test ne peut trouver toutes les vulnérabilités. Nous rapportons ce que nous avons trouvé dans le périmètre et le temps convenus.
- Nous ne promettons pas l'exhaustivité et nous ne qualifions aucun système de « sécurisé » après un test.
- Le périmètre de supervision, et qui répond aux alertes, est convenu pour chaque mission. Nous configurons la supervision ; nous n'exploitons pas de SOC managé.
FAQ
Questions avant une mission de sécurité
Des tests manuels et outillés de votre application web dans un périmètre convenu : authentification et sessions, contrôle d'accès comme les IDOR et l'élévation de privilèges, injection, XSS, SSRF, logique métier, envois de fichiers, validation des entrées et limites de débit, au regard de l'OWASP Top 10. Vous recevez un rapport avec preuves et correctifs.
Un scan exécute des contrôles automatisés pour des problèmes connus. Il est rapide et utile pour l'hygiène régulière. Un test d'intrusion ajoute une personne qui comprend votre application, enchaîne les constats et teste la logique qu'un scanner ne voit pas, par exemple si un utilisateur peut accéder aux données d'un autre.
Oui, dans une mission avec correction. Nous appliquons les correctifs avec votre équipe, puis nous retestons. Dans une mission d'évaluation seule, vous recevez le rapport et le plan de correction, et votre équipe effectue les changements.
Oui. Nous mettons en place règles WAF, limitation de débit, mitigation des bots, TLS, en-têtes de sécurité et protection de l'origine avec un fournisseur adapté, p. ex. Cloudflare. Un WAF complète un code sécurisé. Il ne remplace pas les tests.
Nous configurons une journalisation centralisée et des alertes pour les événements de sécurité, les échecs d'authentification et les abus, et nous les acheminons vers les personnes qui réagissent. Qui surveille les alertes et comment les incidents sont traités est convenu pour chaque mission. Nous n'exploitons pas de SOC managé.
Uniquement avec une autorisation documentée et des limites sûres convenues. Nous préférons un environnement de préproduction qui reflète la production. Lorsque la production est incluse, nous convenons par écrit des horaires, des limites de débit et des actions exclues.
Lors de l'appel de cadrage, nous listons les domaines, applications, API, rôles utilisateurs et environnements à tester, ainsi que ce qui est hors limites. Cela devient l'autorisation écrite que nous signons tous deux avant le début des tests.
Oui. Le nouveau test des constats convenus fait partie de la mission, pour que vous ayez la preuve que les correctifs fonctionnent. Des tests supplémentaires par la suite sont convenus séparément.
Décrivez votre application, vos préoccupations, votre périmètre.
Nous répondons avec un périmètre proposé, le type de mission adapté et un devis sur mesure. Rien n'est testé tant que l'autorisation n'est pas signée.
N'incluez ni identifiants ni détails de vulnérabilités dans votre premier message. Nous mettrons en place un canal sécurisé une fois le périmètre convenu.
