Effective API Penetration Testing in Thailand

Most applications stopped being “websites” years ago. They are APIs now: microservices calling microservices, a mobile client on one end and a payment rail on the other. The security conversation has not fully caught up. Teams still buy “web application penetration tests” that spend 80% of the effort on the front end, while the APIs behind it, where the money and the data actually move, go under-tested.

Why APIs break scanners #

Automated web scanners are built around the page model: crawl links, find forms, inject payloads. APIs do not present pages. They present routes, methods, and schemas, and the interesting behaviour lives in the business logic between them.

Consider an object-level access flaw: a user changes user_id=1024 to user_id=1025 in a request and reads someone else’s records. No signature fires. No payload is malicious. The scanner sees a normal request and moves on. This is Broken Object Level Authorisation (BOLA), the number one entry on the OWASP API Security Top 10, and it is invisible to almost every automated tool.

That is the core argument for human-led API testing: the most damaging flaws are design flaws, and design flaws require an analyst who understands the business context to find them.

What an effective API test actually covers #

A meaningful API assessment goes well beyond running a scanner against an OpenAPI spec:

• Authentication and authorisation: token handling, scope checks, and object-level access across every role boundary.
• Business logic: can a user negative-price an order, replay a payment callback, or skip a workflow step by calling the next endpoint directly?
• Data exposure: which endpoints over-return fields, and which accept fields the client should never send.
• Rate limiting and abuse: enumeration, credential stuffing, and account-takeover paths that abuse weak throttling.
• Integration boundaries: the webhooks, third-party callbacks, and message queues where trust is often assumed and never verified.

This is why the best engagements pair manual offensive tradecraft with AI-assisted recon and fuzzing: the automation expands coverage, the human judges severity and context.

Continuous, not annual #

A once-a-year API test is a point-in-time snapshot of a system that deploys weekly. By the time the report is written, the endpoints have changed. The modern approach folds API security checks into the delivery pipeline:

1. Shift-left with static analysis and schema validation in CI.
2. Test per release: a focused review when the API surface changes.
3. Annual deep-dive: a full, human-led assessment for the audit trail and the business logic the pipeline cannot judge.

PCI DSS Requirement 6 and Requirement 11.4 both push in this direction for organisations touching card data, and Bank of Thailand digital channel guidance raises the bar again for financial systems.

What automated scanners cannot see #

It is worth being specific about what automation misses, because the gaps are not random: they cluster exactly where the money moves.

BOLA in practice. A scanner tests the endpoints it discovered and the parameters it understood. Consider an invoice API: GET /invoices/8842 returns the caller’s own invoice, so the scanner logs a pass. But GET /invoices/8843, another customer’s invoice, may return equally happily, and no scanner will try it, because understanding that 8843 belongs to someone else requires knowing what ownership means in your business. Every object identifier that crosses a tenant boundary is a potential BOLA, and only an analyst enumerating objects across accounts will find them.

Business logic flaws. Scanners test whether requests succeed or fail; logic flaws live in requests that succeed when they should not. Real examples from engagements: applying a coupon code twice because the redemption check happens after payment capture; transferring a booking between accounts without re-authorisation; cancelling a paid order after shipment because the cancel endpoint never checks fulfilment state. Each returns HTTP 200. Each is a financial loss with no error message anywhere.

Trust assumptions between services. Inside a microservices estate, one service routinely trusts headers, tokens, or internal endpoints presented by “the caller”, because in the design diagram the caller was always another internal service. Then one service gets compromised, or one internal endpoint becomes reachable from a less trusted network segment, and those inherited trust assumptions become an attacker’s ladder: authenticate against the weak edge service, then present its identity downstream where the valuable APIs live. Finding this requires reasoning about the architecture as its designers intended it, then testing it as an attacker would traverse it.

None of these appear in scanner output. All of them appear in reports written by analysts who took the time to understand what your API is actually for.

Our API & Application Security Review combines source review with manual exploitation, and our Penetration Testing covers the perimeter and segmentation boundaries around it. If you want a test scoped to your actual architecture, schedule an Engineering & Scoping Session.