For a web application penetration test that includes access-control testing, prepare dedicated accounts that represent the application's actual users and permission boundaries. Where users own separate records, provide two accounts with the same privileges. Include different roles, and separate test customer organizations when the application serves multiple customers. Pair those accounts with an approved description of what each may read, change, export, or administer.
This gives IT directors, application owners, and MSPs a concrete preparation task: make the important access decisions testable before the engagement begins. One working login can provide access to an application while leaving important boundaries unexamined.
Start with the access decisions you need to validate
Authentication establishes who a user is; authorization determines what that user may do. A successful login does not establish that the user should see every record or use every function. The OWASP Authorization Cheat Sheet makes this distinction and recommends validating permissions on every request.
Ask the business owner to identify sensitive actions and the intended restrictions. Useful questions include whether a user can view another person's private records, whether a viewer can change settings, and whether an administrator for one customer can affect another customer. Describe the expected result for each action. A role name such as “manager” is too ambiguous on its own.
OWASP's role-definition testing guidance calls for identifying application roles and reviewing the permissions behind them. Include unusual roles, such as support staff or auditors, when they are relevant to the agreed scope.
Build an account and data matrix
Document each account's role, customer organization, assigned records, allowed actions, prohibited actions, provisioning owner, and expiry date. Keep passwords, recovery codes, and tokens out of this planning document; transfer secrets through the approved secure channel.
The following is an illustrative planning matrix for a customer portal. Its restrictions are examples to replace with the application's actual policy.
| Account or context | Prepare | Decision to validate |
|---|---|---|
| Signed-out visitor | Public pages and approved private test records | Public content is available; private records require authorized access. |
| Two ordinary users in one customer organization | Separate identities and a private record owned by each | A user can work with their own record but cannot read or change the other user's private record. |
| Viewer and editor | Accounts with documented read-only and editing rights | The viewer cannot perform the editor's restricted changes. |
| Customer administrator | A dedicated administrator limited to one test organization | Customer administration stays within its documented authority. |
| A user in a second customer organization | A separate test organization with its own synthetic records | Customer A cannot access Customer B's restricted data or operations. |
| Support user or API identity, if in scope | The actual permission profile and a defined test workflow | Delegated support and automated access obey their specific limits. |
Two equally privileged users help testers evaluate separation between users; different roles help evaluate separation between privileges. Both are covered in OWASP's authorization-testing guidance. For roles with private user-owned data, agree whether additional same-role pairs are needed.
For an application serving multiple customer organizations, a tenant is one customer's logical environment. Two users inside the same tenant cannot by themselves demonstrate separation between customers. The OWASP Multi-Tenant Security Cheat Sheet identifies cross-tenant data access and privilege boundaries as specific concerns. Authorized platform-wide access also needs to be distinguished from unintended access.
Make the accounts usable without changing the security model
Before the testing window, have the application owner and tester confirm that each account can sign in, reach its intended workflow, and find its assigned test data. Empty accounts can leave important actions unavailable: an export workflow, for instance, needs approved records to export.
- Prepare the normal sign-in flow. Arrange MFA enrollment, invitation acceptance, and account recovery for the test identities. Avoid silently disabling controls to make access easier.
- Record environment differences. If testing uses staging, list material differences from production, including identity configuration, permissions, integrations, and enabled features.
- Keep business effects controlled. Use synthetic records and agreed destinations for notifications. Confirm which actions could send messages, initiate transactions, or alter connected systems.
- Provide an available owner. Identify who can repair a locked account, restore test data, or clarify a disputed permission during the engagement.
For MSPs supporting customer portals, have each application owner approve the expected permissions. Familiarity with a client's infrastructure is not a substitute for knowing that application's business rules.
Agree on boundaries before sharing access
Record the authorized application, environment, accounts, tenants, testing period, permitted actions, exclusions, and stop conditions in the engagement documents. Identify the emergency contact and agree how evidence will be protected, transferred, retained, and removed. NIST SP 800-115, especially its rules-of-engagement template and data-handling guidance, provides a foundation for these decisions.
A test account does not extend permission to other customer environments or third-party systems. Confirm the boundaries for shared hosting, identity providers, and integrations before testing begins. If production testing is approved, settle how unexpected exposure of real data or an operational impact will be handled.
Ask for a coverage statement with the findings
Ask the tester to map the results back to the agreed accounts and access decisions. The report should distinguish completed checks, discovered weaknesses, blocked checks, and exclusions. An unavailable account or missing test tenant should produce a visible coverage limitation, not an implied pass.
For each relevant finding, request enough protected evidence to identify the acting role, affected resource, expected permission, observed result, and tested environment. Agree which account pairs and data must be recreated for retesting. After the engagement, disable the temporary identities, revoke their remaining access, and complete the agreed cleanup.
If you are preparing a customer portal or business application for assessment, Network Box USA Penetration Testing can help define the testing scope, validate exploitable weaknesses, and plan remediation and retesting. Bring your account matrix and the access decisions you need the assessment to answer.