PS Product SecurityKnowledge Base

🧭 API Authorization, Business-Flow Abuse, and Third-Party API Consumption

Why this page exists: serious API failures rarely live in one category only. The real incidents usually combine weak authorization, profitable workflow abuse, and too much trust in upstream or third-party APIs. This page consolidates those concerns into one reviewer lens.

The three-layer model

1. Authorization layer

Answer these questions first:

  • who is the caller?
  • what route may they execute?
  • which object may they touch?
  • which properties may they read or mutate?

If route-level auth is correct but object or property checks are weak, the API is still unsafe.

2. Workflow layer

Once the caller can legitimately reach the API, ask:

  • what state transition does this endpoint enable?
  • can that state transition be repeated, parallelized, or raced for profit?
  • does the workflow rely on frontend sequence instead of server-side invariant checks?

This is where tenant abuse, promo abuse, export abuse, quota abuse, and recovery-flow abuse usually emerge.

3. Dependency layer

Finally ask:

  • which external API, webhook, partner feed, enrichment service, or SaaS callback is trusted here?
  • what happens if the upstream data is malformed, malicious, stale, replayed, or overbroad?
  • does this integration enlarge the blast radius of an authorization or workflow mistake?

Common composite failure patterns

Authenticated but over-authorized

A token is valid, but the server trusts a client-supplied tenant ID, account ID, or export job ID. The bug is not authentication failure - it is authorization attached to the wrong source of truth.

Legitimate endpoint, abusive sequence

Each request is “valid,” but the workflow as a whole is unsafe: repeated coupon redemption, invite amplification, asynchronous export farming, or support-recovery chaining.

Safe internal logic, unsafe upstream trust

The product has decent local controls but accepts fields, redirects, status callbacks, or enrichment data from a third-party API without normalization, schema validation, replay control, or cost limits.

Workflow invariants to write down explicitly

A strong API review should document invariants such as:

  • one user may act only within the tenant context derived server-side;
  • sensitive state transitions require eligibility to be checked at execution time, not only when the UI first loaded;
  • recovery, admin, and support workflows are separately logged and constrained;
  • partner callbacks cannot create broader authority than the user or service that initiated the integration;
  • expensive actions are budgeted by actor, tenant, object, and operation cost.

If the team cannot express the invariant in one or two plain sentences, implementation mistakes are likely.

Review workflow

Step 1 - pick the sensitive business objects

Examples: account, tenant, export, invite, coupon, subscription, recovery token, admin session, partner installation, sync job.

Step 2 - map the state transitions

For each object, note create/read/update/delete operations plus bulk actions, retries, imports, callbacks, and asynchronous jobs.

Step 3 - test object and property authorization

Check route-level, object-level, and field-level access separately. Foreign identifiers, hidden fields, optional flags, and bulk operations matter most.

Step 4 - test profitable abuse paths

Try high-volume repetition, replay, race, sequencing, and distribution across many accounts or tenants.

Step 5 - test upstream trust

Validate transport, auth, schema, timeout, redirect handling, payload size, retry behavior, signature verification, and replay windows for every third-party integration in the path.

Release gate ideas

  • foreign-object tests executed for create, read, update, delete, export, and bulk endpoints
  • sensitive workflow invariants written in the design or review notes
  • third-party API inputs normalized and validated before downstream processing
  • expensive actions have actor, tenant, and cost-aware controls
  • support and admin bypass paths reviewed separately from normal user flows

Use this page with