API Security Testing for the Systems Behind Your App
Direct testing of the APIs that your mobile app, website or partners call, because the screen a user sees is often not the only way in. GullySystem probes the interface for what it hands over when asked correctly.
What API Security Testing Covers
An API is tested by talking to it directly, the way a script or another system would, rather than only through the app screens sitting in front of it. This finds problems a well-behaved app interface would never trigger on its own, because the interface hides an option that the API underneath still accepts.
Where APIs Quietly Leak Data
- One shared key is issued to every partner, so any of them can query records belonging to the others
- Changing an order or record number in the request returns someone else's data, even though the app screen never lets you type it in
- There is no limit on how many requests can be sent, so a script can pull an entire customer list overnight
- An error response includes internal details — a stack trace, a file path, a database name — never meant to leave the server
What Gets Tested
Authentication and Token Handling
How tokens are issued, how long they last, and whether an old or expired one can still be reused.
Record-Level Permission Checks
Whether changing an identifier in the request lets one account reach another account's record.
Rate Limits and Bulk Extraction
Whether a script can pull far more data far faster than a normal user ever would, unnoticed.
Input Handling and Error Responses
What unexpected or malformed input does to the API, and what its error messages give away.
Who Needs This
- Businesses whose mobile app is really a thin layer over an API doing all the real work
- Companies handing partners or franchisees direct API access to place orders or pull records
- Marketplaces and platforms where one seller or vendor's data must stay separate from another's
How This Differs From an Application Review
An application review tests the screens a person sees. This tests what the API will do for anyone who skips the screen entirely and talks to it directly with the right tool. A business is rarely fully covered by one without the other where both exist.
Frequently asked questions
Do we need API documentation before you can test it?
It helps but is not required. Where documentation, a Postman collection or a code contract exists, testing starts faster. Where none exists, part of the engagement is discovering what endpoints the app actually calls before testing them.
What drives the cost of API testing?
The number of distinct endpoints and the number of access levels or account types that call them — a public API with one tier of access costs less to cover than a partner API with several tiers, each needing its own set of test credentials.
What decides how long API testing takes?
How quickly test credentials for each access level or partner tier are issued, and how much of the API surface is documented versus needing to be mapped first. A well-documented API with ready credentials moves faster than one discovered as we go.
Does it matter whether our API is REST, GraphQL or something else?
No. The testing approach adapts to the style of API in use — the questions asked of it, about authentication, permissions and limits, stay the same regardless of the format the requests and responses take.
Who owns the findings and any fixes made?
You do. The report, the evidence and any changes made to the API's authorisation logic during remediation belong to your business, along with all credentials issued for the engagement.
What do you need to hand over before testing starts?
API documentation or a collection of example calls if one exists, and a working credential for every distinct account type or partner tier the API serves, so record-level permission checks can be run properly.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private