CORTEX AI™ SAS
CORTEX ORIGIN™
CFVL-IDOR-PRES-001 V0.2 · JUIN 2026 · RUST · 166 TESTS VERTS
CORTEX IDOR™
PRODUIT DÉFENSIF — PASSERELLE D’AUTORISATION EN COUPURE
L’AUTORISATION PAR CONSTRUCTION · ANTI-IDOR / BOLACORTEX IDOR™
Passerelle bolt-on en coupure — sans modification de l’application
Jeton de capacité lié au mandant · owner-check · pré-autorisation fail-closed
Pile d’autorisation : objet (BOLA) · fonction (BFLA) · champ · débit — toutes fail-closed
Audit tamper-evident + ancrage externe · plan admin séparé · TLS · JWKS
Jeton de capacité lié au mandant · owner-check · pré-autorisation fail-closed
Pile d’autorisation : objet (BOLA) · fonction (BFLA) · champ · débit — toutes fail-closed
Audit tamper-evident + ancrage externe · plan admin séparé · TLS · JWKS
CIBLE OWASP #1 — WEB & API
CONTRÔLE COMPENSATOIRE
BOLT-ON · SANS MODIF APP
OBSERVE → ENFORCE
ANTI-PLACEBO · MUTATION-PROUVÉ
FAIL-CLOSED PAR DÉFAUT
CSPN EN TRAJECTOIRE
FRANCE DEEPTECH
166
TESTS VERTS
0
MODIFICATION DE L’APP
14
PROPRIÉTÉS MUTATION-PROUVÉES
17
MODULES
AEAD
JETON LIÉ AU MANDANT
CWE-639
IDOR / BOLA — CŒUR
En cours — latence : pilote · pentest tiers & CSPN : trajectoire
01À QUOI ÇA SERT — IDOR / BOLA
Le problème : on change l’identifiant, on lit les données d’un autre
Une faille IDOR/BOLA, c’est une application qui sert un objet parce qu’on en donne le nom — sans vérifier que l’utilisateur a le droit de le voir. Un utilisateur connecté modifie un identifiant dans l’URL (/api/factures/12345 → 12346) et accède aux données d’autrui. C’est la faille n°1 du top OWASP API, et la cause directe de plusieurs fuites massives récentes.
Invisible aux défenses classiques
Le trafic est authentifié et légitime en apparence. Ni le WAF, ni l’EDR, ni le 2FA ne le voient : ils protègent l’authentification, pas l’autorisation. C’est une faille de logique, pas une signature.
Le scénario type
Identifiants volés → connexion légitime → l’identifiant de ressource est un compteur → incrément automatisé sur des dizaines de milliers de requêtes → exfiltration massive. Aucun malware.
Ce que fait CORTEX IDOR : il se pose devant votre application et remplace chaque identifiant d’objet par un jeton opaque lié à l’utilisateur — l’énumération devient impossible par construction — puis vérifie, objet par objet, que l’utilisateur a bien le droit d’y accéder. Sans modifier votre code.
02LE MARCHÉ — LA CATÉGORIE N°1, PARTOUT
Pas une niche : la faiblesse n°1 des applications, et des API
Toute organisation expose des API. Or leur principale faiblesse n’est pas une signature exotique — c’est le contrôle d’accès cassé, et sa forme la plus courante est le BOLA / IDOR. CORTEX IDOR cible exactement cette catégorie : une faiblesse structurelle et quasi universelle, pas une niche technique.
95 %
des attaques d’API proviennent de sessions authentifiées. L’angle mort n’est pas l’authentification — c’est l’autorisation. L’attaquant est déjà connecté, avec un jeton valide ; ni le WAF, ni le 2FA, ni l’IdP ne voient rien. C’est précisément la couche où agit CORTEX IDOR.CybelAngel — API Threat Report 2025
N°1
OWASP TOP 10 : 2025 — BROKEN ACCESS CONTROL (INCHANGÉ DEPUIS 2021)
100%
DES APPLICATIONS TESTÉES PRÉSENTENT UNE FORME DE CONTRÔLE D’ACCÈS CASSÉ — OWASP 2025
N°1
OWASP API SECURITY TOP 10 — BOLA, EN TÊTE DEPUIS 2019
~40%
DES ATTAQUES D’API SERAIENT DU BOLA — ESTIMATION SECTEUR
La logique tient en quatre maillons : toutes les entreprises ont des API → leur principale faiblesse est le contrôle d’accès → sa manifestation n°1 est le BOLA / IDOR (l’OWASP assimile explicitement les deux) → CORTEX IDOR enforce précisément ce contrôle, en coupure. Tu n’adresses pas 1 % du marché cyber : tu adresses la famille de défauts classée n°1 par l’OWASP, côté web comme côté API.
Pour situer cette tranche dans le paysage complet : voici les dix risques de l’OWASP API Security Top 10 : 2023, avec la couverture exacte de CORTEX IDOR — y compris ce qu’il ne couvre pas.
| Risque — OWASP API Security Top 10 : 2023 | CWE | Couverture | Garde / mécanisme CORTEX IDOR |
|---|---|---|---|
| API1 — Broken Object Level Authorization (BOLA / IDOR) — #1 | CWE-639 | Couvert | jeton capability + owner-check, objet par objet |
| API2 — Broken Authentication | CWE-287 / 306 / 798 | Partiel | exige & vérifie le mandant (JWT HS256/RS256 séparés, JWKS) — n’est pas un IdP |
| API3 — Broken Object Property Level Authorization (BOPLA) | CWE-915 / 200 | Couvert | allowlist de corps + masquage réponse + autorisation de champ par mandant |
| API4 — Unrestricted Resource Consumption | CWE-770 / 400 | Couvert | rate-limit par mandant (token bucket), 429 + Retry-After |
| API5 — Broken Function Level Authorization (BFLA) | CWE-862 | Couvert | scopes OAuth2 requis, fail-closed |
| API6 — Unrestricted Access to Sensitive Business Flows | CWE-799 | Partiel | rate-limit + détection atténuent l’abus à l’échelle, pas une défense anti-bot dédiée |
| API7 — Server-Side Request Forgery (SSRF) | CWE-918 | Hors périmètre | non revendiqué — détection contournable (assumé, voir encadré) |
| API8 — Security Misconfiguration | CWE-16 | Hors périmètre | fail-closed & TLS internes, mais pas un scanner de configuration |
| API9 — Improper Inventory Management | — | Partiel | le mode découverte inventorie les routes observées |
| API10 — Unsafe Consumption of APIs | CWE-20 | Hors périmètre | concerne les API tierces consommées, hors d’une passerelle en coupure |
Lecture honnête. Le classement (« n°1 ») et la prévalence (« 100 % des applications testées ») sont des données OWASP — Top 10 : 2025 et API Security Top 10 : 2023. Le « ~40 % des attaques d’API » est une estimation du secteur, pas un chiffre OWASP. Prévalence ≠ part des attaques : le défaut est extrêmement répandu, donc le marché adressable l’est aussi — sans pour autant affirmer que la majorité des attaques sont des IDOR. Et le périmètre est assumé : CORTEX IDOR est une passerelle d’autorisation. Elle couvre le cluster autorisation de l’OWASP API Top 10 (API1, API3, API4, API5) ; elle ne traite pas l’injection (SQLi / XSS — hors liste API), la sûreté mémoire ni la chaîne d’approvisionnement logicielle, qui relèvent d’autres outils (WAF, SAST, SCA). Ce périmètre net est un choix de positionnement, pas une lacune.
Repères 2025 — ce que dit la donnée récente
- 52 % des fuites d’API divulguées en 2025 sont imputées à une authentification cassée ; 27 % à une consommation d’API tierces non sûre. Wallarm — API ThreatStats (60 incidents)
- N°1 — le BOLA / IDOR reste en tête de l’OWASP API Security Top 10 depuis 2019, et le contrôle d’accès est la première cause racine des fuites d’API. OWASP 2023 · Gartner 2025
Ces chiffres mesurent des choses différentes — prévalence dans les applications, volume d’attaques, causes de fuites : c’est pourquoi aucun « % d’attaques » unique par catégorie n’est honnêtement publiable, et nous n’en inventons pas. Le fil conducteur, lui, est constant : les défauts d’autorisation et d’authentification dominent, et la quasi-totalité des attaques transitent par des sessions légitimes — là où ni le WAF ni le 2FA ne voient rien, et où CORTEX IDOR agit.
03LE CŒUR — TOKENISATION PAR CAPABILITY
L’identifiant n’est plus une cible
Le mécanisme central : la passerelle réécrit chaque identifiant d’objet exposé au client en un jeton opaque, chiffré et authentifié, lié à l’utilisateur. Le client ne manipule plus jamais d’identifiant réel ni de compteur séquentiel.
Avant
/api/factures/12345
compteur séquentiel — énumérable, réutilisable par n’importe qui
Avec CORTEX IDOR
/api/factures/cidor_9fA3kZ…
jeton opaque, lié à l’utilisateur — ni énumérable, ni transférable
En sortie (réponse)
Le client ne voit plus jamais d’identifiant réel ni de compteur. Il n’y a tout simplement plus rien à incrémenter.
En entrée (requête)
La passerelle vérifie que le jeton a bien été émis pour cet utilisateur. Le jeton de A rejoué par B est rejeté à l’ouverture.
Le jeton encode { identifiant réel · utilisateur · type · expiration }, scellé en chiffrement authentifié (AEAD, XChaCha20-Poly1305). On ne peut donc ni le forger, ni l’incrémenter, ni rejouer celui d’un autre — l’énumération est neutralisée par construction, pas seulement détectée. Et ça fonctionne sans que la passerelle ait à connaître le modèle de propriété de l’application : le jeton est la capacité. C’est le modèle de sécurité par capacités, transposé à HTTP — au cœur de l’expertise CORTEX.
04COMMENT ÇA SE BRANCHE — SANS MODIF DE CODE
Dans le chemin de la requête, en coupure devant votre app
Vous reroutez le trafic vers la passerelle ; elle traite chaque requête puis la transmet à votre application inchangée. Réversible et progressif.
Utilisateur
navigateur · app · client API
TLS
CORTEX IDOR™
détok · owner-check · audit · détection
requête validée
Votre API / App
inchangée · zéro modif de code
accès objet
Données
base · stockage
La passerelle est dans le flux : rien ne contourne le contrôle, l’application n’est pas touchée — et passerelle, app et données restent sur votre infrastructure (mode souverain possible).
Reverse-proxy
Le plus courant. Reroutage DNS ou amont du load-balancer.
Sidecar Kubernetes
Un proxy par pod ou par service, dans le mesh.
Souverain / déconnecté
Plan de contrôle local, aucune télémétrie externe.
< 1 h
Mode observation
Installé à distance, sur votre propre serveur
CORTEX déploie l’image conteneur signée à distance, directement sur votre serveur — dans votre data center, sur votre infrastructure. Vos données ne quittent jamais vos murs. La passerelle est ensuite insérée dans le flux. En mode observation, elle laisse passer 100 % du trafic et observe seulement. L’enforcement vient ensuite : c’est l’opérateur qui active chaque route, après revue des suggestions — jamais automatiquement.
Délai pour le cas conteneurisé simple. Un environnement d’entreprise complexe (préparation réseau, terminaison TLS, identification du principal) demande davantage.
Et la mise en route est progressive — chaque palier est un jalon autonome, à votre rythme :
01
Observation
Mise en coupure, zéro enforcement. La passerelle observe, ne bloque rien.
02
Cartographie
Rapport de couverture + mode découverte → routes porteuses d’objets exposées. Suggestions revues par l’humain.
03
Enforce progressif
Bascule activée par l’opérateur, route par route (virtual-patching). Jamais en bloc, jamais automatique.
04
Mesure
Couverture obtenue, faux positifs, latence p50/p99, journal d’audit traçable.
Prérequis
un point d’insertion (DNS / amont LB / sidecar)une identité de principal (JWT / cookie / en-tête)un conteneur léger
05COMMENT ÇA FONCTIONNE — À L’INTÉRIEUR DE LA PASSERELLE
Le trajet d’une requête, étape par étape
À l’aller, la passerelle identifie l’utilisateur, applique les gardes d’autorisation (toutes fail-closed), ouvre le jeton de capacité et pré-vérifie l’autorisation avant même de toucher l’amont. Au retour, elle contrôle la propriété de l’objet, filtre les champs, re-tokenise les identifiants et passe le verdict de détection.
Entrée — vers l’application
01
Extraction du principal
JWT · session · en-tête · vérifs HS256/RS256 séparées (anti-confusion d’algorithme)
02
Détok. + liaison
rejet si le jeton est celui d’un autre utilisateur
03
Gardes + pré-autorisation
auth requise (401) · scopes/BFLA (403) · débit (429) · traversal (400) · corps (422) · owner-check — l’amont n’est pas touché si refus
↕ Application / API amont (inchangée)
Sortie — retour vers le client
04
Autorisation de champ
allowlist par scope, fail-closed — le champ non autorisé (ou inconnu) disparaît
05
Tokenisation des IDs
capability — tue l’énumération par construction
06
Détection + verdict
énumération · cardinalité · débit
En asynchrone, hors du chemin critique : journal d’audit chaîné (HMAC, tamper-evident) · tableau de bord · export SIEM.
Tokenisation / capability
Autorisation (policy / owner / champ)
Détection
Identité
06EN QUOI C’EST DIFFÉRENT — VS LA CONCURRENCE
Ni un WAF, ni une passerelle d’API — de l’autorisation au niveau objet
Le WAF et l’EDR cherchent des signatures ; la passerelle d’API fait de l’authentification, du routage, de la limitation de débit. Aucun ne tranche « cet utilisateur a-t-il le droit d’accéder à cet objet, et de voir ce champ ? ». C’est précisément ce qu’enforce CORTEX IDOR — par un contrôle positif (capability + autorisation déclarée) plutôt que par la seule détection, et sans toucher au code.
| Capacité | WAF | Passerelle d’API | Correctif dans le code | CORTEX IDOR |
|---|---|---|---|---|
| Voit l’IDOR (trafic authentifié, légitime en apparence) | ✗ | ✗ | ✓ | ✓ |
| Autorisation au niveau objet (BOLA) | ✗ | ✗ | ✓ | ✓ |
| Autorisation au niveau champ (par mandant) | ✗ | ✗ | ~ | ✓ |
| Énumération tuée par construction (capability) | ✗ | ✗ | ~ | ✓ |
| Sans modifier le code applicatif | ✓ | ✓ | ✗ | ✓ |
| Déploiement en jours, pas en mois | ✓ | ✓ | ✗ | ✓ |
| Souverain / déconnecté possible | ~ | ~ | — | ✓ |
Le correctif dans le code reste la solution de fond — mais lent, endpoint par endpoint. CORTEX IDOR est le pont qui protège dès maintenant, et son cœur capability est rare sur le marché. La protection s’applique aux routes couvertes (cf. rapport de couverture). « ~ » = partiel / dépend du déploiement.
07CE QUI EST PROUVÉ — 166 TESTS VERTS
Quatorze propriétés prouvées par mutation
Vérifiées par tests d’intégration et property-based testing (proptest). La rigueur est anti-placebo : pour chaque propriété, on casse délibérément la garde — le test correspondant doit alors devenir rouge. Une garantie n’est revendiquée que si son test échoue quand on la rompt. 14 propriétés sur 14, zéro placebo.
~54 M
exécutions · token_decoder + parser DSL fuzzés en coverage-guided (Phase B · libFuzzer) ; finding F-1 investigué et mitigé
0 crash
ANTI-ÉNUMÉRATION
Un jeton forgé ou pour un autre objet est rejeté à l’ouverture.
ANTI-REJEU
Un jeton intercepté et rejoué par un autre mandant échoue.
OWNER-CHECK
L’objet demandé doit appartenir au mandant authentifié.
PRÉ-AUTORISATION
Décision avant tout appel à l’amont — l’amont n’est pas touché si refus.
AUTHENTIFICATION REQUISE
Sans mandant valide, la requête est refusée (401) avant tout appel amont (CWE-306).
AUDIT TAMPER-EVIDENT
Journal chaîné HMAC + ancrage externe détectant la troncature.
JWKS / RS256 · ANTI-ALG
Extraction par clé publique, rotation ; vérifications HS256/RS256 séparées (anti-confusion d’algorithme).
PLAN ADMIN SÉPARÉ
Couverture, découverte et métriques jamais exposées sur le port public (404).
La pile d’autorisation, couche par couche
Au-delà du cœur capability, six gardes d’autorisation — toutes opt-in, toutes fail-closed, chacune adossée à une propriété vérifiée par mutation. Ce que les moteurs OPA / Cedar / Cerbos appliquent dans le code, CORTEX IDOR l’applique en coupure.
| Couche | Garde | Au refus | Réf. |
|---|---|---|---|
| Fonction (BFLA) | scopes OAuth2 requis (sémantique ALL) | 403 | CWE-862 |
| Chemin | anti-traversal (./.., %2e, NUL…) | 400 | CWE-22 |
| Champ entrée | allowlist de corps (mass-assignment) | 422 | CWE-915 |
| Champ réponse | masquage (exposition excessive) | champ retiré | OWASP API3 |
| Champ réponse — par mandant | allowlist conditionnée au scope, fail-closed | champ inconnu supprimé | Field-Level Authz |
| Débit | rate-limit par mandant (token bucket) | 429 + Retry-After | CWE-770 / API4 |
Pile complète : objet (BOLA) → fonction (BFLA) → champ entrée → champ réponse → autorisation de champ conditionnée au mandant, plus rate-limit et anti-traversal. La couche « par mandant » referme le défaut classique de la simple blocklist : un champ ajouté mais oublié de la politique disparaît par défaut, au lieu de fuiter.
Ce qui n’est pas (encore) revendiqué
- Latence bout-en-bout non mesurée — le loopback n’est pas représentatif ; validation en pilote (p50/p99 sur hôtes séparés).
- Fuzzing : ~54 M exécutions sur deux cibles (token_decoder + parser DSL), 0 crash ; finding F-1 investigué et mitigé.
- Pas de pentest tiers à ce jour — sur la trajectoire (périmètre PASSI prêt).
- Non certifié — CSPN (ANSSI) en trajectoire, pas un EAL.
- Autorisation de champ : filtre les noms de champs, pas leurs valeurs ; coût de configuration croissant au-delà de ~50 routes.
- Contrôle compensatoire : neutralise l’exploitation des IDOR sur les routes couvertes, ne remplace pas la sécurisation applicative de fond.
08CONFORMITÉ — RGPD · NIS2 · DORA
Une brique de conformité, traçable
CORTEX IDOR contribue à la démonstration de mesures de sécurité appropriées. Le journal d’audit tamper-evident fournit une trace exploitable des décisions d’accès, en cas de contrôle ou d’enquête post-incident.
RGPD
Contrôle d’accès au niveau objet et au niveau champ, minimisation, journalisation auditable des accès aux données personnelles.
NIS2
Mesures techniques de gestion des risques, traçabilité, détection d’incident.
DORA
Résilience opérationnelle, contrôle et journalisation des accès aux données sensibles.
Contribution à la conformité — pas une certification. CORTEX IDOR reste un contrôle compensatoire.
Discutons d’un pilote — observe-first.
Demander un pilote
Déploiement en mode observation · mesure de couverture et de latence · démonstration « A ne peut pas lire les données de B ».
press@cortexorigin.com
press@cortexorigin.com