Phoenix Security

Tests d’intrusion, prouvés à la main.

Applications web, API, réseaux et applications mobiles, testés à la main. Chaque vulnérabilité est livrée avec la requête, la réponse et la correction.

Demander un devis Voir les cinq services

1 Services

Cinq types de test. Chacun indique ce qu’il couvre et ce dont nous avons besoin de votre part, pour les comparer côte à côte.

ServiceCe que nous testonsCe que vous fournissez
1.1Application webDétails Contrôle d’accès entre utilisateurs et rôles, injections, logique métier, sessions, envoi de fichiers et configuration. D’abord sans compte, puis avec un compte par rôle. Les URL dans le périmètre et un compte de test par rôle.
1.2APIDétails Autorisation au niveau des objets et des fonctions, jetons et authentification, affectation de masse, limites de débit et traitement des entrées, en REST comme en GraphQL. Un fichier OpenAPI ou une collection Postman, et des clés pour chaque rôle.
1.3Réseau externeDétails Tout ce que vous exposez sur internet : hôtes, services ouverts, VPN et accès à distance, messagerie, interfaces d’administration oubliées et fichiers restés en ligne. Vos plages IP et vos domaines, et l’accord écrit de chaque hébergeur.
1.4Réseau interneDétails Ce qu’un attaquant atteint depuis un premier accès interne : Active Directory, élévation de privilèges, mouvement latéral et cloisonnement entre les zones. Un accès VPN ou une machine sur le réseau, et un compte utilisateur standard.
1.5Application mobileDétails Applications iOS et Android et l’API qui les sert : stockage local, épinglage de certificat, parcours de connexion, secrets dans le build, liens profonds. Le build (IPA ou APK) ou le lien du store, et des comptes de test.

2 Méthode

Les outils trouvent la surface. Ils ne concluent jamais. Chaque étape ci-dessous se fait à la main, dans cet ordre.

  1. 2.1

    Cadrer et signer

    Nous fixons les cibles, les fenêtres de test et les personnes à appeler. Vous signez l’autorisation. Aucune requête n’atteint vos systèmes avant cela.

  2. 2.2

    Tester sans accès

    Un premier passage sans compte ni information interne, comme commence un attaquant externe.

  3. 2.3

    Tester avec des comptes

    Un second passage avec un compte par rôle. Chaque rôle tente d’atteindre ce qui appartient à un autre.

  4. 2.4

    Prouver

    Chaque vulnérabilité est exploitée ou démontrée, avec la requête, la réponse et une capture d’écran. Ce que nous ne pouvons pas reproduire est signalé comme une observation, pas comme une vulnérabilité.

  5. 2.5

    Rapport

    Vous recevez le rapport complet à la fin du test.

  6. 2.6

    Contre-test

    Une fois les corrections faites, un contre-test vérifie chaque vulnérabilité et vous remet une attestation.

3 Preuves

Voici à quoi ressemble une vulnérabilité dans nos rapports. La preuve est à côté de l’affirmation, pour que vos développeurs puissent la rejouer et vos responsables comprendre ce qu’elle signifie.

Phoenix Security

Rapport de test d’intrusion

Exemple de vulnérabilité

Tout utilisateur connecté peut lire les factures de n’importe quel client

Gravité : Élevée

Un client change un identifiant de facture et lit celle d’un autre client.

Lire la vulnérabilité complèteMasquer la vulnérabilité complète
Faiblesse
CWE-639
CVSS 4.0
AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Trouvée en
Test avec des comptes (2.3)
Statut
Prouvée

Preuve

  1. 1Nous sommes connectés en tant qu’utilisateur 1042, un client ordinaire.
  2. 2Nous demandons la facture 88213 en changeant un seul nombre dans l’URL.
  3. 3Le serveur la renvoie. Elle appartient au client 2291, avec son nom et ses coordonnées bancaires.
Figure 1. Requête
GET /api/v2/invoices/88213 HTTP/2Host: app.example-saas.comCookie: session=7f3a…c91eAccept: application/json
Figure 2. Réponse
HTTP/2 200 OKContent-Type: application/json {  "invoice_id": 88213,  "customer_id": 2291,  "customer_name": "             ",  "iban": "FR76                0189",  "amount_due": 18400.00}

