Droits, sessions, HTTPS Contrôle à chaque livraison Web, mobile et API
Contrôle d’accès, sessions, authentification, HTTPS : nous rejouons vos parcours réels pour vérifier la sécurité observable depuis un navigateur. Le test d’intrusion et l’analyse de code restent le domaine de vos experts.
Un scan de vulnérabilités regarde la surface technique d’une application. Il n’ouvre pas de session, ne change pas de profil en cours de parcours, et ne vérifie pas qu’une facture reste inaccessible après une déconnexion. Ces contrôles-là se jouent dans le navigateur, sur des parcours réels. C’est exactement ce que rejoue un scénario automatisé, à chaque livraison.
Une page protégée ne doit pas s’ouvrir sans session, ni avec le profil d’un autre utilisateur. Le scénario tente l’accès, profil par profil, et vérifie que le refus est bien au rendez-vous.
Expiration après inactivité, déconnexion effective, retour arrière dans l’historique, second onglet resté ouvert : la session doit se fermer partout où elle a été ouverte.
Connexion, MFA, code à usage unique, verrouillage après plusieurs échecs, réinitialisation de mot de passe. Ce sont des parcours comme les autres, ils se testent comme les autres.
Redirection de HTTP vers HTTPS, certificat valide, absence de contenu mixte, pages d’erreur sans trace technique : tout ce qui est visible côté client est vérifiable.
“Avec Mr Suricate, nous avons automatisé la vérification des étiquettes, sécuriser nos données et gagné en fiabilité pour prendre des décisions stratégiques sans erreur. En plus, c’est amusant !”
Xavier ValetHead of Data Analytics - HelloWork
ALLER PLUS LOIN
Quinze types de tests, quatre familles. Chacun répond à une question différente sur la qualité de vos parcours.
Un terme vous échappe ? Le glossaire du test automatisé le définit.
VOS QUESTIONS
Ce qu’on nous demande le plus souvent sur le périmètre réel des tests de sécurité.
Non, et les deux ne visent pas la même chose. Un test d’intrusion cherche des failles exploitables, souvent hors des parcours nominaux, et demande une expertise offensive. Un scénario rejoue un parcours réel et vérifie ce qui est observable depuis le navigateur : accès, droits, sessions, HTTPS. Le premier se commande ponctuellement, le second tourne à chaque livraison.
Non. Le scan de vulnérabilités, l’analyse statique de code et l’audit d’infrastructure restent le domaine de vos outils et de vos experts sécurité. Notre périmètre s’arrête à ce qu’un utilisateur peut atteindre depuis une page web.
Le contrôle d’accès par profil, l’expiration et la fermeture de session, le verrouillage après plusieurs échecs de connexion, le parcours de réinitialisation de mot de passe, la redirection de HTTP vers HTTPS, la validité du certificat, l’absence de contenu mixte, et les pages d’erreur qui ne laissent pas fuir d’information technique.
Oui, un compte par profil à couvrir, et de préférence des comptes réservés aux tests. C’est ce qui permet de vérifier qu’un profil lecteur ne voit pas ce que voit un administrateur, sans manipuler de données réelles.
Oui pour tout ce qui est non destructif : tentative d’accès refusée, contrôle de session, vérification du certificat. Les scénarios qui écrivent des données restent sur vos environnements de recette, ou s’appuient sur des jeux de données de test isolés.
Une démo de 30 minutes sur votre propre application. Vous verrez un de vos parcours automatisé en direct, sans écrire de code.