Authorization Matrix Testing

Authorization Matrix Testing is a project type in RedVeil that performs systematic cross-account authorization testing against a single web application. It validates that every role in your application can only access the resources it is supposed to, and flags cases where one role can reach another role's endpoints or data.

How it works

An auth matrix test takes a target URL and two or more user accounts with different privilege levels. RedVeil's AI agent then:

1. Authenticates each account — logs in (or applies tokens/cookies) for every configured role and, optionally, an unauthenticated session.

2. Discovers resources — crawls the application and, if provided, imports routes from an OpenAPI/Swagger spec.

3. Builds the access matrix — rows are acting accounts (including unauthenticated if enabled), columns are resources or functions intended for each role.

4. Tests every cell — for each account × resource combination the agent makes requests with that account's session and records whether access was allowed or denied.

5. Classifies outcomes — each cell is classified as:

   Classification	Meaning
   Expected allow	The account was permitted and should be.
   Expected deny	The account was blocked and should be.
   Unexpected allow	The account was permitted but should not be — potential vulnerability.
   Unexpected deny	The account was blocked but should not be — potential logic/availability defect.
   Blocked / error	The request errored or was blocked for an unexpected reason.
   Skipped	The cell could not be tested in this run.

6. Reports findings — any unexpected-allow or other security-relevant outcome is filed as a finding with full evidence: acting account, target resource/role, request/response proof, and impact statement.

The matrix and findings are updated in real time as the agent works.

What it tests

• Vertical privilege escalation — lower-privilege roles attempting admin-only endpoints, role management, billing, sensitive exports.
• Horizontal privilege escalation — same-role account A accessing account B's data or actions.
• IDOR / BOLA — swapping object IDs, UUIDs, tenant identifiers, and path parameters across sessions.
• Function-level access control — non-admin sessions invoking create/update/delete/configuration endpoints.
• Unauthenticated access — (optional) verifying that protected endpoints reject requests with no credentials.
• OWASP-aligned web security — broken auth/session handling, CSRF gaps, sensitive data exposure, injection, XSS, and SSRF discovered during authorization flows.

Supported authentication types

All accounts in a single project must use the same auth type.

Creating a project

Web UI

1. Go to Projects → New Project.
2. Select Auth Matrix as the project type.
3. Enter the target URL — a single HTTP(S) URL for the application under test.
4. Choose the authentication type.
5. Add at least two accounts. Each account needs:
   • A unique role label (e.g. "Admin", "Viewer", "Editor").
   • The credentials matching the chosen auth type.
   • (Optional) Role guidance — a sentence describing what this role should be able to do. This helps the agent set accurate expected outcomes.
   • (Optional) 2FA secret — a TOTP secret if form login requires a one-time code.
6. Toggle Test unauthenticated access on or off (default: on).
7. (Optional) Paste or upload an OpenAPI/Swagger spec to expand endpoint coverage.
8. Click Create project.

CLI

pentest-agent project create auth_matrix \
  --name "Acme Auth Matrix" \
  --target https://app.acme.com \
  --auth-type form \
  --auth-matrix-accounts @accounts.json

--auth-matrix-accounts accepts a JSON array inline or as a @file reference. Each entry must have a unique label and the credentials matching --auth-type.

Example accounts.json:

[
  {
    "label": "Admin",
    "username": "admin@example.com",
    "password": "super-secret",
    "guidance": "Can manage users and billing"
  },
  {
    "label": "Viewer",
    "username": "viewer@example.com",
    "password": "viewer-secret",
    "guidance": "Read-only access only"
  }
]

CLI options

For more CLI context, see Projects.

Running a scan

Start a scan the same way as any other project type:

pentest-agent scan start <projectId>

Or click Start Scan in the web dashboard.

The agent authenticates each account, builds sessions, and begins cross-role testing. Progress is visible in real time on the dashboard.

Reading results

Authorization matrix panel

The dashboard replaces the network topology diagram with a live Authorization Matrix panel. Each row shows:

Rows are color-coded by classification:

• Green left border — expected allow or expected deny (working as intended).
• Amber left border — unexpected allow or unexpected deny (investigate).
• Red left border — blocked or errored.

The panel updates in real time as the agent tests each cell. You can expand it to full screen from the host detail view.

Findings

Findings from auth matrix tests follow the same format as all other RedVeil findings. Each includes:

• Acting account label and target role/resource.
• Request and response evidence.
• Impact statement explaining what cross-role action became possible.
• CVSS severity score.

Findings can be triaged (mark as false positive with a comment) and retested with one click, just like any other project type.

Reports

Auth matrix projects generate the same executive and standard reports available to other project types. The authorization matrix outcomes and cross-role findings are included in the report body.

Account field reference

Each account object in the accounts array supports these fields:

Editing a project

Auth matrix project settings can be updated after creation from the project settings page or via pentest-agent project edit. You can change the target URL, auth type, accounts, unauthenticated testing toggle, and OpenAPI docs.

Availability

Auth matrix testing is available on Full Coverage and Enterprise plans. See your account's usage page for current plan details.