Business Logic Flaws

Qu'est-ce qu'une faille de logique métier#

Une faille de logique métier est une vulnérabilité dans le workflow prévu de l'application plutôt que dans son traitement d'entrée, son parsing ou sa plomberie de contrôle d'accès. Les requêtes paraissent syntaxiquement valides, passent l'authentification et ne contiennent aucun payload d'injection. L'attaquant utilise l'application exactement telle qu'elle est conçue — simplement dans une séquence, une combinaison ou une magnitude que les développeurs n'avaient jamais anticipées.

Les exemples canoniques sont partout : appliquer une remise en pourcentage après avoir manuellement mis le prix du panier à zéro, commander un article quantity=-5 pour recevoir un crédit, naviguer directement vers /checkout/confirm sans jamais finaliser le paiement, et faire courir 30 requêtes concurrentes contre un code promo max_redemptions=1 pour drainer une fenêtre de transactions sans frais de 600 000 $. Aucun ne fait intervenir une liste de payloads. Chacun exige de comprendre ce que l'application est censée faire, puis de faire l'inverse.

La taxonomie a mûri. La classification primaire chez MITRE est CWE-840 (Business Logic Errors), avec des sous-classes pour CWE-841 (Improper Enforcement of Behavioral Workflow) et CWE-915 (Mass Assignment / Improperly Controlled Modification of Object Attributes). L'OWASP Top 10 mappait historiquement la logique métier à A04:2021 Insecure Design ; dans OWASP Top 10:2025, cette catégorie a été renumérotée A06:2025 Insecure Design et nomme explicitement « missing business constraint validation » comme sous-catégorie, comblant une lacune documentaire qui faisait paraître le cadre OWASP limité aux dessins architecturaux plutôt qu'au respect des règles à l'exécution.

L'événement taxonomique le plus important de 2025 fut la publication du premier OWASP Top 10 for Business Logic Abuse (BLA) dédié à AppSec Global EU à Barcelone le 30 mai 2025, avec une v2 rafraîchie le 2 août 2025. Le framework modélise les applications comme des machines de Turing abstraites (ruban, tête, états, transitions) et fut validé en classifiant par LLM 76 000 CVE de 2023–2025 plus 25 000 problèmes de sécurité GitHub. Le résultat est la première taxonomie cross-domaine qui traite la logique métier non comme une catégorie de bug, mais comme une classe de comportement système qu'il faut raisonner formellement. Les catégories vont de BLA1 Action Limit Overrun à BLA10 Shadow Function Abuse, et absorbent proprement l'ancien catalogue OWASP WSTG-BUSL-01..10.

Cette page est la référence pilier. Elle définit la classe, passe en revue les six variantes d'attaque à maîtriser, résume l'état de l'art issu de la recherche 2024–2026, et renvoie aux deep dives dédiés à chaque variante.

Pourquoi les scanners automatisés les ratent#

Les tests dynamiques de sécurité d'application (DAST) traditionnels — ZAP, Burp Scanner, templates Nuclei communautaires — atteignent une détection proche de zéro sur les véritables failles de logique métier. La raison structurelle comporte cinq composantes, et elles se cumulent :

1. Aucune signature statique n'existe. Un amount=-1000 négatif n'est une vulnérabilité que si l'application l'accepte et crédite le compte. Scanner le nom du paramètre ne dit rien sur l'exploitabilité. Comparez avec l'injection SQL, où ' OR 1=1-- produit un signal différentiel déterministe.
2. Le contexte est spécifique à l'application. Savoir si POST /api/checkout/confirm sans appel /api/checkout/payment préalable est un bug dépend entièrement de la machine à états du checkout — qu'un scanner générique ne peut pas modéliser sans ingérer le workflow prévu de l'application.
3. La preuve exige une vérification d'état. Confirmer que « le transfert négatif a crédité le compte » exige de lire le solde avant et après, dans deux sessions séparées, avec le bon contexte d'authentification. Les scanners génériques ne suivent pas l'état applicatif entre requêtes.
4. Workflows multi-étapes. Les exploits réels exigent souvent 3 à 10 requêtes coordonnées avec cookies partagés, jetons CSRF rafraîchis et contraintes d'ordre. Le fuzzing à requête unique (modèle de chaque DAST commodity) ne peut pas les reproduire.
5. Les race conditions dépendent du timing. Une race de rachat de coupon qui fonctionne de manière fiable en labo peut échouer sous gigue réseau. Une détection fiable exige l'attaque single-packet HTTP/2 (Kettle 2023) — requêtes concurrentes livrées dans une seule rafale TCP, et non des sondes séquentielles.

