Dans la conception d'applications web modernes, l'une des failles les plus critiques survient lorsque les développeurs confondent l'ergonomie (l'Interface Utilisateur) et la sécurité (le Backend). Dans le domaine de la cybersécurité, et particulièrement pour une plateforme SOAR capable d'isoler des machines ou de purger des e-mails, cette confusion peut être fatale.
Cacher un bouton "Isoler la machine" dans l'interface web si l'utilisateur n'a pas validé sa double authentification (MFA) ne suffit absolument pas. Un attaquant compétent ignorera totalement votre interface graphique. Découvrez pourquoi la sécurité "côté client" est une illusion, et comment l'architecture Middleware d'Akuity SOC garantit un bouclier infranchissable pour vos requêtes API.
L'illusion de la sécurité côté Client (Frontend)
De nombreuses applications SaaS gèrent l'authentification de la manière suivante : l'utilisateur se connecte, et le code JavaScript du navigateur vérifie s'il a bien passé la case MFA. Si oui, l'interface s'affiche. Si non, il est redirigé vers une page d'erreur.
C'est ce que l'on appelle la sécurité "Client-Side" (côté client). Le problème, c'est que l'attaquant contrôle le client.
S'il possède le mot de passe de l'analyste SOC, un attaquant peut :
- Désactiver le JavaScript dans son navigateur pour contourner les redirections.
- Ouvrir les outils de développement (DevTools), récupérer le jeton de session AAL1 basique.
- Utiliser un outil d'interception de requêtes comme Burp Suite ou Postman.
- Forger directement une requête HTTP
POST /api/remediate/isolate_deviceen y joignant son jeton basique, contournant ainsi complètement l'interface web.
Si le serveur backend n'effectue pas une vérification rigoureuse du niveau d'assurance du jeton, il obéira à la requête. Le pirate vient d'exécuter une commande destructrice sur votre parc informatique sans jamais avoir validé le MFA.
Le Bouclier Middleware : L'interception au vol
Pour qu'un orchestrateur SOC soit certifié SOC 2 et réponde aux principes d'une architecture Zero Trust, chaque point de terminaison de l'API (Server Actions) doit douter de la légitimité de l'appelant.
Plutôt que de coder la vérification du MFA dans chaque fonction (ce qui augmente le risque d'oubli humain de la part d'un développeur), l'architecture de la plateforme Akuity SOC utilise un composant logiciel centralisé : le Middleware Next.js.
Le middleware agit comme un videur intraitant placé à la porte d'entrée du serveur. Il intercepte la totalité des requêtes HTTP (qu'elles proviennent du navigateur web légitime ou d'un outil de piratage comme Postman) avant qu'elles n'atteignent la logique métier de l'application.
La vérification du Claim "AAL2"
Voici comment se déroule la validation algorithmique du Middleware d'Akuity :
- Interception : Le middleware intercepte la requête entrante pointant vers une route protégée (par exemple, le Cockpit ou l'exécution d'un script KQL).
- Extraction cryptographique : Il lit le cookie de session sécurisé généré par Supabase (
sb-access-token). - Décodage du JWT : Il décode le JSON Web Token (JWT) sans faire confiance à l'appelant et vérifie sa signature cryptographique.
- La règle d'or (AAL2) : Il recherche la présence du champ d'assurance. Si le jeton indique
"aal": "aal1", cela signifie que l'utilisateur n'a validé que son mot de passe. - Le Rejet : Le Middleware bloque instantanément la requête. Si c'est une navigation web, il déclenche une redirection de force (
HTTP 302) vers la page/login/mfa. Si c'est un appel API malveillant direct, il rejette la requête avec un code statutHTTP 403 Forbidden.
Le mode démo : Une simulation sécurisée pour les essais
Cette rigueur architecturale peut rendre le test d'un produit complexe pour de nouveaux utilisateurs. Comment évaluer la plateforme lors de l'essai gratuit de 14 jours si l'on ne souhaite pas lier son propre Google Authenticator ?
Akuity intègre un astucieux "Mode Démo / Sandbox". Lors d'une simulation, le système génère un faux QR Code. Lorsque le prospect saisit un code à 6 chiffres aléatoire, une Server Action spécifique intercepte ce jeton factice (qui débute par demo.), y injecte virtuellement le claim "aal": "aal2" et place un cookie demo-mfa-enabled = 'true'. Le middleware reconnaît cette structure de test et permet au prospect d'expérimenter la remédiation simulée de bout en bout, sans jamais affaiblir les règles drastiques imposées aux utilisateurs en production.
Conclusion : Sécurisez le moteur, pas la carrosserie
En cybersécurité, on ne protège pas une banque en se contentant de peindre les portes. La sécurité doit être intrinsèque à la structure de l'application. En confiant le contrôle de l'élévation des privilèges MFA (AAL2) à un Middleware implacable, vous éliminez les vulnérabilités d'interface (Bypass Frontend) et garantissez que vos API de remédiation Microsoft Graph restent hors d'atteinte de toute usurpation d'identité basique.
Optez pour une architecture logicielle sans compromis. > Explorez les principes de Sécurité des API et la Gestion MFA d'Akuity SOC pour garantir l'étanchéité de vos opérations.