What is authenticated penetration testing?
It is a pentest run with valid logins. The tester signs in as each kind of user the application has, then tries to do things that user should not be able to do. Most of a modern SaaS product sits behind a login, so a test without accounts sees the login page, the marketing site and a handful of public endpoints.
The PCI SSC's penetration testing guidance is direct about this: if an application requires authentication, testing "should be performed against all roles or types of access," including roles with no access to cardholder data, to confirm they cannot reach it. FedRAMP's guidance goes further and has cloud providers supply privileged accounts in production so the 3PAO can test the path from unauthenticated, to authenticated, to privileged access.
What does each approach find?
Unauthenticated testing finds what anyone on the internet can reach. Authenticated testing finds what your own users can reach, which is where authorization flaws live.
| Finding class | Unauthenticated test | Authenticated test |
|---|---|---|
| Login, password reset, signup flaws | Yes | Yes |
| Exposed admin panels, debug endpoints, public buckets | Yes | Yes |
| Injection in public forms and endpoints | Yes | Yes |
| Injection in features behind login | No | Yes |
| IDOR and broken object level authorization | No | Yes |
| Privilege escalation between roles | No | Yes |
| Cross-tenant data access | No | Yes, with accounts in two tenants |
| Mass assignment on profile and settings endpoints | No | Yes |
| Business logic flaws in paid or gated features | Rarely | Yes |
| Session handling after logout, role change, password change | No | Yes |
The authorization rows are the ones that matter most in practice. Broken object level authorization and broken function level authorization cannot be found by a tester who has no session to test them with.
Which accounts should you provision?
One account for every role, a second account at the most common role, and accounts in at least two tenants. One account per role lets the tester check vertical access (can a member reach admin functions). Two accounts at the same role let them check horizontal access (can one member read another member's data). Two tenants let them check isolation between customers. OWASP's testing guide builds its horizontal escalation test on exactly this: two users with identical privileges, two live sessions, and swapped identifiers.
A typical provisioning request for a B2B app with four roles:
| Account | Tenant | Role | Purpose |
|---|---|---|---|
| owner_a | Tenant A | Owner | Highest customer privilege, billing, user management |
| admin_a | Tenant A | Admin | Vertical escalation target and source |
| member_a1 | Tenant A | Member | Baseline user |
| member_a2 | Tenant A | Member | Horizontal checks against member_a1 |
| viewer_a | Tenant A | Read-only | Write attempts from a read-only role |
| owner_b | Tenant B | Owner | Cross-tenant checks from the top role |
| member_b1 | Tenant B | Member | Cross-tenant checks from a baseline role |
Seed each tenant with realistic objects (projects, invoices, files, API keys) so there is something to try to reach. An empty tenant produces a clean-looking test and proves nothing. If your product has internal staff or support roles, include one; support tooling is a common path into every tenant.
What is the multi-role matrix?
It is the table a tester fills in to prove access control works: every sensitive action down one side, every role across the top, the expected result in each cell, and the observed result beside it. A mismatch is a finding.
| Action | Owner | Admin | Member | Read-only | Other tenant | No session |
|---|---|---|---|---|---|---|
| GET /api/projects/{id} | Allow | Allow | Allow | Allow | Deny | Deny |
| PATCH /api/projects/{id} | Allow | Allow | Allow | Deny | Deny | Deny |
| DELETE /api/projects/{id} | Allow | Allow | Deny | Deny | Deny | Deny |
| POST /api/users/invite | Allow | Allow | Deny | Deny | Deny | Deny |
| PATCH /api/users/{id}/role | Allow | Deny | Deny | Deny | Deny | Deny |
| GET /api/billing/invoices | Allow | Deny | Deny | Deny | Deny | Deny |
The procedure behind it:
- Record each action once as the most privileged role, capturing the full request.
- Replay that request with every other role's session token, changing nothing else.
- Replay again with the object IDs swapped for objects owned by another user and another tenant.
- Compare each response to the expected cell. A 200 with data where the matrix says Deny is a finding; so is an error response on a Deny cell when the change was applied anyway. Check the object state, not just the status code.
- Repeat for GraphQL operations and any background job endpoints, which often skip the checks the REST layer has.
Burp Suite extensions such as Autorize and AuthMatrix, and ZAP's Access Control Testing add-on, automate steps 2 and 3; the OWASP guide lists them.
How do you handle MFA and SSO?
Give the tester a way through MFA that is as strong as what your users face, and keep it limited to test accounts. Common options:
- Share the TOTP seed. For authenticator-app MFA, enroll each test account and share the secret with the tester through your secret manager. TOTP (RFC 6238) is deterministic from the seed, so tooling can generate codes and sessions can be refreshed without a human.
- Dedicated IdP test users. For SAML or OIDC single sign-on, create test users in your identity provider, assigned to the app through a dedicated group, with the same conditional access policies as real users where possible.
- Test the fallback path. If the app still accepts local passwords or has a break-glass login beside SSO, include it. Those paths are often weaker than the SSO flow they sit next to.
Avoid disabling MFA globally for the test window. If an exemption is unavoidable, scope it to the named test accounts and record it in the rules of engagement.
What does good test-account hygiene look like?
- Create accounts only for the test, with names that make their purpose obvious.
- Never reuse a real employee's account or password.
- Give test tenants no access to real customer data, and exclude them from billing, email and SMS.
- Store credentials in a secret manager with an expiry, not in the SOW or a chat thread.
- Rotate or disable the accounts at the end of the window. The PCI guidance lists removing test accounts as part of cleanup after the test.
[ Sources ]
Written by Parameter · Last reviewed