Une nouvelle génération d'outils a émergé en 2025–2026 pour attaquer cette lacune. Pynt, Escape DAST et StackHawk Business Logic Testing (BLT) — lancé le 16 décembre 2025 — utilisent un crawling intelligent piloté par OpenAPI, une configuration multi-utilisateur basée sur les rôles, et une orchestration de tests pilotée par feedback pour détecter automatiquement les failles Broken Object Level Authorization (BOLA) et Broken Function Level Authorization (BFLA). Ils ne couvrent pas encore la manipulation de prix, les race conditions, les attaques de bornes ou le contournement de workflow ; cela exige toujours soit des moteurs de règles YAML personnalisés (l'approche BreachVex), soit des pentesters humains avec Burp Repeater + Turbo Intruder, soit une détection guidée par spécification assistée par LLM (GPTScan 2024, IRIS arXiv:2405.17238).

Taxonomie — 6 variantes principales#

Les six variantes ci-dessous couvrent la majorité des découvertes de logique métier divulguées publiquement entre 2020 et 2026. Chacune a une page deep dive dédiée avec des walkthroughs d'attaque, des CVE réels, des exemples de code et des patterns de remédiation.

Manipulation de prix#

L'application accepte un prix, une quantité, un total ou une devise fournis par le client sans re-validation contre le catalogue produit côté serveur. L'attaquant intercepte la requête d'ajout au panier ou de checkout et substitue price: 0.01 (ou currency: "BTC" contre un catalogue USD). Le serveur traite la commande à la valeur contrôlée par l'attaquant. Le lab PortSwigger « Excessive Trust in Client-Side Controls » le démontre exactement. Les cas réels incluent CVE-2025-56426 (Bagisto CMS, avril 2025, CVSS 8.1, patché en 2.2.3) et HackerOne #614523 (Eternal e-commerce — montant de commande manipulable via la soumission du panier).

Lire le deep dive sur la manipulation de prix

Abus de quantité négative#

Une spécialisation de la manipulation de prix : l'attaquant soumet quantity: -5 (ou une valeur qui wrappe via un overflow INT32/INT64, comme 2147483648). Si le serveur multiplie unit_price * quantity sans validation de signe, le total de la ligne devient négatif et réduit le total du panier — parfois en dessous de zéro. CVE-2023-45854 (Shopkit 1.0, CVSS 7.5) est le cas d'école : le paramètre qtd acceptait INT32_MAX+1 et wrappait vers un total de panier négatif. HackerOne #364843 (Upserve/OLO) rapporte exactement la même classe contre une grande plateforme de commande de restaurant.

Lire le deep dive sur l'abus de quantité négative

Empilement de coupons#

Les coupons, codes promo et cartes-cadeaux sont prévus pour un usage unique, mais la logique de déduplication ne vérifie que le code immédiatement précédent (ou pas du tout). Appliquer le coupon A, puis le coupon B, puis le coupon A à nouveau ré-applique souvent la remise. Le lab PortSwigger « Flawed Enforcement of Business Rules » démontre le contournement par alternance de coupons. Leur lab « Infinite Money » démontre le cycle carte-cadeau : acheter une carte-cadeau de 10 $ avec une remise de 10 % → 9 $ dépensés net → racheter 10 $ → profit de 1 $ par cycle, à l'infini. HackerOne #59179 (Dropbox) et HackerOne #157996 (Instacart, variante race condition) sont des cas réels canoniques.

