Authentication and Authorization Testing: Access Control Validation

Authentication and Authorization Testing: A Beginner's Guide to Access Control Validation

In the digital world, not all users are created equal. A bank's mobile app should allow you to view your balance, but it must absolutely prevent you from seeing another customer's transactions. This fundamental principle—ensuring users can only access what they're supposed to—is the domain of authentication and authorization testing, often called access control validation. For aspiring software testers, mastering this area is non-negotiable. It's where technical skill meets critical security thinking, protecting data integrity and user privacy. This guide will break down these essential concepts, align them with the ISTQB Foundation Level syllabus, and show you how to apply them practically in real-world projects.

1. Understanding the Core Concepts: Authentication vs. Authorization

Before testing, you must understand what you're testing. The ISTQB Foundation Level syllabus clearly distinguishes these two pillars of access control.

Authentication: Proving Your Identity

Authentication is the process of verifying a user's claimed identity. It's the digital "show me your ID." Common methods include:

• Knowledge-Based: Something you know (passwords, PINs).
• Possession-Based: Something you have (a smartphone for OTP, a security token).
• Inherence-Based: Something you are (fingerprint, facial recognition).

Testing Focus: Validate that only valid credentials grant access, and invalid ones are rejected with appropriate (non-revealing) error messages.

Authorization: Defining Your Permissions

Once the system knows *who* you are, authorization decides *what* you can do. It's the rulebook that defines permissions for different user types.

Example: In a project management tool:

• A Viewer can see tasks.
• A Contributor can create and edit tasks.
• An Admin can delete projects and manage user roles.

How this topic is covered in ISTQB Foundation Level

The ISTQB syllabus introduces these concepts under the umbrella of functional testing types and security testing. It emphasizes testing for failures in these mechanisms as a critical quality attribute. Understanding these definitions is the first step toward designing effective test cases for access control validation.

How this is applied in real projects (beyond ISTQB theory)

While ISTQB provides the foundational definitions, real projects demand a proactive, "attacker-mindset" approach. Testers don't just verify that correct logins work; they relentlessly try to break the system by manipulating sessions, tampering with requests, and attempting unauthorized actions. This practical, hands-on skill is what separates theory from job-ready competency. For a structured path to build this mindset, our ISTQB-aligned Manual Testing Course bridges this exact gap.

2. Role-Based Access Control (RBAC): The Backbone of Authorization

Role-Based Access Control (RBAC) is the most common authorization model. Permissions are assigned to roles (like "Manager," "Customer," "Support Agent"), and users are assigned to these roles.

Testing RBAC: A Manual Tester's Approach

Your primary goal is to ensure users cannot perform actions outside their assigned role. This is a perfect area for exploratory and negative testing.

Practical Test Scenario: Test an e-commerce admin panel.

1. Step 1: Log in as a "Customer Support" role user.
2. Step 2: Navigate to the page for managing product prices (an "Admin" function).
3. Expected Result: You should be denied access—either via a "403 Forbidden" error, a redirect to a dashboard, or the UI element being hidden.
4. Step 3 (Negative Test): Try to directly access the admin URL (e.g., `/admin/update-price`) while logged in as support.
5. Expected Result: The server must reject this request. A critical failure would be if the page loads or the action processes.

3. Testing for Privilege Escalation: The Hacker's Playbook

Privilege escalation occurs when a user gains access to privileges they shouldn't have, such as a standard user becoming an administrator. Testing for this is paramount.

Vertical vs. Horizontal Privilege Escalation

• Vertical: Gaining higher-level privileges (e.g., user -> admin).
• Horizontal: Accessing resources of a peer user (e.g., User A accessing User B's private photos).

Manual Testing Techniques

Using browser developer tools (F12), a tester can probe for weaknesses:

1. Parameter Tampering: If a request to delete a post sends `"post_id": 123`, try changing it to `"post_id": 124` (another user's post). Does the system check ownership?
2. URL Manipulation: If your profile URL is `/users/me/profile`, try `/users/5/profile`. Does it show another user's data?
3. State Modification: Intercept a response or check browser storage (like localStorage) for a field like `"role": "user"`. What happens if you manually change it to `"role": "admin"` before sending the next request? (Spoiler: A robust system will re-validate this server-side).

4. Session Management and Token Validation

After login, the application needs to remember you. This is done via sessions (server-side) or tokens (client-side, like JWT - JSON Web Tokens).

What to Test in Session Management?

• Session Timeout: Does an inactive session expire correctly?
• Concurrent Sessions: Can the same user be logged in from two devices/browsers? Is this allowed by policy?
Session Fixation: Does the session ID change after login? (It should, to prevent an attacker from forcing a known session ID on a user).

Token Validation (OAuth / JWT Context)

Modern apps often use tokens (like in OAuth flows for "Login with Google").

Key Test: Token Integrity. Copy a valid JWT token (from your browser's Network tab) to a different browser or tool like Postman. Try to access an API endpoint with it. It should work—that's by design. Now, try to *modify* the token's payload (e.g., change the `user_id` inside) and use it. A secure system will invalidate the token because the signature won't match. Testing this validation is crucial.

5. OAuth and Third-Party Authorization Testing

OAuth is a framework that lets users grant a third-party application limited access to their resources (e.g., "Allow App X to read your Google contacts").

Critical OAuth Flows to Understand for Testing

As a tester, you don't need to be an OAuth architect, but you should understand the basic "Authorization Code Flow":

1. User clicks "Login with Google" in your app.
2. Your app redirects them to Google's login/consent page.
3. After success, Google redirects back to your app with a short-lived "authorization code."
4. Your app's backend exchanges this code for an "access token."

Testing Focus: What happens if the redirect fails? What if the user denies consent? Does your app handle the error gracefully? Can you tamper with the "state" parameter (which prevents CSRF attacks) during the flow?

6. Crafting Your Access Control Test Strategy

Now, let's synthesize everything into a actionable checklist for a new feature or application.

Access Control Test Checklist

• ✅ Map all user roles and their defined permissions (RBAC matrix).
• ✅ For each role, verify access to all major modules/features (positive testing).
• ✅ For each role, attempt to access modules/features of a higher role (vertical privilege escalation test).
• ✅ Test horizontal access: Can User_A access, modify, or delete resources owned by User_B?
• ✅ Test direct object reference via URL and parameter tampering.
• ✅ Validate session logout and timeout behavior.
• ✅ Test authentication boundaries: password strength, account lockout, error messages.
• ✅ If applicable, test the complete OAuth login flow, including error and denial scenarios.

7. Common Tools and Mindset for Manual Testers

You don't always need expensive tools. Start with:

• Browser Developer Tools (F12): Your #1 tool for inspecting network requests (to see tokens and parameters), manipulating cookies, and testing client-side logic.
• Postman / Insomnia: For crafting and sending customized HTTP requests to test API authorization.
• Proxy Tools (like OWASP ZAP or Burp Suite Community): To intercept and modify traffic between your browser and the server for deeper security testing.

The Hacker Mindset: Always ask, "What if I change this? What if I go here directly? What is the system trusting that it shouldn't?" This curious, adversarial perspective is the core of effective security testing.

Conclusion: From Theory to Trusted System

Authentication and authorization testing is the bedrock of application security and trust.