AUDIT DE SÉCURITÉ DE VOTRE API REST — AUTHENTIFICATION, AUTORISATIONS, INJECTIONS

───────────────────────
Et si quelqu'un pouvait payer 0 F CFA pour votre produit ?
───────────────────────

Votre site, votre application mobile, votre espace client — tout ça ne parle pas directement à votre base de données. Tout passe par une API. C'est elle qui reçoit les commandes, vérifie qui est connecté, calcule les prix, valide les paiements, et renvoie les résultats.

Le problème : une API, personne ne la voit. Elle n'a pas d'interface, pas de bouton, pas de page visible. Beaucoup d'entreprises sécurisent leur site web mais oublient complètement de tester l'API qui tourne derrière — parce qu'elle est invisible, elle semble "à l'abri des regards".

Sauf que les hackers, eux, savent exactement où chercher.

Voici un scénario réel et fréquent : votre panier calcule un prix côté site web (interface), mais c'est l'API qui reçoit la commande finale. Si l'API ne revérifie pas ce prix elle-même, et fait confiance à ce que le navigateur du client lui envoie, alors n'importe qui avec des outils gratuits et accessibles peut intercepter cette requête et changer le prix avant qu'elle n'arrive à votre serveur. Un article à 50 000 F CFA peut alors être validé pour 100 F CFA — ou 0 F CFA. La commande passe. Le paiement est "validé". Et vous ne le voyez pas, parce que dans vos logs, tout a l'air normal : une commande, un client, une transaction.

Ce n'est pas un bug rare. C'est l'une des failles les plus fréquentes sur les API de paiement mal testées, et elle ne nécessite aucune compétence de piratage avancée pour être exploitée.

C'est exactement ce type de faille — et bien d'autres — que je viens chercher avant qu'un utilisateur malintentionné ne le fasse à votre place.

───────────────────────
Ce que je teste concrètement
───────────────────────

Je m'attaque à votre API exactement comme le ferait un attaquant : je n'utilise pas l'interface prévue, j'envoie des requêtes directement, je modifie ce qui peut l'être, et j'observe ce que l'API accepte ou refuse.

Authentification
→ Est-il possible d'accéder à des données ou fonctions sans être connecté ?
→ Les jetons d'authentification (tokens) sont-ils correctement vérifiés, ou peuvent-ils être devinés, réutilisés ou falsifiés ?
→ Que se passe-t-il après une déconnexion — l'accès est-il vraiment coupé ?

Autorisations et contrôle d'accès
→ Un utilisateur connecté peut-il accéder aux données d'un autre utilisateur en modifiant simplement un identifiant dans la requête (faille IDOR) ?
→ Les droits (utilisateur normal / administrateur) sont-ils bien vérifiés à chaque appel, ou seulement à la connexion ?
→ Un utilisateur limité peut-il déclencher des actions réservées à un rôle supérieur ?

Logique métier et paiement
→ Les prix, quantités et remises sont-ils recalculés et vérifiés côté serveur, ou l'API fait-elle confiance à ce qu'elle reçoit ?
→ Est-il possible de valider une commande sans paiement réel, de dupliquer une requête pour obtenir un article deux fois, ou de contourner une étape du processus d'achat ?
→ Les webhooks et confirmations de paiement (Stripe, PayPal, mobile money, etc.) sont-ils vérifiés de façon sécurisée, ou peuvent-ils être simulés depuis l'extérieur ?