Lire le deep dive sur l'empilement de coupons

Contournement d'étape de workflow#

Un processus multi-étapes — inscription, checkout, upgrade d'abonnement, remboursement — est implémenté en exposant chaque étape comme son propre endpoint HTTP. L'attaquant appelle l'endpoint final directement sans finaliser les prérequis. Exemple classique : POST /checkout/confirm {order_id: X} depuis une session fraîche. Si le serveur retourne HTTP 200 avec le corps de confirmation de commande, le paiement a été contourné. HackerOne #271176 (Lyst, 2017) a sauté l'étape de paiement en forgeant checkout_id dans un cookie. HackerOne #92481 (Shopify) a accédé à l'ajout de méthode de paiement sans checkout prérequis. Le problème Magento2 PayPal « Bill Me Later » (#39145) contournait entièrement le checkout via une séquence d'API spécifique. Cette classe est mappée à CWE-841 et OWASP BLA2:2025 Concurrent Workflow Order Bypass (CWOB).

Lire le deep dive sur le contournement d'étape de workflow

Dépassement de limite#

L'application fait respecter les limites « one per user » ou « max N per day » dans la couche applicative (vérification Python, puis insert en base) sans garde atomique. Les requêtes concurrentes contournent la limite parce que la vérification s'exécute avant que l'un ou l'autre des inserts ne soit committé. La cible d'école est les coupons à usage unique et les jetons de vérification. HackerOne #1717650 (Stripe) — un code promo max_redemptions=1 racheté 30 fois en parallèle, donnant 600 000 $ de transactions sans frais (payout : 5 000 $). CVE-2025-31161 (CrushFTP) — race condition dans l'authentification permettant un Concurrent Workflow Order Bypass, activement exploité. La classe est mappée à CWE-362 et OWASP BLA1:2025 Action Limit Overrun (ALO).

Lire le deep dive sur le dépassement de limite

Abus d'arrondi monétaire#

Moins courant mais à fort impact lorsqu'il est présent : une application effectue de l'arithmétique en virgule flottante sur des valeurs monétaires (0.1 + 0.2 != 0.3 en IEEE 754), accepte des micro-montants (0.001) qui s'arrondissent à zéro à l'affichage mais s'accumulent en stockage, ou accepte plusieurs devises (USD, BTC, JPY) sans canonisation. L'attaquant draine soit l'erreur d'arrondi accumulée par micro-transactions répétées (attaque Office Space), soit exploite des mismatches de devises où des prix en USD sont facturés à la même valeur numérique en JPY (1/100e du prix). La règle de discipline classique : ne jamais utiliser la virgule flottante pour l'argent.

Lire le deep dive sur l'abus d'arrondi monétaire

Techniques d'attaque état de l'art (2024-2026)#

Le paysage de la recherche pour l'exploitation de logique métier a bougé plus vite entre 2023 et 2026 que dans toute la décennie précédente. Trois flux ont remodelé le domaine.

Attaque single-packet HTTP/2 — James Kettle, Black Hat USA / DEF CON 2023#

Dans Smashing the State Machine: The True Potential of Web Race Conditions, James Kettle (PortSwigger Research) a introduit l'attaque single-packet : livrer toutes les requêtes concurrentes dans une seule rafale de trame HTTP/2, éliminant la gigue réseau comme variable confondante.

L'amélioration de performance est de 4 à 10x par rapport à la synchronisation last-byte HTTP/1.1 antérieure. Une vulnérabilité réelle est passée d'« exploitable en 2+ heures » (HTTP/1.1) à « exploitable en 30 secondes » (single-packet HTTP/2). Les requêtes concurrentes courent désormais contre les sous-états internes de l'application — états intermédiaires qui n'existent que pendant le traitement d'une seule requête, durant environ 1 ms.

