A marketplace API is used by sellers, buyers, internal services and third-party tools. Which security properties must be enforced at the API layer, and which must not be?
Show the full answer Hide the answer
Enforced at the API layer
Authentication, establishing identity once so every downstream service receives an authenticated principal rather than re-implementing verification.
Coarse rate limiting and quotas, because the point is to reject excess before it consumes backend capacity. A limiter behind the expensive work is decoration.
Input validation and size limits, so malformed or oversized requests never reach a service.
Transport security and header policy, applied uniformly.
Enumeration resistance. This is the API-specific concern teams underestimate: sequential identifiers let anyone walk the entire dataset. Non-sequential identifiers, per-account rate limits on identifier lookups, and — importantly — identical responses for "not found" and "not permitted", since a distinguishable 404 versus 403 confirms existence and is itself a leak.
Enforced deeper, and why
Fine-grained authorization. Whether this account may access this specific order requires domain state the gateway does not have. The gateway establishes who; the service decides what they may do — and it must do so at the data access layer rather than per handler, so a new endpoint cannot forget.
Idempotency, because the key must be recorded in the same transaction as the effect it protects, and the gateway does not participate in that transaction.
Business rule validation, including anything involving prices, quantities or eligibility. A gateway enforcing business rules becomes a distributed monolith that every team must change and nobody owns.
Data minimisation in responses. Whether a field should be visible to this caller is a domain decision, and over-returning is one of the most common real-world data exposures — an internal field left in a serialiser and shipped to every client.
The properties that need attention on a marketplace specifically
- Field-level authorization. A buyer and a seller see different fields of the same order. Object-level permission is insufficient.
- Scraping resistance, which is a business concern as much as a security one — listing data is the platform's asset. Rate limiting alone does not stop distributed scraping; behavioural detection and progressively degraded responses are what work.
- Abuse of legitimate functionality — bulk messaging, offer spam, review manipulation. These pass every security control because they are authorised actions performed at scale, and they need volume limits per account tied to account age and standing.
The organising principle
The gateway enforces what can be decided from the request alone; everything requiring domain state lives with the service that owns the data. Misplacing authorization or idempotency at the gateway produces a system that is usually correct — which for security properties is the same as incorrect.