The OWASP API Security Top 10 is a useful document precisely because it is boring. It does not describe novel attack research; it describes the ten categories that keep producing real incidents. What it does not do is tell you what any of them look like in a payments context, where the assets are money movement, customer identity and merchant configuration rather than generic records. This article restates each category in those terms and describes how we test it.
API1 — Broken object level authorisation
The endpoint verifies who you are, then acts on whatever identifier you supplied. In payments this shows up as transaction lookups, refund initiation, settlement report retrieval and merchant configuration reads that check authentication and not ownership. Opaque identifiers slow enumeration down; they do not fix the defect, and identifiers leak through webhooks, exports and support tooling anyway.
Testing method: two accounts, every endpoint that accepts an identifier, systematically. It is unglamorous and it produces more high-severity findings than everything else combined. Pay particular attention to endpoints added for partner integrations, which are often written outside the framework that enforces the check everywhere else.
API2 — Broken authentication
In payments the interesting failures are rarely a weak password policy. They are token validation that accepts an unexpected algorithm or skips the audience claim, refresh tokens without rotation or reuse detection, API key provisioning flows where a lower-privileged user can mint a higher-privileged key, and machine-to-machine credentials that never expire because rotation was deferred at integration time and never revisited.
Also worth testing: whether authentication downgrade paths remain reachable. A legacy client endpoint kept alive for one merchant is a legacy authentication mechanism kept alive for everyone who can find it.
API3 — Broken object property level authorisation
Two failures share this category. Excessive data exposure returns fields the caller should not read — full card metadata in a transaction object, internal risk scores, other merchants' identifiers in a shared response envelope. Mass assignment accepts fields the caller should not write, and in payments the dangerous writable fields are settlement account, fee schedule, risk tier and merchant status.
Test by submitting fields observed in administrative responses back through customer-facing write endpoints. A permissive object binder plus a shared data transfer object is still one of the fastest privilege escalations we find.
API4 — Unrestricted resource consumption
Rate limiting in payment platforms is usually present at the edge and absent where it matters. The questions are whether limits apply per credential and per resource rather than only per source address, whether they survive distribution, and whether expensive operations carry tighter limits than cheap ones. Settlement report generation, transaction search with wide date ranges and bulk export endpoints are the usual candidates.
There is also a direct cost dimension: an endpoint that triggers a paid downstream call — identity verification, sanctions screening, card network lookup — is a financial denial of service target even when it returns nothing useful to the caller.
API5 — Broken function level authorisation
Administrative capability reachable with ordinary credentials. Test administrative routes with a customer token, and test HTTP method variations — some frameworks route an unexpected verb to a handler that skips the authorisation filter applied to the documented one. In payment platforms the highest-value functions are usually manual transaction adjustment, refund override, merchant status change and fee configuration.
API6 — Unrestricted access to sensitive business flows
This category was the significant addition in the current revision and it is the one most relevant to payments. The question is not whether a single request is authorised, but what an automated caller could achieve at scale that the flow was never designed to permit.
- Card testing: low-value authorisations at volume to validate stolen card data
- Refund replay against a flow that is idempotent in intent but not in implementation
- Account existence enumeration through timing or error message differences
- Promotional or fee-tier abuse through repeated onboarding
These are business logic findings. No scanner reports them, and they are frequently the items with the largest quantifiable loss attached.
API7 — Server side request forgery
Payment platforms accept URLs constantly: webhook endpoints, logo and document uploads by reference, redirect destinations, merchant callback configuration. Each is a potential SSRF vector into internal services or the cloud metadata endpoint. Test with internal addresses, redirect chains, DNS rebinding and alternative encodings, and verify that egress filtering exists rather than assuming the allowlist in code is the only control.
API8 — Security misconfiguration
Verbose error responses that expose stack traces and internal hostnames, permissive CORS configuration on authenticated endpoints, missing security headers on API responses that are rendered in a browser context, and debug interfaces reachable in production. Also in scope: TLS configuration on partner-facing endpoints, which is often older than the customer-facing estate because a partner asked for compatibility years ago.
API9 — Improper inventory management
Undocumented, deprecated and staging endpoints reachable from production. In payments this commonly means a previous API version kept alive for one integrator, without the authorisation improvements added since. Establish the real inventory from observed routes, historic client bundles, mobile traffic and schema introspection rather than from documentation, then compare. The delta is usually where the finding is.
API10 — Unsafe consumption of APIs
The platform is also a client. Responses from identity providers, screening services, analytics and banking partners are frequently trusted more than user input, despite arriving over the same internet. Test what happens with a malformed, oversized or hostile response, and confirm the failure mode is deliberate: fail-open on a sanctions screening call is a design decision with regulatory consequences, and it should be a documented one.
Using the list well
Treat the ten categories as a coverage checklist, not a test plan. The categories tell you which classes must be examined; the payments context tells you which endpoints matter and in what order. A report that maps findings to the category and states the business consequence separately gives both the engineering team and the compliance function something they can act on, which is the point of the exercise.
