Méthodologie

Notre méthode de revue externe.
Claire, limitée, reproductible.

Une revue externe, ce n'est ni un scanner automatique ni un pentest intrusif. C'est une lecture technique de votre surface publique, menée de façon disciplinée, avec des limites explicites : pas de brute force, pas de téléchargement massif, pas de modification de données, pas de perturbation en production.

Cadre

6
phases de travail
0
accès serveur requis
0
disruption production
48h
premier rapport

Ce que « passif » veut dire

  • Observer ce qu'un tiers peut déjà voir depuis Internet : DNS, sous-domaines, en-têtes, robots.txt, sitemap.xml, bundles, routes d'API, docs techniques, IAM exposé, buckets, panels et processus d'automatisation.
  • Vérifier les findings sans exfiltrer de données personnelles ni créer d'effets de bord inutiles.
  • Privilégier la preuve par la configuration, le code client, la structure des réponses, les modèles d'accès et les comportements observables.
  • Documenter honnêtement la frontière entre finding confirmé, risque plausible et hypothèse non vérifiée.

Les 6 phases de notre processus

Phase 0

Cadrage et cartographie rapide

Comprendre le périmètre visible, les domaines, les sous-domaines, la stack apparente et les dépendances les plus exposées.

Phase 1

Énumération externe

DNS, certificats, en-têtes, routes courantes, robots, sitemap, exposition de panels d'admin, outils d'analytique, IAM, préprod ou environnements oubliés.

Phase 2

Analyse applicative

Téléchargement et lecture des bundles, recherche de source maps, routes d'API, rôles, webhooks, schémas de données, specs Swagger ou GraphQL.

Phase 3

Validation des findings

Qualification manuelle de chaque signal : ce qui est vraiment accessible, ce qui n'est qu'exposé comme blueprint, ce qui est déjà bloqué.

Phase 4

Qualification d'impact

Priorisation par faisabilité, gravité, valeur métier et implications de conformité. Une faille ne vaut pas seulement par son score, mais par ce qu'elle ouvre réellement.

Phase 5

Restitution et remédiation

Rapport, synthèse dirigeante, preuves reproductibles, ordre de correction, restitution claire pour l'équipe technique comme pour les décideurs.

Ce que nous vérifions en pratique

Surface d'attaque externe

Sous-domaines, environnements de préprod, services oubliés, routes techniques, panels, docs et métadonnées publiques.

Bundles et source maps

Parcours d'authentification, rôles, modèles de données, routes d'API, webhooks, URLs internes, variables publiques et logique client sensible.

API et exposition technique

REST, GraphQL, Swagger/OpenAPI, schémas, routes de back-office, écarts de réponses, contrôle d'accès apparent.

Authentification, rôles et isolation des données

RLS, séparation des tenants, permissions, processus d'admin, logique de réinitialisation, magic links, policies incomplètes.

Stockage et automatisation

Buckets, signed URLs, webhooks, n8n/Make, signatures HMAC, chaînes d'admin déportées, fichiers accessibles par URL directe.

Contexte métier et conformité

Données personnelles, santé, finance, RH, juridique, attentes clients, questionnaires sécurité, CNIL, HDS, DORA, PCI-DSS.

Ce que nous ne faisons pas sans autorisation explicite

  • Pas de brute force, de credential stuffing, de stress test ou de fuzzing agressif.
  • Pas de création de comptes, pas d'exécution de processus métier sensibles, pas de suppression de données.
  • Pas de téléchargement ni d'extraction massive de données personnelles.
  • Pas de pivot interne, pas d'intrusion active, pas d'action assimilable à un pentest formel.

Ce que vous recevez

Revue externe

Une faille critique mise en évidence avec un scénario d'attaque très clair et une preuve de faisabilité compréhensible.

Rapport détaillé

Findings classés par criticité, impact réel, niveau de confiance, preuves, recommandations et priorités de correction.

Synthèse pour le dirigeant

Une vue exploitable côté dirigeant ou responsable produit : ce qui est grave, quoi faire maintenant, quoi planifier ensuite.

Point de remédiation

Un cadre de correction directement activable par les développeurs, avec logique de remédiation et zones à reprendre en premier.

Pages à lire ensuite

FAQ

Besoin d'une revue externe de votre SaaS RH ?

Expliquez votre produit, votre stack et votre contexte client. Nous revenons vers vous avec le bon niveau de revue.

Parler de votre audit