Pentest application web

On casse votre app avant les autres

Votre prochaine levée, certification SOC 2 ou contrat Enterprise dépend d'un rapport de pentest. On teste votre application comme un attaquant réel — et vous recevez un rapport avec chaque faille documentée et son correctif, prêt à merger.

Rapports conformes SOC 2 et ISO 27001 Zéro faux positif Retest inclus

Périmètre

Ce qu'on teste

01

Injection (SQL, NoSQL, LDAP, OS)

Une injection SQL sur un endpoint de recherche donne accès à toute la base de données. On teste chaque point d'entrée — formulaires, headers, payloads JSON — manuellement.

02

IDOR et contrôle d'accès

Un paramètre modifié dans l'URL, et le tenant A accède aux données du tenant B. On teste chaque ressource pour les accès horizontaux et verticaux — UUID et ID séquentiels.

03

Authentification et sessions

Brute force, bypass MFA, fixation de session, tokens qui ne tournent pas. On audite le flux d'authentification complet, du login au logout.

04

Logique métier

Les scanners ne trouvent pas les failles de logique. On teste vos workflows : contournement d'étapes, manipulation de prix, race conditions, abus de fonctionnalités.

05

Cross-Site Scripting (XSS)

Une XSS stockée dans un champ de commentaire touche tous les utilisateurs qui le consultent. On cherche les XSS stockées, réfléchies et DOM-based, y compris les contournements de CSP.

06

SSRF et interactions serveur

Un import de fichier ou un webhook mal protégé donne accès à vos métadonnées cloud et services internes. On teste chaque fonctionnalité qui fait des requêtes côté serveur.

07

Headers de sécurité et configuration

CSP, HSTS, cookies sans flags Secure/HttpOnly, CORS trop permissif. Les headers manquants sont les failles les plus faciles à corriger — et les plus souvent oubliées.

08

Exposition de données sensibles

Endpoints de debug en production, stack traces dans les réponses d'erreur, secrets dans le code frontend. On identifie chaque point de fuite avant qu'un attaquant ne le fasse.

Extrait de rapport

Voici ce que vous recevez

Chaque vulnérabilité est documentée avec sa preuve d'exploitation et un correctif applicable. Pas de généralités, pas de faux positifs.

4.2.1 Broken Object-Level Authorization (IDOR)
HIGH
CVSS 3.1: 7.5 OWASP: A01:2021 Verification: Live-Confirmed

Description

L'endpoint /api/v1/documents/{id} permet à un utilisateur authentifié de lire et modifier les documents de n'importe quel tenant en manipulant le paramètre id. Aucune vérification d'appartenance au tenant n'est effectuée côté serveur.

Requête

GET /api/v1/documents/1337 HTTP/2
Host: app.example.com
Authorization: Bearer eyJhbGci...{token_tenant_A}

Réponse — document du tenant B

200 OK
{
  "id": 1337,
  "tenant_id": "tenant_B",
  "title": "Facture #2024-0891 — Client Acme Corp",
  "amount": "42 500.00",
  "status": "paid"
}

Correctif proposé

// app/Http/Controllers/DocumentController.php
public function show(Request $request, int $id)
{
    $document = Document::where('id', $id)
        ->where('tenant_id', $request->user()->tenant_id)
        ->firstOrFail();

    return $document;
}

Méthodologie

Notre approche étape par étape

01

Cadrage

Définition du périmètre, des rôles utilisateurs et des scénarios prioritaires.

1 jour

02

Reconnaissance

Cartographie de l'application, identification des endpoints et des flux de données.

0.5 jour

03

Tests manuels

Exploitation manuelle de chaque vecteur d'attaque identifié. Pas de scanner automatique.

3–7 jours

04

Rapport

Documentation de chaque finding avec preuve d'exploitation, score CVSS et correctif.

Inclus

05

Restitution

Présentation des résultats à votre équipe. Priorisation et plan de remédiation.

Inclus

OWASP WSTG OWASP ASVS PTES OSSTMM CVSS 3.1 CWE

Livrable

Contenu du rapport

Synthèse exécutive

Résumé non technique pour votre direction et vos investisseurs. Score de risque global et tendances.

