Authentification et sessions
Connexion, réinitialisation de mot de passe, authentification multifacteur, SSO, jetons et gestion des sessions.
Pentest d’application web et d’API
Les scanners trouvent les en-têtes manquants. Nous trouvons la requête qui renvoie les données d’un autre client. Des tests manuels d’applications web et d’API, avec une preuve pour chaque vulnérabilité et un correctif que vos développeurs peuvent appliquer.
En bref
Un test d’intrusion d’application web est une évaluation de sécurité manuelle d’une application web et de ses API. Les testeurs recherchent des failles dans l’authentification, la gestion des sessions, le contrôle d’accès (IDOR, BOLA, BFLA), le traitement des entrées et la logique métier, en suivant l’OWASP Top 10 et l’OWASP API Security Top 10. Zyberum livre des vulnérabilités notées CVSS avec preuve de concept, des correctifs et un retest, à prix fixe.
Ce que nous testons
Connexion, réinitialisation de mot de passe, authentification multifacteur, SSO, jetons et gestion des sessions.
L’utilisateur A peut-il lire ou modifier les données de l’utilisateur B ? IDOR, BOLA et BFLA sont les failles dont l’impact est le plus lourd.
Étapes sautées, prix modifiés, plafonds contournés : les failles qu’aucun scanner ne comprend.
Injection SQL et injection de commandes, cross-site scripting (XSS), server-side request forgery (SSRF), désérialisation non sécurisée.
REST et GraphQL : exposition excessive de données, mass assignment, absence de limitation de débit, endpoints non documentés.
Interfaces d’administration exposées, messages d’erreur trop bavards, composants obsolètes et chiffrement des échanges insuffisant.
Pourquoi des tests manuels
Dans les produits IoT que nous avons testés récemment, les pires failles n’avaient rien d’exploits exotiques. C’étaient des appels d’API qui renvoyaient ou modifiaient tout simplement les appareils d’autres clients, parce que le serveur faisait confiance à un identifiant présent dans la requête.
Ce type de faille n’apparaît que lorsque quelqu’un comprend ce que l’application est censée faire, puis essaie ce qu’elle ne devrait pas permettre. C’est à cela que nous consacrons notre temps. Nos modèles d’IA auto-hébergés nous aident à couvrir davantage d’endpoints dans le même temps, et chaque vulnérabilité est vérifiée par un testeur.
Études de cas
Nous pouvions voir et activer les appareils d’autres clients via MQTT, et géolocaliser leur lieu d’installation.
Nous avons testé un système d’arrosage connecté : une configuration MQTT défaillante permettait de voir, piloter et localiser les appareils d’autres clients.
Lire l’étude de casAccès root complet sur l’appareil, et accès à la caméra WebRTC en direct d’autres utilisateurs via l’API cloud.
Nous avons testé un robot aspirateur à caméra : accès root sur l’appareil, et failles de l’API cloud ouvrant la caméra en direct d’autres utilisateurs.
Lire l’étude de casFAQ
L’idéal est un environnement de préproduction avec des données proches de la production : nous pouvons y tester sans risque pour vos utilisateurs. Un test en production reste possible, dans des limites convenues.
De l’URL, de comptes de test pour chaque rôle et de la documentation de l’API, si elle existe. Pour un test en boîte blanche, d’un accès au code source.
En général 5 à 10 jours de test pour une application, selon le nombre de rôles et de fonctionnalités.
Passez à l’action
Parlez-nous de l’application, de ses rôles et de ses API. Vous recevez une offre à prix fixe après l’appel.

Vous échangerez avecTom ZaubermannFondateur et CEO, Zyberum
Nous répondons sous un jour ouvré.
Votre vie privée
Nous utilisons des cookies et des technologies similaires pour mesurer l’audience de notre site et l’efficacité de nos annonces. Vous choisissez ceux que nous pouvons utiliser. Vous pouvez modifier votre choix à tout moment via « Paramètres des cookies » en bas de page. Politique de confidentialité