Injections et manipulation des données
→ L'API accepte-t-elle des données malformées ou malveillantes sans les filtrer (injection SQL, NoSQL, commande) ?
→ Les réponses de l'API renvoient-elles plus d'informations que nécessaire (mots de passe, tokens internes, données d'autres utilisateurs) ?

Configuration et exposition
→ La documentation technique de l'API (Swagger, endpoints internes) est-elle accessible publiquement alors qu'elle ne devrait pas l'être ?
→ Les limites de requêtes (rate limiting) sont-elles en place pour empêcher les abus automatisés ?

───────────────────────
Ce que vous recevez
───────────────────────

Un rapport PDF, écrit pour être compris sans être développeur, avec en complément le détail technique pour votre équipe :

→ Chaque faille identifiée, avec son niveau de gravité (Critique / Haute / Moyenne / Faible)
→ La preuve de concept exacte — la requête utilisée et le résultat obtenu, pour que votre développeur puisse reproduire et vérifier la correction
→ Une explication en langage simple de l'impact réel pour votre activité (perte financière, fuite de données, usurpation)
→ Les recommandations de correction, classées par priorité

───────────────────────
Pourquoi me faire confiance
───────────────────────

Je participe à des programmes de bug bounty sur des plateformes internationales (YesWeHack, Bugcrowd, Intigriti), où je recherche des failles réelles sur des API et applications en production, notamment sur des logiques métier et des systèmes de paiement. Je suis également certifié CRTA. Votre API ne sera pas mon terrain d'entraînement : j'arrive avec une méthode rodée et un œil habitué à repérer les failles de logique que les scans automatiques ne détectent presque jamais.

───────────────────────
Ce que couvre l'audit selon l'offre choisie
───────────────────────

Basique — 28,61 $US
Diagnostic ciblé
→ Test de 3 endpoints prioritaires que vous identifiez (ex : connexion, panier, paiement)
→ Vérification de l'authentification et des autorisations sur ces endpoints
→ Rapport PDF court avec failles et niveau de gravité
→ Délai : 3 jours

Standard — 91,56 $US (le plus commandé)
Audit complet de l'API
→ Test de l'ensemble des endpoints accessibles de l'API
→ Authentification, autorisations, injections, logique métier et paiement testés en profondeur
→ Preuves de concept pour chaque faille confirmée
→ Rapport PDF détaillé avec recommandations de correction
→ 1 session de questions/réponses après livraison
→ Délai : 6 jours

Premium — 171,68 $US
Audit complet + accompagnement correction
→ Tout le contenu de l'offre Standard
→ Accompagnement à la correction des failles (échanges illimités pendant 7 jours)
→ Une nouvelle vérification après correction (retest)
→ Rapport final "avant / après" utilisable pour rassurer vos clients ou investisseurs
→ Délai : 8 jours + suivi

───────────────────────
FAQ
───────────────────────

Qu'est-ce qu'une API, concrètement ?
C'est la partie invisible de votre site ou application qui traite les données en arrière-plan — connexion, commandes, paiements. Vous n'avez pas besoin de la comprendre techniquement pour commander cet audit : c'est justement mon rôle de la tester et de vous expliquer ce qui a été trouvé en langage clair.

Est-ce dangereux de tester une API en production ?
Non, si le test est réalisé avec précaution. Je privilégie autant que possible un environnement de test si vous en avez un. Si le test doit se faire en production, aucune donnée n'est modifiée ou supprimée, et les actions à risque (comme une tentative de paiement à 0 F CFA) sont réalisées de façon contrôlée et immédiatement signalées, jamais exploitées au-delà de la preuve nécessaire.

J'ai un système de paiement, est-ce inclus ?
Oui, la logique de paiement fait partie des points testés en priorité, notamment la vérification des prix côté serveur et la validation des confirmations de paiement. C'est l'un des points les plus critiques et les plus souvent négligés.

Dois-je fournir la documentation technique de l'API ?
Si vous en avez une (Swagger, Postman collection, documentation interne), cela accélère l'audit. Si vous n'en avez pas, je peux la reconstruire moi-même en observant le trafic de votre application, mais cela peut allonger légèrement le délai.

Est-ce légal ?
Oui, à condition que vous soyez propriétaire de l'API ou que vous ayez donné une autorisation explicite. Une confirmation écrite est demandée avant le début de toute mission.

Que se passe-t-il si aucune faille critique n'est trouvée ?
Vous recevez tout de même le rapport complet avec les points vérifiés et des recommandations de renforcement préventif.