En août 2024, le chercheur @ryotkak a publié Beyond the Limit: Expanding single-packet race condition with a first sequence sync, qui utilise la fragmentation au niveau IP pour étendre la fenêtre d'attaque du MTU de 1 500 octets à la fenêtre TCP complète de 65 535 octets. Le résultat : 10 000 requêtes synchronisées en environ 166 millisecondes. Implémentation : h2spacex open-source (basé Scapy) et Turbo Intruder avec engine=Engine.BURP2.

Cinq classes d'attaque de Smashing the State Machine#

L'article de Kettle de 2023 a introduit quatre classes d'attaque de race condition entièrement nouvelles au-delà du dépassement de limite classique :

1. Object Masking — Exploiter les états intermédiaires pendant la création d'un objet. L'objet existe mais n'est pas encore complètement initialisé. Une requête en course observe l'objet incomplet et contourne la validation qui se déclencherait sur la version finalisée.
2. Multi-endpoint Collisions — Faire courir deux endpoints différents qui touchent la même ressource partagée. Exemple : POST /transfer en course avec GET /balance où les deux lisent la même ligne sous des sémantiques de verrouillage différentes.
3. Single-endpoint Collisions — Le dépassement de limite classique : race de coupon, race de carte-cadeau, race de vote.
4. Deferred Collisions — Vulnérabilités de traitement par lots exploitables avec des délais temporels, pas des microsecondes. La fenêtre de race peut s'étendre sur des heures. Particulièrement précieux contre les applications placées derrière un CDN où des requêtes simultanées sont impossibles.
5. Partial Construction Attack — Attaquer l'initialisation multi-étape d'un objet avant que tous les champs ne soient écrits.

Listen to the Whispers — Black Hat USA 2024#

Le suivi de Kettle en 2024, Listen to the Whispers: Web Timing Attacks That Actually Work, militarise les différentiels de timing à l'échelle de la microseconde. Avancées clés sur 2023 :

• Découverte de surface d'attaque cachée via timing : l'analyse du temps de réponse détecte les paramètres et en-têtes HTTP dissimulés qui ne produisent aucun signal de réponse visible — révélant la « surface d'attaque invisible » où les portes de logique métier existent mais n'émettent rien d'autre que de la latence.
• Injection aveugle via timing : détection d'injection SQL, d'injection JSON et de pollution de paramètres lorsqu'aucun message d'erreur n'est retourné. Le timing révèle la divergence de flux de contrôle (une requête scannant 1 M de lignes vs 1 ligne prend mesurablement plus de temps, même à travers un CDN).
• Découverte SSRF restreinte : les reverse proxies qui restreignent le routage à des domaines spécifiques sont désormais détectables via timing là où la détection par pingback échoue entièrement.
• Réduction de gigue : de 30 000 microsecondes (HTTP/1.1 naïf) à 200 microsecondes (single-packet HTTP/2) — viable contre des cibles de production live sans conditions de labo.

Vecteurs de logique métier GraphQL#

GraphQL fait émerger des vecteurs d'attaque BL uniques que les détecteurs orientés REST ratent. 50 % des endpoints GraphQL en production acceptent toujours les requêtes d'introspection (vérifié sur les enquêtes 2024–2025), révélant les noms de mutations internes, les types d'arguments et les structures de champ qui mappent directement aux flux de logique métier. Catégories d'attaque spécifiques à GraphQL :

• Chaînage de mutations : plusieurs mutations dans un seul payload s'exécutent séquentiellement avec un contexte d'authentification partagé. createUser(role: "ADMIN") + grantPermission() peuvent passer individuellement l'autorisation mais constituer ensemble une élévation de privilège.
• Mutations admin exposées : deleteUser, resetPassword, generateJWT, modifyRole — fréquemment dépourvues de vérifications d'autorisation et appelables par tout utilisateur authentifié.
• Race conditions sur alias de champ : les alias de champ GraphQL permettent de demander le même champ plusieurs fois avec des arguments différents en une seule requête. Toutes les sous-requêtes s'exécutent côté serveur dans un contexte de transaction partagé — un mécanisme efficace de race condition qui n'exige même pas HTTP/2.

