Authentication and Authorization Testing

Authentication and authorization testing protects the two questions every secure product must answer correctly: who are you, and what are you allowed to do? Teams often test login with valid and invalid passwords, then stop. That leaves the larger failure mode untested: a valid user who can see or change things outside their permission boundary. Broken access control remains one of the most exploited classes of web and API bugs because it is product-specific and easy to miss with happy-path QA.

This guide gives you a practical method for authentication and authorization testing. You will learn how to separate AuthN from AuthZ, how to build RBAC matrices, how to run IDOR testing for horizontal privilege escalation, how to design vertical privilege escalation test scenarios, how to cover session management security test cases, and how to report broken access control with evidence developers can fix. You will also get tables, request-level examples, and common mistakes.

For token-heavy APIs, pair this with API authentication testing. For request tampering mechanics, use the Burp Suite tutorial.

Authentication vs Authorization

Keep the definitions strict.

Concept	Question	Typical failures	Typical HTTP signals
Authentication (AuthN)	Is the caller's identity valid?	Missing login checks, weak reset flows, session fixation	401 Unauthorized (common)
Authorization (AuthZ)	May this identity do this action on this resource?	IDOR, role bypass, tenant leaks	403 Forbidden or 404 hide (common)

Examples:

• No cookie on /admin -> authentication problem if the route requires login.
• Viewer cookie on DELETE /admin/users/1 -> authorization problem.
• Org A token reading Org B invoice GET /invoices/99 -> authorization or tenancy problem.

If your report confuses these, developers may patch the wrong layer.

Why UI-Only Access Testing Fails

Frontends hide buttons. Backends enforce reality.

A page may not show Delete user for a viewer. That is good UX. It is not proof of security. The viewer can still call:

DELETE /api/users/45 HTTP/1.1
Host: staging.example.com
Cookie: session=viewer-session

If the server deletes the user, authorization failed. Authentication and authorization testing must include API and request-level checks, especially in SPAs and mobile clients.

Build an Access Model Before Test Cases

Do not start by randomly changing ids. Start with a model.

1. Identify actors

Examples:

• Anonymous visitor
• Signed-up user
• Customer admin
• Internal support agent
• Super admin
• Service account / API client

2. Identify resources

Examples:

• Profile
• Order
• Invoice PDF
• Project
• Message thread
• Organization settings
• Feature flags admin panel

3. Identify actions

• Create, read, update, delete
• Approve, publish, refund, invite, export
• Share, transfer ownership

4. Build a permission matrix

Action	Anonymous	User	Org Admin	Support	Super Admin
Read own order	No	Yes	Yes	Yes*	Yes
Read peer order same org	No	No**	Yes	Yes*	Yes
Read other org order	No	No	No	Policy	Yes
Refund order	No	No	Yes	Policy	Yes
Change user role	No	No	Yes	No	Yes

* Support access may be impersonation-based and audited.
** Some products allow shared org resources; model the real rules.

This matrix becomes your authorization oracle. Without it, you cannot say what "correct" means.

How to Do Authentication and Authorization Testing in Practice

Split the work into two passes. First prove identity handling. Then prove permission boundaries. Mixing them in one chaotic session is how teams "tested login" and still shipped IDOR.

How to Test Authentication

Authentication testing proves identity establishment and lifecycle handling.

Login and credential rules

Test cases:

1. Valid credentials succeed and establish a session or token.
2. Invalid password fails with a generic error.
3. Unknown user fails without account enumeration if that is the policy.
4. Empty fields fail validation.
5. Case sensitivity rules match the spec for email or username.
6. Unicode and leading/trailing spaces are handled intentionally.
7. Rate limiting or lockout engages after repeated failures.
8. CAPTCHA or bot controls behave as designed in staging.

Multi-factor authentication (if present)

1. Correct password without second factor does not grant full access.
2. Replayed OTP fails.
3. Expired OTP fails.
4. Backup codes work once if offered.
5. MFA reset path is itself authorized and audited.

Password reset and recovery

1. Reset link expires as specified.
2. Reset link is single use.
3. Reset does not log in other existing sessions unless specified.
4. Response messages avoid user enumeration when required.
5. Old password fails after successful reset.
6. Reset tokens are not guessable (quality depends on security review, but QA can check length/random appearance and reuse).

Logout and session end

1. Logout clears browser session state.
2. Server rejects the old session id or access token after logout.
3. Refresh tokens cannot mint new access tokens after revocation.
4. Shared device scenarios do not leave account switch debris.

Federation and social login (if present)

1. Callback state parameter is validated.
2. Account linking rules cannot steal accounts.
3. Redirect URIs are allowlisted.

Session Management Security Test Cases

Sessions and tokens are where authentication becomes ongoing authorization context.

Cookie session checklist

