Vapt Authz

Authorization & Access Control Testing

When Invoked

The user runs /vapt authz <url> or this skill is triggered as part of Wave 3 during /vapt audit.

Prerequisites

This is the most manual testing category. It requires understanding the application's roles and resources. Check for existing context:

• If VAPT-WAVE2-CONTEXT.md exists -> use discovered endpoints
• If VAPT-AUTH.md exists -> use authentication details and session tokens
• If no context -> discover endpoints and attempt to identify role-based differences

Phase 1: Access Control Mapping

1.1 Identify Roles

Determine the application's role hierarchy:

• Unauthenticated (anonymous)
• Authenticated (regular user)
• Privileged (admin, moderator, manager)
• Super admin / system

1.2 Endpoint Inventory

Build a matrix of endpoints vs roles:

• Which endpoints require authentication?
• Which endpoints are role-restricted?
• Which endpoints handle user-specific data?

# Check endpoint access as unauthenticated
curl -s -o /dev/null -w "%{http_code}" <url>/admin
curl -s -o /dev/null -w "%{http_code}" <url>/api/users
curl -s -o /dev/null -w "%{http_code}" <url>/dashboard

# Check with regular user token
curl -s -o /dev/null -w "%{http_code}" -H "Authorization: Bearer <token>" <url>/admin

Phase 2: Horizontal Privilege Escalation (IDOR)

2.1 Direct Object Reference Testing

For endpoints that reference user-specific data (user IDs, order IDs, file names):

1. Identify the reference pattern (numeric ID, UUID, slug)
2. Access the resource as the authenticated user
3. Modify the reference to another user's resource
4. Check if access is granted

# If user 123 can access their own profile:
curl -s -H "Authorization: Bearer <user_123_token>" <url>/api/users/123

# Try accessing user 124's profile:
curl -s -H "Authorization: Bearer <user_123_token>" <url>/api/users/124

Test across:

• User profiles (/api/users/{id})
• Orders/transactions (/api/orders/{id})
• Documents/files (/api/documents/{id})
• Messages (/api/messages/{id})
• Settings (/api/settings/{user_id})

2.2 ID Enumeration Patterns

2.3 Scoring

Phase 3: Vertical Privilege Escalation

3.1 Admin Function Access

Test if regular users can access admin-only endpoints:

# With regular user token, try admin endpoints
curl -s -H "Authorization: Bearer <regular_token>" <url>/admin/users
curl -s -H "Authorization: Bearer <regular_token>" <url>/api/admin/settings
curl -s -H "Authorization: Bearer <regular_token>" <url>/api/admin/export

3.2 Role Manipulation

Check if the role can be modified in:

• User profile update requests (mass assignment)
• JWT claims (if JWT is used)
• Cookie values
• Hidden form fields

# Try to elevate role via mass assignment
curl -s -X PUT -H "Authorization: Bearer <token>" \
    -H "Content-Type: application/json" \
    -d '{"name":"test","role":"admin"}' \
    <url>/api/users/profile

3.3 Scoring

Phase 4: Forced Browsing & Authentication Bypass

4.1 Unauthenticated Access

Test if protected pages are accessible without authentication:

# No auth header -- should all return 401/403
curl -s -o /dev/null -w "%{http_code}" <url>/dashboard
curl -s -o /dev/null -w "%{http_code}" <url>/api/users
curl -s -o /dev/null -w "%{http_code}" <url>/admin
curl -s -o /dev/null -w "%{http_code}" <url>/settings

4.2 Direct URL Access

Check if pages behind multi-step flows are directly accessible:

• Payment confirmation page without going through checkout
• Step 3 of a wizard without completing steps 1-2
• Admin setup page after initial setup

4.3 Scoring

Phase 5: HTTP Method Tampering

5.1 Method Override

Some frameworks support method override headers:

# If POST is blocked, try overriding
curl -s -X POST -H "X-HTTP-Method-Override: DELETE" <url>/api/resource/123
curl -s -X POST -H "X-Method-Override: PUT" <url>/api/resource/123

# Try different HTTP methods
for method in GET POST PUT DELETE PATCH OPTIONS HEAD; do
    echo "$method: $(curl -s -o /dev/null -w '%{http_code}' -X $method <url>/api/resource/123)"
done

5.2 Scoring

Phase 6: Path Traversal

6.1 Directory Traversal

Test parameters that accept file paths:

# Basic traversal
curl -s "<url>/api/files?path=../../../etc/passwd"
curl -s "<url>/api/files?path=....//....//....//etc/passwd"

# Encoded variants
curl -s "<url>/api/files?path=%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd"
curl -s "<url>/api/files?path=..%252f..%252f..%252fetc%252fpasswd"

6.2 Scoring

Phase 7: File Upload Access Control

7.1 Upload Restrictions

If file upload exists, test:

• File type validation (bypass with double extension, null byte, content-type manipulation)
• File size limits
• Upload path accessibility (can uploaded files be directly accessed?)
• Execution prevention (can uploaded scripts be executed?)

7.2 Scoring

Phase 8: Output

Terminal Output

Dev mode: Explain each access control flaw, the difference between horizontal and vertical escalation, OWASP access control best practices.

Pro mode: Access control matrix and findings table.

VAPT-AUTHZ.md

# VAPT Authorization & Access Control Report

## Target: <url>
## Date: <timestamp>

## Role Matrix
| Endpoint | Unauth | User | Admin | Expected |
|----------|--------|------|-------|----------|
| /admin | ... | ... | ... | Admin only |
| /api/users/{id} | ... | ... | ... | Own data only |
| ... | ... | ... | ... | ... |

## IDOR Findings
<horizontal privilege escalation results>

## Vertical Escalation Findings
<privilege escalation results>

## Forced Browsing
<unauthenticated access results>

## HTTP Method Tampering
<method override results>

## Path Traversal
<traversal results>

## File Upload
<upload restriction results>

## Findings
<scored findings table>

## Suggested Next Steps
- /vapt logic <url> -- test business logic around access controls
- /vapt api <url> -- test API-specific access controls
- /vapt report <url> -- compile full report

Cross-Skill Integration

• Authorization findings weight 12% in Security Posture Score
• IDOR findings inform vapt-logic testing
• Access control gaps combined with injection findings amplify risk ratings