Findings détaillés

Chaque vulnérabilité documentée avec preuve d'exploitation, score CVSS 3.1 et mapping OWASP.

Correctifs applicables

Code ou configuration de correction prêt à être intégré par votre équipe de développement.

Matrice de risques

Classement par sévérité et facilité d'exploitation pour prioriser votre plan de remédiation.

Mapping conformité

Chaque finding mappé vers NIS2, DORA, SOC 2, ISO 27001, PCI DSS. Prêt pour votre auditeur.

Retest inclus

Validation gratuite de vos corrections sous 30 jours. Attestation de remédiation fournie.

Conformité

Chaque audit couvre vos obligations réglementaires

Les findings sont mappés vers les référentiels de conformité applicables à votre secteur.

OWASP

Référentiel de test standard pour la sécurité applicative

NIS2

Directive européenne sur la cybersécurité des entités essentielles

DORA

Tests d'intrusion obligatoires pour le secteur financier

SOC 2

Preuves de pentest requises pour les Trust Services Criteria

ISO 27001

Tests de sécurité réguliers exigés par l'annexe A

PCI DSS

Tests d'intrusion obligatoires pour le traitement de paiements

Tarif indicatif

3 000 – 15 000 €

5–10 jours ouvrés

Prix fixe après cadrage. Pas de surprise, pas de semaines d'attente.

  • Tests d'intrusion manuels (OWASP Top 10)
  • Rapport PDF avec scoring CVSS
  • Correctifs applicables pour chaque finding
  • Synthèse exécutive pour la direction
  • Restitution orale avec votre équipe
  • Retest gratuit sous 30 jours
Cadrer mon audit

Appel de 30 min — sans engagement

Questions fréquentes

Ce que nos clients demandent

Quelle différence entre un pentest et une revue de code ?

Le pentest teste votre application depuis l'extérieur (black/grey box) en simulant un attaquant réel. La revue de code analyse le code source (white box) pour trouver des failles invisibles depuis l'extérieur : secrets hardcodés, logique d'autorisation fragile, dépendances vulnérables. Les deux approches sont complémentaires.

Combien d'endpoints testez-vous ?

Le périmètre est défini lors du cadrage. Un audit standard couvre 30 à 80 endpoints. Pour les applications plus larges, on ajuste le calendrier et le tarif en conséquence. Chaque endpoint est testé manuellement sur tous les vecteurs d'attaque pertinents.

Faut-il fournir des comptes de test ?

Selon l'approche choisie : en black box, aucun accès n'est fourni. En grey box (recommandé), on vous demande 2 à 3 comptes avec des rôles différents (admin, utilisateur, lecteur) pour tester les contrôles d'accès entre rôles et entre tenants.

Comment gérez-vous les architectures multi-tenant ?

C'est notre spécialité. On teste systématiquement l'isolation entre tenants : accès croisé aux données (IDOR), élévation de privilèges inter-tenant, fuites d'information dans les réponses API. Chaque tenant est traité comme un périmètre de sécurité distinct.

Les APIs sont-elles incluses dans le pentest web ?

Oui, les APIs consommées par l'application web sont testées dans le cadre du pentest. Pour un audit approfondi d'une API REST ou GraphQL complexe (documentation OpenAPI, schéma GraphQL, WebSocket), on recommande un audit API dédié.

Est-ce que les tests risquent de perturber notre production ?

Non. Le périmètre et les conditions de test sont définis lors du cadrage. On peut intervenir sur un environnement de staging ou de production avec des précautions adaptées : pas de tests destructifs, fenêtres horaires définies, IP sources communiquées à l'avance pour whitelisting.

Signez-vous un accord de confidentialité ?

Oui, systématiquement. Un NDA est signé avant le début de chaque mission. Le rapport est chiffré et transmis uniquement aux destinataires définis lors du cadrage. Les données collectées pendant les tests sont détruites à la fin de la mission.

Prêt à sécuriser votre application

Décrivez votre projet en 2 minutes. On revient vers vous le même jour avec une proposition de périmètre et un devis détaillé.

Réponse le jour même · Sans engagement · 4 missions par mois maximum

Obtenir un devis gratuit