Case	What to verify
Secure flag	Cookie not sent over pure HTTP if HTTPS is required
HttpOnly	Session cookie not readable by document.cookie (mitigates some XSS impact)
SameSite	Matches CSRF strategy for the app
Expiry / Max-Age	Idle and absolute timeouts match policy
Scope Path/Domain	Not overly broad
Logout	Server-side invalidate, not only client delete
Password change	Old sessions rotated or invalidated per policy
Concurrent sessions	Allowed or blocked as designed

Token session checklist (JWT/OAuth style)

Case	What to verify
Access token expiry	Protected APIs reject expired access tokens
Refresh rotation	Refresh works, replay of old refresh fails if rotation enabled
Audience/issuer	Tokens for another app or env are rejected when feasible to test
Algorithm confusion	Unsigned or unexpected alg rejected (often security-owned, QA can smoke)
Storage	Tokens not leaked in URL query strings
Scope reduction	Downscoping works; privilege does not increase silently

Session fixation style checks

1. Obtain an anonymous session id if the app issues one.
2. Log in.
3. Confirm the pre-login session id is not reused as the authenticated session if policy forbids it.
4. Confirm an attacker who planted a session cannot ride the victim login.

Concurrent access

1. Log in on two browsers if multi-session is allowed.
2. If single session is mandatory, confirm the old one dies.
3. Confirm profile or password changes propagate to session claims as designed.

How to Test Authorization and Broken Access Control

Broken access control testing is systematic permission abuse.

Vertical privilege escalation test scenarios

Vertical means climbing the privilege ladder.

Examples:

• Member calls admin-only POST /admin/force-reset.
• User opens /internal/metrics and receives data.
• Teacher assigns themselves role=admin via profile API.
• Support agent reaches super-admin billing controls.
• Read-only API key performs DELETE.

Method:

1. Capture an admin request with Burp or browser DevTools.
2. Replay it with a lower-privilege session.
3. Verify denial and absence of side effects.
4. Try forced browsing to admin URLs.
5. Try hidden parameters: isAdmin=true, role=admin, permission=* in body or query.

For a focused checklist on this risk class, add test broken access control to the authorization regression pack.

Horizontal privilege escalation and IDOR testing

Horizontal means peer access.

Classic IDOR pattern:

User A: GET /api/orders/501 -> 200 own order
User B: GET /api/orders/501 -> must not return A's order

IDOR testing for horizontal privilege escalation:

1. Create two users with comparable roles.
2. As user A, create or note object ids: order, document, message, report.
3. As user B, attempt read/update/delete on A's ids.
4. Repeat for every object type that uses sequential or predictable ids.
5. Include nested resources: /projects/7/files/19.
6. Include exports: /orders/501/invoice.pdf.
7. Include search and list filters that might return foreign objects.
8. Include websocket or bulk endpoints that accept arrays of ids.

Tenant isolation

For multi-tenant SaaS:

1. User in Tenant A must not read Tenant B data even with B's object id.
2. Invites must not attach users to the wrong tenant without authorization.
3. Cross-tenant admin tools must be explicit and audited.
4. Analytics endpoints must not aggregate foreign tenant private data into unauthorized views.

Function vs object vs field authorization

Do not only test pages. Test levels:

Level	Example failure
Function/route	Viewer can call refund API
Object	Viewer can refund another customer's order
Field	User can edit salary or role on own profile payload
Context	User can approve a request outside their department

Field-level issues often appear as mass assignment:

PUT /api/me
{
  "displayName": "Alex",
  "role": "admin"
}

If role sticks, you found vertical escalation via mass assignment.

RBAC Testing Workflow

Step 1: Freeze the matrix

Get product sign-off on the permission matrix for the release. Ambiguous rules become flaky security bugs and flaky tests.

Step 2: Pick critical transactions

Prioritize:

• Money movement
• PII access
• Permission changes
• Deletion
• Export
• Impersonation
• Production configuration

Step 3: Dual channel every case

For each row in the matrix:

1. Attempt via UI.
2. Attempt via direct API or proxied request.

Both must match policy.

Step 4: Assert side effects, not only status codes

A 200 with empty body can still have deleted data. A 403 after partial write is still a bug. Verify database state, UI state, or follow-up GET.

Step 5: Negative and positive coverage

People forget positive cases. If Org Admin should refund, prove it works. Authorization tests are not only denials.

Sample Test Case Catalog

Use these as seeds. Adapt names to your product. For format guidance, see how to write test cases.

Authentication set

ID	Title	Expected
AUTH-01	Valid login establishes session	User reaches authenticated home; session present
AUTH-02	Wrong password fails	Generic error; no session
AUTH-03	Lockout after N failures	Account temporarily locked; audit event if specified
AUTH-04	Logout rejects old session	Protected API returns 401
AUTH-05	Password reset link expires	Expired link cannot change password
AUTH-06	MFA required account without OTP	No full access

Authorization set

