Authenticated web app testing with AI agents

Authenticated web application penetration testing tests the parts of your app that sit behind login. The lab's AI testing agents sign in with test accounts, one per role, and compare what each role can see and do. Excession Labs checks the evidence for each finding and writes the report.

An unauthenticated test reaches the login page and the public site. Most records, settings, payments and admin tools are behind login, so authorization bugs show up only when the caller is signed in.

What does an authenticated test cover?#

It covers every function that checks who the caller is. The agents run the same request as several roles and as an anonymous caller, then compare the results.

OWASP API1:2023 and the OWASP privilege escalation test describe the same ideas for manual testers.

Which test accounts do you need for each role?#

You need one account for each role, and a second account in any role that holds data. The second account is what proves one user can reach another user's records. Create the accounts for the test and mark them as test data.

Give each account some test data, or a cross-account read has nothing to read. We write the accounts and roles into the scope.

How do sessions work during the test?#

Each account keeps its own session, and the agents renew it when it ends. A mix-up between sessions would ruin the comparison. If a response returns a login page with a 200 status, the agent treats the session as lost, writes it in the run log, and does not report it as a finding.

Tell us three things: how to sign in, what carries the session (a cookie, a bearer token or a header), and how long it lives. The OWASP Session Management Cheat Sheet is the reference for expiry and logout behavior. Logout, token reuse after logout and cookie flags are valid tests, so the scope can include them. The signed-in flows guide walks through session handling step by step.

What are the SSO and MFA options?#

You pick one option per environment, and the scope records it. OWASP calls MFA a critical control, so we do not ask you to turn it off for real users.

If login, MFA or password reset is in scope, test it on purpose with accounts you control. The OWASP Multifactor Authentication Cheat Sheet lists what to check.

What stays out of scope?#

Real users' accounts, real customer data and anything the system owner has not authorized in writing stay out. We test only with written authorization from the system owner. Destructive proofs use test-owned accounts and records only.

Some actions need approval or are bounded, and their cost goes in the report: uploads, password guessing, email sending and paid third-party APIs. If something outside the scope looks relevant, we stop and ask. The agents' tool rules (run on its own, wait for approval, blocked) are set per scope. See the safety page.

Credentials need care too. Pass them through a secrets manager or an encrypted channel, not through chat or tickets. Replace session values with placeholders in saved evidence, and disable the accounts when the test ends.

What evidence do you get?#

Each finding comes with saved requests and responses, timestamps and the controls that were run next to it. Key evidence can carry a SHA-256 manifest. A finding is "Observed" when we reproduced it and "Browser-observed" when it was shown in a real browser.

A worked example: the agent signs in as user A and as user B in the same role. It requests B's record with A's session, and then reads it from B's session to see what changed. A control, such as a nonexistent record ID, runs alongside. The report holds the pair, the result and the fix guidance. The report also lists controls that held, so you know which protections work. The example assessment shows the report layout.

How do you start?#

Start with a short call, then a written scope and proposal. Prices are quoted after scoping. Send us the role list, the environment and your SSO and MFA setup before the call. For a small first test, apply for a pilot. Places are limited and reviewed by hand.