Marketplace RBAC Audit

Overview

Audit authorization in marketplaces where customers, vendors, fulfillment staff, couriers, support agents, administrators, and service accounts act on shared orders and resources. Build an explicit policy matrix, trace enforcement from route to data access, and verify both allowed and denied behavior without treating hidden UI controls as security.

This is a read-only review by default. It does not grant permission to scan a live service, create test accounts, alter permissions, or access another person's data.

When to Use This Skill

• Reviewing authorization in a marketplace, delivery platform, multi-vendor store, or fulfillment system.
• Adding or changing roles, administrative powers, ownership rules, or order-state transitions.
• Investigating whether one customer, vendor, courier, hub, or tenant can access another party's resources.
• Preparing negative authorization tests before release or after an access-control incident.

Do not use this skill for authentication design alone, generic multi-tenant architecture, offensive ID enumeration, or penetration testing outside an explicitly authorized test environment.

Establish the Authorization Contract

Record the actual actors and resources instead of assuming standard role names.

For each actor, capture:

• identity source and role-assignment authority;
• tenant, organization, store, hub, region, or assignment scope;
• resource relationships such as owner, seller, assigned courier, servicing hub, or support case;
• permitted operations and state transitions;
• emergency, support, delegated, and service-account access;
• audit-log and approval requirements for privileged actions.

Separate these policy dimensions:

1. Role — what this actor type may generally do.
2. Relationship — which specific object the actor may access.
3. Tenant or operational scope — where the permission applies.
4. Resource state — whether the operation is valid now.
5. Field scope — which attributes may be viewed or changed.

A matching role is not sufficient when ownership, assignment, tenant, state, or field rules fail.

Build the Policy Matrix

Create one row per meaningful actor-resource-operation combination.

Mark an undocumented decision as UNDEFINED; do not invent a permission merely because current code allows it.

Audit Workflow

1. Inventory Entry Points

Map HTTP routes, GraphQL operations, server actions, background jobs, webhooks, file downloads, exports, administrative tools, and queue consumers that access marketplace resources. Include bulk operations and alternate HTTP methods.

2. Trace Identity and Scope

For every entry point, trace how the authenticated principal becomes an authorization context. Confirm that role, tenant, store, hub, assignment, and delegation claims come from a trusted server-side source and are current enough for the operation.

Do not accept actor, tenant, owner, vendor, hub, courier, price, payout, or privilege fields from the request merely because they are present in a signed-in session.

3. Trace Object Authorization

Follow the resource identifier from request to data access. Prefer a scoped query or atomic mutation that includes every required predicate:

resource_id
+ tenant/store/hub scope
+ owner/seller/assignee relationship
+ permitted current state
= authorized object or no match

A separate “check then update” sequence may race with reassignment or state changes. Record where a transaction, conditional update, row-level lock, or equivalent consistency control is required.

4. Check Field-Level Authorization

…