QA should test authorization after a pentest fix with a role-and-tenant matrix built from the security invariant, not by replaying only the reported request. Each protected action needs positive and negative cases across owner, same-role peer, higher and lower privilege, foreign tenant, revoked identity and relevant object states. Verify the authoritative outcome and keep the matrix as release regression.

Define the architecture question before testing

Translate the finding into a product rule QA can evaluate repeatedly. If the issue was “user A read user B’s invoice,” the rule is not “this URL returns 403.” It is “only authorized relationships may view invoice data through any route, export, search, cache or job.”

Write the expected security invariant and the prohibited outcome in language that engineering, security and operations interpret the same way. Name the identity, trust transition, protected asset and authoritative state. That statement becomes the basis for scope, evidence and retesting.

Build the minimum evidence pack

  • A current component and trust-boundary diagram for the environment under test.
  • Identity, credential, network and data-flow details relevant to the decision.
  • Representative accounts, workloads and synthetic records with known ownership.
  • Logs or traces that follow the action through every material control point.
  • Explicit safety limits, stop conditions, owners and restoration steps.

Obtain the original finding and preconditions, fixed build, root-cause explanation, affected policy or component, role definitions, tenant and sharing model, route inventory, paired accounts, canary objects and access to authoritative state. Clarify intended exceptions with product and security owners.

Build dimensions before cases

Start with actor role, tenant, ownership, action and object state. Add authentication age, channel or feature flag only when they change policy.

  • List every material role and platform-level exception.
  • Define owner, peer, collaborator and foreign relationships.
  • Separate read, update, delete, share, approve and export.
  • Include active, archived, transferred and revoked states.
  • Map web, mobile, API and asynchronous consumers.

Maintain a compact matrix with expected decision and rationale. Avoid a combinatorial explosion by prioritizing high-risk actions and equivalence classes.

Create reliable synthetic fixtures

Authorization regression needs stable relationships that are easy to inspect and reset.

  • Create at least two users per horizontal role.
  • Create two tenants with unmistakable canary data.
  • Seed shared and unshared objects.
  • Prepare privileged and revoked identities.
  • Automate reset without copying customer data.

Record IDs and ownership in test configuration while keeping credentials in approved secret storage. Test failures should name the relationship, not expose secrets.

Test denied cases at authoritative state

A denial is successful only if no protected data or side effect escapes. Framework errors, partial GraphQL data and delayed jobs can hide failures.

  • Inspect response body, headers and field-level data.
  • Verify database or service state did not change.
  • Check files, exports, notifications and queues.
  • Compare foreign and nonexistent object behaviour.
  • Review security-relevant audit events.

Capture before-and-after state and correlation IDs. Treat a different status code as one observation, not the entire oracle.

Test allowed cases after the security fix

A restrictive patch can break legitimate owners, collaborators, administrators or automated processes. Positive coverage prevents denial-of-service-by-remediation.

  • Repeat the owner’s normal workflow.
  • Test approved sharing and delegation.
  • Verify scoped tenant administration.
  • Run legitimate background or integration actions.
  • Check error handling for expired or changed relationships.

Link allowed cases to the same invariant and build. Security closure requires preserving intended business behaviour.

Expand from the endpoint to the policy pattern

Ask which routes, resolvers, services, repositories and jobs use the changed control. Select representative cases from each consumer class.

  • Test detail, list, search and bulk operations.
  • Test alternate API versions and methods.
  • Include export, file and asynchronous paths.
  • Sample services using the same authorization helper.
  • Look for direct access that bypasses middleware.

Record which pattern was sampled and what remains outside regression. Do not claim API-wide closure from one path.

Automate at the right level

Put fast policy logic in unit tests, object-path checks in service integration tests and critical trust chains in end-to-end tests. Keep manual adversarial retesting for uncertain composition.

  • Generate negative cases from role-action policy data.
  • Use API fixtures for cross-user and cross-tenant objects.
  • Fail tests when authorization context is missing.
  • Run critical matrix cases in release gates.
  • Track flaky concurrency or async cases separately.

Automation should assert the prohibited business effect, not hard-code one response string. Version fixtures alongside role and tenant model changes.

Coordinate independent retesting

QA regression and pentester retesting answer related but different questions. QA proves maintained product behaviour; the tester independently validates the exploit and adversarial variants.

  • Share the fixed build and root-cause summary.
  • Preserve original accounts or equivalent relationships.
  • Avoid coaching the tester toward only the expected payload.
  • Compare QA matrix results with retest evidence.
  • Keep unresolved scope limitations visible.

A closure record should cite QA regression and independent retest separately. Neither should be implied when it did not occur.

Execute as controlled hypotheses

  1. Establish the legitimate baseline and capture authoritative state.
  2. Change one trust variable—identity, route, scope, object, time or environment.
  3. Observe the decision at each layer rather than relying only on the response.
  4. Stop at the minimum proof that demonstrates or rejects the hypothesis.
  5. Restore test state and record residual uncertainty or blocked coverage.

Run with dedicated synthetic identities and resettable objects. Sequence lifecycle tests carefully to avoid invalidating later cases. Coordinate asynchronous and export checks with operations, and prevent test notifications or files from reaching real users.

Report the architectural consequence

For each failed case, include matrix coordinates, expected policy, request or action, observed result, authoritative effect and build. Summarize coverage by role, tenant, action and consumer class so gaps are visible.

Separate observed evidence from inference. State prerequisites, repeatability, blast radius and the shared component responsible for the decision. When multiple findings have one architectural cause, keep the individual proofs but group the remediation around the common control.

Required closure evidence

  • The original proof no longer succeeds.
  • A legitimate workflow still succeeds under the intended identity and route.
  • Alternate consumers of the same pattern enforce the same invariant.
  • Telemetry records both allowed and denied decisions with useful context.
  • The architecture record and threat assumptions reflect the new control.

Remediate at the durable control point

When QA finds another bypass, reopen the root-cause analysis rather than stacking endpoint conditions. Improve the shared policy, tenant-aware data access and missing-context behaviour, then update the matrix and regression generator.

Retest the invariant, not just the payload

Re-run the original exploit, the full affected equivalence class and legitimate positive cases. Sample alternate channels, lifecycle states and asynchronous effects. Keep the cases in the normal release suite after independent closure.

Use the NIST Technical Guide to Information Security Testing and Assessment for assessment planning and evidence discipline, and the OWASP Web Security Testing Guide for relevant application techniques. Adapt both to the system-specific trust decision described here.

The architecture decision

QA should convert the pentest finding into a durable authorization oracle and prioritized matrix. That proves the fixed policy across relationships and prevents the same defect from returning through a new endpoint or product state.

Ask WIMD to align retesting with QA regression across roles, tenants, object relationships and API consumers.