API Security Testing: REST and GraphQL
An API rarely shows its mistakes the way a broken web page does. There is no visual glitch to notice, just a response body that quietly returns more, or less, than it should. That makes API testing less forgiving of a shallow pass than a traditional web application review.
REST-specific issues worth checking
- Broken object-level authorization. Changing an ID in the URL or request body and getting back another user's data, one of the most common and most damaging API findings.
- Excessive data exposure. An endpoint returns a full internal object and lets the client-side code decide what to display, rather than the server deciding what to send in the first place.
- Missing rate limiting. No practical limit on how many requests an authenticated or unauthenticated client can make, which turns brute-force and enumeration attacks into a purely automated exercise.
- Inconsistent authorization between endpoints. A permission check enforced on one route but forgotten on a near-identical one that reaches the same underlying data.
GraphQL adds its own surface
GraphQL's flexibility is exactly what makes it worth testing differently from REST:
- Introspection left enabled. A GraphQL schema, if introspection is not disabled in production, will happily describe its entire structure to anyone who asks, handing an attacker a complete map of the API.
- Query depth and complexity. A single deeply nested query can force the server to do an enormous amount of work, a denial-of-service risk that has no equivalent in simple REST endpoints.
- Authorization applied inconsistently across resolvers. REST authorization bugs tend to live at the endpoint level. GraphQL authorization bugs tend to hide inside individual field resolvers, which is a very different place to look.
Enumeration still applies
The same enumeration discipline that applies to network targets applies to API surface area too: finding every version of an API (v1 alongside v2, a deprecated endpoint nobody removed), every environment (staging endpoints reachable from the public internet), and every undocumented route that never made it into the official API reference. Our piece on network enumeration covers the same principle at the infrastructure layer.
Findings still map back to familiar categories
Most API findings still map cleanly onto the OWASP Top 10 categories, broken access control and injection especially show up constantly in API testing. The delivery mechanism is different. The underlying weakness usually is not.
See it in an actual tool
Shieldome Siege enforces scope on every action and gates exploit confirmation behind a human approval, with a tamper-evident audit log of the whole engagement.
Read the documentation