Authenticated testing

Protected routes are tested from Workbench with approved identities. Add those identities on the project before the assessment starts. Do not attach production user cookies from a personal browser session.

What to configure

In Workbench, attach only dedicated test identities:

  • Username and password flows the target owner approved
  • Session material issued for this assessment
  • Role pairs when you need to compare two authorized users

Store credentials in the workspace identity controls, not in CLI flags and not in CI logs.

Assessment setup where dedicated test identities are attached
Assessment setup where dedicated test identities are attached

Role boundaries

When two identities are in the same project, compare what each one can reach. Authorization issues still have to land in Findings with HTTP Records attached. A difference you cannot replay is not a finding yet.

HTTP records used to replay an authenticated finding
HTTP records used to replay an authenticated finding

Safety

Authenticated testing is still bound by the authorization gate. A valid login does not expand the project to every host the session can see.

If the identity fails mid-assessment:

  1. Stop the scan in Workbench
  2. Repair the session
  3. Restart only after the identity works on the authorized host

Do not continue with a guessed, stolen, or personal session.

LoginRequest access

Need a workflow that is not documented here? Email contact@eresussec.com.