Impact réel#

La sélection ci-dessous mêle le cas canonique de chaque variante avec les CVE 2025 les plus activement exploités pour illustrer l'échelle financière.

Le pattern financier est cohérent : les failles de logique métier commandent régulièrement les payouts les plus élevés en bug bounty. Shopify paie 25 K$ – 150 K$ pour la manipulation de prix au checkout, GitLab 20 K$ – 80 K$ pour le contournement de workflow d'autorisation, et Uber 10 K$ – 50 K$ pour l'abus de logique de prix. Le secteur crypto et blockchain paie encore plus — des découvertes uniques de logique métier contre des protocoles DeFi majeurs ont été divulguées entre 50 K$ et 500 K$.

Méthodologie de détection#

Pentest manuel#

Le workflow manuel professionnel combine quatre outils :

1. Burp Suite Repeater — établir la requête/réponse de référence, puis rejouer avec des paramètres altérés un à la fois. Burp Repeater Groups (mise à jour 2024) supporte nativement l'attaque single-packet via « Send group in parallel ».
2. Turbo Intruder — l'outil canonique pour les attaques de race HTTP/2. Utilisez le template race-single-packet-attack.py avec engine=Engine.BURP2, concurrentConnections=1 et synchronisation par gate.
3. h2spacex — bibliothèque open-source basée Scapy pour la synchronisation last-frame HTTP/2 avec l'extension 65535-octets de @ryotkak. Requise lorsque vous avez besoin de 1 000+ requêtes synchronisées pour l'épuisement de jetons ou le rachat massif de cartes-cadeaux.
4. Param Miner (timing-based) — découverte de paramètres et d'en-têtes cachés qui ne produisent aucun signal de réponse visible mais affectent le comportement serveur, révélant les portes de logique métier. Mis à jour en 2024 avec la découverte par timing intégrée.

La méthodologie : cartographier le workflow → identifier les transitions d'état → altérer un paramètre numérique/d'état à la fois → vérifier le changement d'état via un GET de suivi vers l'endpoint solde/commande/compte approprié → escalader vers des requêtes concurrentes lorsque l'ordre compte.

Outils automatisés modernes (2025-2026)#

La limitation structurelle commune à tous : la preuve exige une vérification d'état spécifique à l'application. Aucun des scanners commodity ne construit un dictionnaire de preuve state_before / state_after par découverte. Un 200 OK générique n'est pas une preuve — la confirmation exige un GET de suivi vers l'endpoint solde/commande/inventaire approprié qui démontre que la valeur altérée a persisté.

BreachVex détecte cette classe via un moteur de règles YAML personnalisé qui encode les endpoints de vérification d'état par règle, une sonde post-tampering qui compare l'état de la ressource avant et après la requête, et un modèle de preuve default-deny qui élève une découverte à CONFIRMED uniquement lorsqu'un véritable changement d'état côté serveur est observé. Le ruleset par défaut couvre transfert négatif, produit à prix zéro, stacking de coupons, contournement de workflow, mass assignment, integer overflow, réutilisation d'idempotence, multiplication de cartes-cadeaux et réactivation d'essai gratuit, et est auto-généré depuis les specs OpenAPI au moment du scan — sans curation humaine requise pour les cibles e-commerce ou API standard.

Principes de prévention#

Les quatre principes ci-dessous sont les correctifs structurels qui ferment chaque variante de cette page. Les détails au niveau du code se trouvent dans la page deep dive de chaque variante ; les principes eux-mêmes sont uniformes.

Autorité côté serveur#

Ne jamais faire confiance à une valeur que le client soumet et qui affecte le prix, la quantité, le rôle, le statut ou l'état du workflow. Toujours re-fetch la valeur canonique côté serveur depuis le catalogue, l'enregistrement utilisateur ou l'état de commande.

# BAD: price comes from the client
@router.post("/cart/add")
async def add_to_cart(item: CartItemInput):
    cart.add(item.product_id, item.quantity, item.price)
 