Correction

  1. Appliquer le contrôle d’autorisation au niveau objet côté serveur. Charger la facture, puis comparer son identifiant de compte à celui de la session de l’appelant avant de renvoyer la moindre donnée.
  2. Renvoyer 404 Not Found quand le contrôle échoue, pour que la réponse ne confirme pas l’existence de la facture.
  3. Placer le contrôle dans une couche partagée (middleware ou accès aux données) et l’appliquer à chaque point d’accès qui reçoit un identifiant d’objet, pas route par route.
  4. Ajouter un test de non-régression qui demande la facture d’un autre compte et attend 404.
  5. Chercher dans les journaux d’accès les demandes de factures hors du compte de l’appelant, pour savoir si la faille a été utilisée avant la correction.

Des identifiants aléatoires comme les UUID rendent la faille plus difficile à trouver. Ils ne la corrigent pas.

Contre-test

Demander la facture 88213 en tant qu’utilisateur 1042. Résultat attendu : 404, aucune donnée de facture.

Références

OWASP Top 10:2025, A01 Broken Access Control. OWASP ASVS 5.0, exigence 8.2.2.

Rédigé pour cette page. Non tiré d’un rapport client. Les données personnelles sont aussi masquées dans les vrais rapports.

4 Livrables

Vous recevez des documents sur lesquels vos développeurs peuvent agir et que votre direction peut valider.

DocumentContenuPour
Rapport techniqueChaque vulnérabilité avec son chemin d’exploitation, sa preuve, son score CVSS 4.0, sa CWE et sa correction.Développeurs, DSI
Rapport de synthèseCinq à huit pages sur le risque métier, en langage clair.Direction, conseil d’administration
Plan de remédiationLes vulnérabilités classées par ordre de correction.DSI, chefs de projet
RestitutionUne séance à distance pour parcourir les résultats et répondre aux questions.Les deux
Attestation de contre-testLa preuve que les vulnérabilités ont été corrigées.Auditeurs, clients

  • Rapport technique

    Contenu
    Chaque vulnérabilité avec son chemin d’exploitation, sa preuve, son score CVSS 4.0, sa CWE et sa correction.
    Pour
    Développeurs, DSI

  • Rapport de synthèse

    Contenu
    Cinq à huit pages sur le risque métier, en langage clair.
    Pour
    Direction, conseil d’administration

  • Plan de remédiation

    Contenu
    Les vulnérabilités classées par ordre de correction.
    Pour
    DSI, chefs de projet

  • Restitution

    Contenu
    Une séance à distance pour parcourir les résultats et répondre aux questions.
    Pour
    Les deux

  • Attestation de contre-test

    Contenu
    La preuve que les vulnérabilités ont été corrigées.
    Pour
    Auditeurs, clients

Pour les entreprises réglementées : les rapports peuvent être séparés par entité, pour que chacune réponde à son propre régulateur. Les rapports sont rédigés en anglais ou en français.

5 Règles d’engagement

Elles s’appliquent à chaque test, quel que soit le client.

  1. 5.1

    Aucun test ne commence avant la signature de l’autorisation. Le périmètre est ce que le document nomme, rien de plus.

  2. 5.2

    Les tests partent d’adresses IP fixes communiquées à l’avance, dans des fenêtres convenues, pour que votre équipe puisse nous distinguer d’une vraie attaque.

  3. 5.3

    Aucun déni de service. Aucune donnée n’est modifiée ni supprimée. Aucune donnée client réelle n’est extraite. Les preuves sont réduites au minimum et masquées.

  4. 5.4

    Le test s’arrête et votre contact est appelé si nous atteignons des données personnelles en clair, prenons le contrôle d’un système de production ou constatons un effet sur la disponibilité.

6 Société

Phoenix Security est une société de tests d’intrusion. Les testeurs qui cadrent votre test sont ceux qui le mènent et signent le rapport.

Recherche

Plusieurs vulnérabilités critiques dans un logiciel de déclaration d’impôts utilisé par des millions de personnes aux États-Unis. Signalées à l’éditeur, qui les corrige.

Nom non communiqué jusqu’à la publication du correctif, dans le cadre d’une divulgation coordonnée.

Certifications

CertificationPortéeOrganisme
OSEPÉvasion et intrusion dans des réseaux défendusOffSec
OSCPTest d’intrusion pratique, examen chronométréOffSec
CRTOOpérations red teamZero-Point Security
PenTest+Méthode, cadrage, rapportCompTIA

7 Demander un devis

Dites-nous ce qu’il faut tester. La réponse vient d’un testeur, pas d’une équipe commerciale.

Que devons-nous tester ?

Nombre d’applications ou de plages IP, rôles utilisateurs, échéance, et pourquoi maintenant (un client, un audit, un régulateur).