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.

| Field | Required content |

|---|---|

| Actor | Role plus relevant tenant/store/hub/assignment |

| Resource | Order, product, inventory, payout, address, profile, delivery, refund, or admin object |

| Operation | List, view, create, update, delete, assign, transition, refund, export, or impersonate |

| Relationship | Owner, seller, assignee, servicing hub, same tenant, or none |

| Required state | Order/payment/delivery state in which the operation is allowed |

| Field scope | Allowed and prohibited fields |

| Expected result | Allow or deny, including disclosure policy such as 403 versus 404 |

| Enforcement point | Route, policy layer, service, query predicate, database policy, or queue consumer |

| Evidence | Code reference, test ID, request ID, or audit event |

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 a