ID	Title	Expected
AUTHZ-01	User B cannot read User A order by id	403/404; no PII leakage
AUTHZ-02	User cannot call admin role change API	403; roles unchanged
AUTHZ-03	Org Admin can update org settings	200; change persists
AUTHZ-04	Org Admin cannot update other org settings	403/404; no change
AUTHZ-05	Viewer cannot delete project	403; project remains
AUTHZ-06	Mass assignment cannot set role	Role unchanged
AUTHZ-07	Direct object PDF export enforces owner/tenant	Unauthorized user blocked
AUTHZ-08	Bulk id endpoint does not leak foreign records	Only permitted ids returned

Session set

ID	Title	Expected
SESS-01	Absolute timeout enforced	Re-auth required
SESS-02	Idle timeout enforced	Re-auth required
SESS-03	Cookie flags present	Secure/HttpOnly/SameSite as designed
SESS-04	Password change invalidates old sessions	Old session fails
SESS-05	Refresh replay rules enforced	Replayed refresh rejected when rotation enabled

Practical Request-Level Examples

Example A: Horizontal IDOR on messages

GET /api/messages/88421 HTTP/1.1
Host: staging.chat.example
Authorization: Bearer <user_B_token>

Pass: 403 or 404.
Fail: 200 with user A's message body.

Example B: Vertical escalation on feature flag admin

POST /api/admin/flags HTTP/1.1
Host: staging.app.example
Authorization: Bearer <standard_user_token>
Content-Type: application/json

{"key":"new-checkout","enabled":true}

Pass: 401/403 and flag unchanged.
Fail: 200 and flag flips.

Example C: Forced browsing

Visit as standard user:

/admin/users
/internal/config
/api/admin/v1/metrics

Pass: blocked consistently in UI and API.
Fail: page loads data or API returns sensitive JSON even if UI route is empty.

Automation Strategy for Access Control

Manual exploratory work finds design gaps. Automation prevents regressions.

Patterns that work:

• Data factories create user A, user B, admin, and objects each run.
• Tests call APIs with explicit tokens per role.
• Assertions check status and forbidden field absence.
• A thin suite of IDOR checks runs on every PR for critical resources.
• Broader matrix runs nightly.

Avoid brittle UI-only authZ automation as your sole control. UI tests are still useful for workflow confidence, but API checks catch the server contract.

Evidence and Bug Writing

A strong broken access control report includes:

1. Accounts used (not real passwords in tickets).
2. Exact requests (path, method, critical headers redacted as needed).
3. Expected policy reference (matrix row or requirement id).
4. Actual result and data leakage sample (minimized).
5. Impact: confidentiality, integrity, multi-tenant scope.
6. Repro reliability and environment.

Severity tips:

• Cross-tenant data read is usually critical.
• Peer order read is usually high.
• UI button visible without API success may be medium/low if API is safe, but still fix UX.
• Admin function callable by user is usually critical/high.

Common Mistakes in Authentication and Authorization Testing

1. Testing only login

Login success is the beginning. Authorization is the product.

2. One user account for everything

You cannot prove horizontal issues with a single identity.

3. Trusting hidden UI controls

Server checks are the real checks.

4. Asserting status codes only

Look for data and side effects.

5. Ignoring nested resources and files

PDFs, exports, image URLs, and zip downloads often skip the same checks as JSON APIs.

6. Forgetting support impersonation paths

Impersonation is powerful. Test who can start it, what they can see, how it is audited, and how it ends.

7. No retest after role redesign

Permission refactors break old assumptions. Rerun the matrix.

8. Mixing staging shared accounts

Shared credentials create false fails and false passes. Use isolated test users.

9. Over-scanning with destructive deletes

Prefer read IDOR first, then carefully test write/delete on disposable objects.

10. Skipping anonymous access

Some "private" URLs are fully open. Include the anonymous actor in the matrix.

End-to-End QA Play for a Release

1. Update permission matrix with product
2. Identify new or changed resources in the release
3. Create clean users per role in staging
4. Smoke authentication lifecycle
5. Run horizontal IDOR on new object ids
6. Run vertical checks on new admin functions
7. Run session expiry/logout checks if auth changed
8. Automate the top 10 critical denials and allows
9. File issues with request evidence
10. Retest fixes and nearby variants

How This Connects to Other Security Testing

Access control failures often combine with other bugs:

• XSS in an admin view becomes instant privilege abuse. See XSS testing.
• Weak authentication makes authorization moot. See API authentication testing.
• Request tampering skills speed up everything. See Burp Suite tutorial.

If you want hands-on practice designing role matrices and abuse cases, try security and API battles on QABattle or sign up to track your progress.

Final Takeaway

Authentication and authorization testing is matrix thinking plus request-level honesty. Prove who the system thinks you are, then prove every sensitive action is allowed or denied according to policy. Use multiple users, multiple roles, UI and API paths, and assertions on side effects. Cover session lifecycle so identity cannot outlive its welcome. When you find a break, write it as a policy violation with clear impact, not only as a technical curiosity.

Do this well and you will catch the class of bugs that pure functional checklists miss most often: "it works for me" while it also works for people who should never have seen it.