# GOOD: price fetched server-side from the authoritative catalog
@router.post("/cart/add")
async def add_to_cart(item: CartItemInput):
    product = await catalog.get_product(item.product_id)
    cart.add(item.product_id, item.quantity, product.current_price)

Le client est autorisé à soumettre product_id et quantity (avec validation de bornes). Tout le reste — prix, devise, taxe, livraison, rôle, statut — est calculé côté serveur depuis le stockage faisant autorité.

Transitions d'état atomiques#

Toute opération state-changing doit s'exécuter dans une seule transaction atomique avec verrouillage explicite au niveau ligne. L'erreur classique est « check then act » sans verrouiller la ligne entre la vérification et l'action — la race TOCTOU canonique.

-- BAD: SELECT then UPDATE — race window between the two statements
SELECT redeemed FROM coupons WHERE code = 'SAVE10';  -- returns false
UPDATE coupons SET redeemed = true WHERE code = 'SAVE10';
 
-- GOOD: SELECT FOR UPDATE locks the row for the duration of the transaction
BEGIN;
SELECT redeemed FROM coupons WHERE code = 'SAVE10' FOR UPDATE;
UPDATE coupons SET redeemed = true WHERE code = 'SAVE10' AND redeemed = false;
COMMIT;
 
-- BETTER: single atomic UPDATE that returns the row only on success
UPDATE coupons
SET redeemed_by_order = $1
WHERE code = $2 AND redeemed_by_order IS NULL
RETURNING amount;

La forme RETURNING est la défense la plus propre : un seul énoncé qui réussit au plus une fois sur toutes les transactions concurrentes, indépendamment de la manière dont le code applicatif est écrit.

Clés d'idempotence#

Les opérations qui ne doivent pas s'exécuter deux fois (transferts, débits, placement de commande) exigent une clé d'idempotence fournie par le client et stockée côté serveur. Les replays de la même clé retournent la réponse en cache au lieu de ré-exécuter. C'est le pattern de l'API Stripe (en-tête Idempotency-Key) et c'est la défense standard de l'industrie contre le paiement dupliqué, le double remboursement et les races de soumission concurrente.

@router.post("/transfer")
async def transfer(req: TransferRequest, idem_key: str = Header(...)):
    cached = await cache.get(f"idem:{idem_key}")
    if cached:
        return cached  # replay returns cached response
    # execute transfer atomically
    result = await db.execute_transfer(req)
    await cache.set(f"idem:{idem_key}", result, ttl=86400)
    return result

Application de machine à états#

Tout workflow multi-étapes — inscription, checkout, remboursement, KYC — doit être modélisé comme une machine à états finis explicite avec validation de transition côté serveur. L'état vit en base de données (ou Redis), pas dans le cookie client ou un champ caché de formulaire, et chaque transition est vérifiée contre une allow-list avant d'être appliquée.

VALID_TRANSITIONS = {
    "cart":     ["shipping"],
    "shipping": ["payment"],
    "payment":  ["confirm"],
    "confirm":  ["complete"],
}
 
@router.post("/checkout/{step}")
async def checkout_step(step: str, session: Session = Depends(get_session)):
    current = await redis.get(f"checkout:{session.id}:state") or "cart"
    if step not in VALID_TRANSITIONS.get(current, []):
        raise HTTPException(400, f"Cannot transition from {current} to {step}")
    # ... process step ...
    await redis.set(f"checkout:{session.id}:state", step)

C'est le correctif structurel pour le contournement d'étape de workflow et le SPA Workflow Skip. Les requêtes directes vers /checkout/confirm depuis une session fraîche échouent à la garde de transition — l'utilisateur n'a aucun état payment depuis lequel avancer.

Ressources#

• OWASP Top 10 for Business Logic Abuse (BLA) — Première publication le 30 mai 2025
• OWASP Top 10:2025 — A06 Insecure Design
• OWASP WSTG — Business Logic Testing (BUSL-01 à BUSL-10)
• PortSwigger Research — Smashing the State Machine (James Kettle, 2023)