PS Product SecurityKnowledge Base

🧱 API Abuse Resilience and Rate Limits

Intro: Abuse control is part of API security, not a platform afterthought. The real goal is not just to slow down requests. The goal is to make high-value abuse paths expensive, noisy, and easy to contain.

What this page focuses on

  • actor-based, object-based, tenant-based, and workflow-based budgets;
  • expensive operation protection for export, search, model-backed, or bulk actions;
  • links between rate limits, business-logic abuse, and object-level authorization;
  • telemetry needed to distinguish normal growth from scripted abuse.

A practical mental model

Good API abuse controls usually combine four layers:

  1. Eligibility controls - who is even allowed to call the operation.
  2. Per-action budgets - how often it can be called by actor, tenant, object, or IP.
  3. Cost controls - how much work the server is willing to do per request.
  4. Detection and response - how the team notices, throttles, or temporarily blocks misuse.

A single global requests-per-minute limit is almost never enough.

The limits that matter most

Actor limits

Use these for login, reset, invite, export, search, and admin flows.

Object limits

Useful for comments, shares, purchases, coupon redemption, document export, and any action where repeated access to the same object is suspicious.

Tenant limits

Use these when a single tenant can generate disproportionate load or abuse shared expensive features.

Cost-aware limits

Use query complexity, page size caps, expansion limits, and asynchronous job queues when one request can be computationally expensive even at low request volume.

Practical guidance

  • do not use only a global requests-per-minute limit;
  • budget by actor, object, tenant, and operation type where risk justifies it;
  • limit page size, fan-out, field expansion, resolver depth, and bulk action size;
  • fail closed on anonymous expensive operations;
  • pair rate limits with logs that product teams can use to understand abuse patterns;
  • for GraphQL, combine rate limiting with depth and complexity controls.

Review questions

  • Which operations are profitable to automate?
  • Which operations are cheap for the attacker but expensive for us?
  • Which limits are shared across a tenant, and which are per actor?
  • Can a user stay under one limit while abusing many objects in parallel?
  • Do retries, webhooks, or batch endpoints bypass the intended budget model?

Release gate ideas

  • high-risk endpoints mapped to actor, object, and tenant limits
  • expensive operations have page-size or complexity caps
  • abuse telemetry tested in staging or replay data
  • alert thresholds reviewed with product or operations owners