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.

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.