Before the scan: prepare access that actually gets tested

Write down the boundaries first

Create a short scope sheet with the exact hosts, API base paths, environment, and permitted test window. Include the account owner who can stop the activity if anything behaves unexpectedly. A wildcard domain is not a useful substitute for a decision about which systems your team is authorized to test.

Record exclusions as specific actions and routes. For example, a staging purchase flow may be testable while live refunds, outbound messages, and account deletion are excluded. Agree request limits with the application owner and start with a small, observable run.

Prepare a useful set of test identities

One administrator account will not represent the boundaries in most business applications. Prepare a standard user, another user with the same role, and a higher-privilege account if that role is in scope. For a multi-tenant service, add a second test organization. Give each account a few distinguishable synthetic records so the tester can tell who owns what.

Being signed in does not mean a user should be allowed to access every record. OWASP’s Authorization Cheat Sheet separates identity verification from permission checks and recommends checking permissions on every request. Your account set should make those permission boundaries testable.

• List which records and actions each role should be able to access.
• Keep test tenants separate from real customer accounts.
• Name test records clearly and record who will remove them afterward.
• Confirm that your selected tool supports separate account contexts; extra credentials alone do not create cross-account tests.

Plan for sessions to expire

Decide how the scanner will authenticate: a recorded login flow, a supported identity-provider integration, a short-lived API token, or a supplied session cookie. The correct choice depends on the application and the scanner. Do not assume that a browser login and an API login use the same token or permissions.

Cookies and bearer tokens can carry an authenticated session. Treat them as secrets: transfer them through the agreed secure channel, restrict who can retrieve them, and keep them out of screenshots, source control, and ordinary tickets. Avoid handing over your own everyday administrator session.

Document session timeouts, refresh behavior, and any MFA or device requirements. OWASP’s Session Management Cheat Sheet describes idle and absolute timeouts, session renewal, and invalidation. Coordinate a supported login approach instead of quietly removing authentication controls to make a scan pass.

Run a small coverage check before the full scan

Start with a few representative workflows: sign in, open a test record, use a filter, and view a role-restricted page. Inspect the resulting requests and responses. Check that the expected identity, tenant, and environment stayed consistent. Watch for repeated redirects, access-denied responses, or unexpected login HTML.

Compare what was reached with the scope sheet. If the application has 20 important workflows and only two were exercised, report that limitation plainly. Route counts can help describe coverage, but they do not prove that business logic, authorization, or every parameter was tested.

{
  "environment": "staging",
  "roles_prepared": ["member", "manager"],
  "test_tenants": 2,
  "session_check": "protected account profile",
  "excluded_actions": ["live payment", "delete account"],
  "coverage_review": "required before full run"
}

Make the handover repeatable

Keep the preparation record with the assessment, without storing secrets in it. Record the tested build, the roles used, unreachable areas, and any authentication failures. This makes the next scheduled run easier to compare with the previous one.

After a one-time assessment, revoke temporary credentials and remove disposable data. For recurring testing, assign an owner to review account permissions, secret rotation, and environment changes. A successful login today should not become an unexamined assumption next month.

Then evaluate the findings separately from the coverage. Our guide to validating and prioritizing findings explains how to turn a scanner result into a useful engineering decision.