Your permission rules become the assessment
An application owner defines account profiles, approved endpoints and the expected result for each pairing. Each endpoint represents a synthetic record with a known marker. The matrix can expect access, access with a sensitive field hidden, or denial.
- Role and tenant boundaries
- Compare a standard user, another user with the same role, a user in another tenant, a privileged account, an anonymous visitor, or a disabled account. Choose the identities that match your application.
- Objects, functions and fields
- Declare which synthetic record or admin view each profile may read. Add a sensitive-field marker when a role may see the record but must not receive that field.
- Evidence for every cell
- Review the expected outcome, observed result, session state and reason for each endpoint/profile pair. Outcomes distinguish pass, finding, inconclusive and blocked.
A failed session should not look like a passing check
Tests use pre-issued sessions supplied through protected credential references. Missing credentials, rejected sessions and expired sessions are shown as blocked. An authenticated profile can establish its session through a configured session check or a successful permitted cell.
A denial passes only when the required session evidence exists and a permitted profile saw the same record in that run. Without that positive control, the result is inconclusive. Truncated responses also remain inconclusive when absence cannot be established.
From an application to a reviewed test plan
- Save the application. Record the approved targets, environment, roles, tenants, account references and testing authorization.
- Define the matrix. An owner selects who may read each synthetic endpoint and confirms the test records. Analysts and viewers can inspect the grid.
- Review the plan. Choose the Authenticated web & API assessment goal. See runnable and blocked profiles, missing inputs and coverage gaps before starting.
- Investigate and retest. Review the permissions grid and export its CSV or JSON. A matrix finding is resolved by a comparable retest only when its exact cell passes again.
Recurring assessments retain the matrix captured when scheduled. Refresh the assessment schedule after changing account profiles or permissions.
Precisely scoped authenticated testing
Matrix checks use GET requests to declared endpoints within the approved scope and request limits. VulnBeacon does not discover authenticated routes, submit forms, perform writes, or automatically log in, complete MFA, refresh sessions or log out.
A passing cell covers its declared record and response. List endpoints, alternate routes and other operations need their own coverage. Reports and linked retests preserve these distinctions alongside the evidence.
Authenticated-testing questions
Do I enter passwords in the matrix?
No. The matrix uses references to protected credentials for synthetic test accounts. The deployment owner assigns those references to the workspace; credential values are not included in reports.
Does this test login and MFA?
No. This workflow assesses declared read permissions using pre-issued sessions. Interactive authentication journeys remain outside its current coverage.
Can I combine this with external and source checks?
Yes. Guided multi-part goals can combine external exposure, API cases and code review as separate runs with their own reports. Missing inputs remain visible as gaps.