Permissions, Sessions, HTTPS Inspection with every delivery Web, Mobile, and APIs
Access control, sessions, authentication, HTTPS: We simulate your actual user flows to verify the security observable from a browser. Penetration testing and code analysis remain the domain of your experts.
A vulnerability scan examines the technical surface of an application. It does not log in, does not switch profiles during the test, and does not verify that an invoice remains inaccessible after logging out. These checks are performed in the browser, using real-world user flows. This is exactly what an automated scenario replicates with every release.
A protected page must not open without a session or using another user's profile. The scenario attempts to access the page, one profile at a time, and verifies that access is indeed denied.
Timeout due to inactivity, actual logout, going back in the history, a second tab left open: the session must close wherever it was opened.
Login, MFA, one-time code, lockout after multiple failed attempts, password reset. These are workflows just like any others; they are tested just like any others.
HTTP-to-HTTPS redirection, a valid certificate, no mixed content, and error pages with no technical traces: everything visible on the client side is verifiable.
“With Mr Suricate, we’ve automated label verification, secured our data, and gained the reliability we need to make strategic decisions without errors. Plus, it’s fun!”
Xavier ValetHead of Data Analytics - HelloWork
GO FURTHER
Fifteen types of tests, four categories. Each one answers a different question about the quality of your courses.
Is there a term you don't understand? The automated testing glossary defines it.
YOUR QUESTIONS
The most common questions we receive about the actual scope of security testing.
No, and the two don’t aim to achieve the same thing. A penetration test looks for exploitable vulnerabilities—often outside of standard workflows—and requires offensive expertise. A scenario simulates a real-world workflow and verifies what can be observed from the browser: access, permissions, sessions, and HTTPS. The former is run on an ad hoc basis, while the latter runs with every release.
No. Vulnerability scanning, static code analysis, and infrastructure auditing remain the domain of your tools and security experts. Our scope is limited to what a user can access from a web page.
Profile-based access control, session expiration and logout, account lockout after multiple failed login attempts, the password reset process, HTTP-to-HTTPS redirection, certificate validity, the absence of mixed content, and error pages that do not leak technical information.
Yes, one account per user role, and preferably accounts set aside for testing. This allows you to verify that a user role does not see what an administrator sees, without manipulating actual data.
Yes, for all non-destructive operations: access attempts that are denied, session checks, and certificate verification. Scenarios that write data remain within your test environments or rely on isolated test datasets.
A 30-minute demo of your own app. You'll see one of your workflows automated in real time, without writing any code.