Marketplace Rbac Audit

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

Compare request and response schemas by role. Verify that mass assignment, serializer defaults, ORM spreads, exports, and error payloads cannot expose or change protected fields.

Examples of sensitive fields include:

• another customer's address or contact details;
• vendor settlement and payout configuration;
• courier identity or precise location outside an active delivery need;
• internal fraud, moderation, cost, or risk fields;
• role, tenant, hub, assignment, price, refund, and payment-state attributes.

5. Audit State Transitions

Build an allowlist of valid transitions with authorized actors and invariants. For example, “assigned courier may mark picked up” is incomplete unless the order is assigned to that courier, is in the expected prior state, belongs to the same operational scope, and has not been cancelled.

Reject client-selected final states when the server should derive the transition. Verify idempotency and concurrency behavior for assignment, cancellation, refund, fulfillment, and delivery confirmation.

6. Verify Indirect Paths

Apply the same policy to:

• nested resources and parent-child ownership;
• invoice, receipt, label, media, and document downloads;
• search, autocomplete, counts, and analytics;
• bulk update, import, and export;
• webhook and queue-triggered changes;
• cached responses and pre-signed URLs;
• support tools, impersonation, and “view as user” modes.

UI visibility is evidence of presentation only. A hidden button, disabled control, or unpublished link does not enforce authorization.

7. Design Negative Tests

Use synthetic identities and records in an authorized test environment. For every important allowed case, add the nearest denied cases:

• same role, different owner;
• same role, different vendor/store/hub/tenant;
• correct role, wrong assignment;
• correct relationship, invalid resource state;
• expired, disabled, removed, or downgraded membership;
• protected field added to an otherwise valid request;
• bulk request containing one unauthorized object;
• stale session after role or assignment revocation;
• guessed nested-resource or download identifier.

Do not use real customer records as “victim” data. Do not enumerate identifiers or run live probes without explicit target authorization and a bounded test plan.