How to prepare a target for live application testing

Note

Live application testing is not self-serve. It runs as a BattleTest Enterprise deployment inside a client’s own network, scoped per engagement. This page covers what an application needs before a run can cover it properly. Read it before the scoping conversation. Talk about a dedicated deployment →

Prerequisites

• You must own the target or have permission to test it under your agreement. Enterprise does not require DNS ownership verification or a separate approval for each host. Any configured organisation scope restrictions still apply.
• The application must be reachable from wherever the deployment runs.
• For authenticated coverage, the app must offer self-serve email/password signup. Most of an application’s attack surface (IDOR, broken access control, privilege escalation) lives behind login, and the agent acquires its own test identities by registering real accounts. See below.

Authenticated testing requires self-serve signup

To test everything behind login, BattleTest signs up its own disposable accounts (using throwaway mailboxes it controls), logs in, and drives the app as a real user, including creating a second identity to probe for cross-user access flaws (IDOR/BOLA/RBAC). The second identity is also how findings are confirmed: nothing is reported unless it was replayed against the running system and reproduced from a second, unrelated account.

For this to work, the target must allow self-serve registration with email and password (or another credential BattleTest can create on demand).

Caution

SSO-only apps get discovery-only coverage. If the only way in is “Sign in with Google/GitHub” and there is no email/password signup, BattleTest will not automate a third-party login (it’s outside your authorisation and against those providers’ terms). It reports the app as SSO-only and tests only the unauthenticated surface. To get authenticated testing, expose a self-serve email/password signup: even a staging-only or feature-flagged one is enough.

Note

Seeing shallow results on a login-gated app? Check that a fresh visitor can register without SSO. A hard SSO wall, an invite-only signup, or an email-domain allowlist all block automated account creation and cap coverage at the public surface.

Scope restrictions and third-party hosting

Enterprise deployments can test public hosts, private IP addresses, and local aliases without DNS TXT records or CNAME approvals. The application must still be reachable from the deployment.

Administrators may restrict targets in Settings → Policy → Testing scope. With no entries, registered targets are allowed. With entries, each target must match a listed domain or IP range. See Configure testing scope.

For applications hosted on shared or third-party infrastructure, confirm that your permission to test covers the intended activity. Registration in BattleTest does not establish that permission.

Environments and domains

A target is described as an environment: one application, and every hostname that belongs to it. api.example.com and app.example.com are one environment, not two. One battletest run covers the whole environment regardless of how many hostnames it contains.

Group by application. Do not group by DNS. Splitting one application across two environments hides exactly the flaws worth finding: an agent that can move from the web app to the API in a single run is what surfaces a cross-service access-control break.

Screenshot to addThe dashboard environment view: an environment with its hostnames, each showing its registration status.

Permission tiers

Each environment carries a permission tier that decides what the agent is allowed to do to it. The tier is a code-level control: offensive tooling is withheld at lower tiers rather than the agent being instructed not to use it. Raising a tier is an explicit, recorded approval, and steps that could change state pause for a human decision.

A first assessment normally starts read-only, and the tier is raised once the discovered inventory has been reviewed. See How live testing works for what each tier permits.

What a run reports

A run reports what it confirmed and what it could not reach. Coverage you did not get is a fact about the assessment and appears in the report. Discovery output (the endpoint inventory the run built) is part of the record.

For the shape of the report itself, see Scan results.