API Security Testing

API Security Testing for SaaS Products

Manual testing for REST and GraphQL APIs, authorization models, token boundaries, object-level access, tenant isolation, and API-driven business logic.

Not sure which review fits? Start with a general request and I will recommend the right scope.

1Request
2Scope Discussion
3Recommended Review
4Testing
REST APIsGraphQL APIsAuthorization ReviewsManual Testing
Coverage

API Attack Surface Coverage

Coverage spans REST and GraphQL authorization boundaries, token and scope validation, tenant isolation, response shaping, and valid API actions that can be combined into business logic abuse.

01

REST APIs

Endpoint behavior, HTTP methods, object references, filters, pagination, and response handling, checked for the broken object-level authorization and insecure direct object references that let one account reach another's data.

02

GraphQL APIs

Schemas, resolvers, mutations, nested queries, batching, introspection, and field-level exposure, the areas where GraphQL's flexibility most often hides authorization gaps that a REST-focused review would miss.

03

Authentication

Login exchanges, session creation, refresh flows, credential recovery, and identity transitions, tested for the weaknesses attackers use to hijack accounts or bypass multi-factor authentication.

04

Authorization

Role enforcement, object ownership, action permissions, and cross-user or cross-tenant access, the exact control failures behind most IDOR and BOLA findings in production APIs.

05

Token Validation

JWT claims, OAuth scopes, signature handling, expiry, audience, and privilege boundaries, so a stolen or over-scoped token can't be replayed into more access than it was ever issued.

06

Tenant Isolation

Organization boundaries, shared identifiers, tenant context, and data segregation controls, the layer that keeps one customer's data from leaking into another customer's session.

07

Business Logic

Workflow sequencing, state manipulation, replay, limit bypasses, and unintended product actions, the class of abuse no automated scanner can catch because nothing about it is technically invalid.

08

Third-Party Integrations

Webhooks, partner APIs, service credentials, trust assumptions, and external data paths, since a single overprivileged integration can become a backdoor into the rest of the platform.

Exploit Path

How Modern APIs Get Breached

Attackers often use legitimate sessions and valid API actions. Risk appears when token scope, object ownership, tenant isolation, or workflow rules are enforced inconsistently across the request path, turning a normal authenticated user into an unintended path to another tenant's data.

Validated outcomeCross-tenant sensitive data exposure
Common Findings

Common API Vulnerabilities Identified

Typical findings include excessive data exposure, broken object authorization, scope bypasses, resolver-level GraphQL weaknesses, and business logic abuse that depends on product context.

BOLA-01

IDOR / BOLA

Object identifiers expose records outside the caller's ownership or tenant boundary, one of the most reported API vulnerabilities year over year and still one of the easiest to miss in code review.

GET /accounts/{id}
GQL-02

GraphQL Enumeration

Queries reveal internal IDs, relationships, hidden fields, or account existence signals, turning a single flexible query into a map of your entire data model.

query user(id)
AUTHZ-03

Broken Object Authorization

Valid sessions can invoke actions without a matching ownership or policy check, letting an authenticated user modify or delete records that were never theirs.

PATCH /projects/{id}
TOKEN-04

Token Scope Failures

JWT or OAuth permissions allow broader reads, writes, or administrative actions than intended, often because a scope was left overly broad during development and never tightened before launch.

scope: read:*
DATA-05

Excessive Data Exposure

Responses return sensitive fields that the UI does not need and the caller should not receive, leaking internal fields, PII, or credentials to any client that inspects the raw response.

200 response fields
LOGIC-06

Business Logic Abuse

Legitimate API functions can be sequenced or replayed to bypass product rules and controls, from skipping payment steps to unlocking features a plan tier was never meant to include.

state transition
TENANT-07

Multi-Tenant Isolation Issues

Tenant context is missing, user-controlled, or inconsistently enforced across endpoints, the exact gap that turns a single-tenant bug into a cross-customer data breach.

X-Tenant-ID
INT-08

Insecure Integrations

Webhooks and partner connections trust unsafe input, weak signatures, or overprivileged credentials, giving an attacker a trusted-looking path straight into internal systems.

POST /webhooks
Deliverable Preview

Example Finding Report

Each finding connects endpoint evidence to product risk, with developer-ready remediation, ownership context, and clear retest criteria.

Evidence-backedEndpoint-specificEngineering-ready
thf-api-review.pdfHIGH
Finding

Broken Object Authorization

Affected endpointGET /api/v1/accounts/{id}
ImpactCross-tenant data exposure
Root causeMissing ownership validation
RecommendationEnforce authorization checks before record retrieval and bind object access to the authenticated tenant context.
Tenant A userAccount ID BRecord returned
Method

API Review Process

A focused review moves from architecture and role mapping to manual abuse-case testing, evidence-backed reporting, and fix validation.

01

Scope

Define APIs, roles, tenants, environments, and high-risk product workflows, so testing time is spent on what actually matters to your product, not a generic checklist.

02

Map

Trace schemas, endpoints, identities, trust boundaries, and sensitive data paths, building the same map an attacker would build before deciding where to push.

03

Test

Run manual authorization, abuse-case, token, GraphQL, and business logic testing by hand, against real roles and real data, not an automated pattern match.

04

Validate

Confirm the exploit path, affected users, tenant reach, and practical impact, so every finding in the report is proven, not theoretical.

05

Report

Document requests, evidence, reproduction, root cause, and engineering guidance in a format your engineers can act on the same day they receive it.

06

Retest

Verify critical fixes and confirm the vulnerable path is no longer reachable, closing the loop instead of leaving that confirmation to guesswork.

Difference

Why Automated Scanners Miss These Issues

API risk is often hidden in who can call an action, which object they can reference, and how legitimate functions combine across a workflow, exactly the context an automated API security scanner has no way to evaluate.

Automated Scanning

Pattern and response checks

  • Known signaturesand configuration checks
  • Limited identityand tenant context
  • No ownership validationacross workflows
  • Severitywithout exploit confirmation
  • Generic outputrequiring interpretation
✓ RecommendedThe Hidden Finds

Manual, context-aware validation

  • Workflow testingacross roles and tenants
  • Authorizationand object access validation
  • Business logicand abuse-case review
  • Exploit confirmationwith practical impact
  • Developer-ready evidenceand guidance
Output

What You Receive

A concise security deliverable with affected endpoints, exploit evidence, practical fix guidance, and retest criteria for engineering and product stakeholders, so nothing gets lost in translation between the security review and the sprint that fixes it.

Review outputValidated and prioritized
Ready for engineering handoff
01

Reproduction Steps

Requests, role context, prerequisites, and a reliable path engineers can replay step by step to see the issue for themselves.

02

Impact Analysis

Affected users, tenant reach, exposed data, and the product consequence of exploitation, framed in terms the business can act on, not just a CVSS number.

03

Exploit Path

The authorization or workflow failure connecting attacker-controlled input to impact, laid out as the same chain an attacker would follow.

04

Fix Guidance

Practical control recommendations aligned to the endpoint, resolver, or permission model, written for the engineer who has to ship the fix.

05

Retest Validation

Clear verification criteria and confirmation notes for remediated high-risk findings, so nothing is marked closed until it's actually closed.

06

Risk Prioritization

Findings ordered by reachability, exploitability, data sensitivity, and customer impact, not a generic severity label copied from a scanner.

Engagement

Scoped to Your API Surface, Not a Fixed Package

Watch how a quote actually gets built: each real factor is weighed in sequence, ending on how pricing is decided, not a flat number pulled from a rate card.

✓
Distinct roles & tenant boundaries
✓
REST / GraphQL surface size
✓
Business logic & workflow depth
✓
Retest after fixes
Scoping in progress
weighing scope
Fixed quote issued before testing starts. No hourly billing, no surprise add-ons.
Who is Testing

Manual Testing, Performed Directly by the Founder

A side by side pace comparison, not to say automation is worthless, but to show exactly where it stops and manual review has to take over.

Automated Scan
Manual Review
Every one of these manual passes is run directly by the founder of The Hidden Finds, not a delegated team, not a relabeled scanner report, using patterns drawn from active, ongoing bug bounty and disclosure work on live SaaS platforms.
FAQ

Frequently Asked Questions

Answers for teams reviewing REST APIs, GraphQL APIs, authorization boundaries, tenant isolation, and API-driven product risk.

What is API security testing?

API security testing reviews how requests, tokens, roles, object references, and workflows behave when abused by authenticated or unauthenticated users.

Do you test REST and GraphQL APIs?

Yes. Reviews can cover REST endpoints, GraphQL queries and mutations, resolver behavior, token scopes, object-level access, and excessive data exposure.

How is API testing different from normal penetration testing?

API testing focuses deeply on request-level trust boundaries, authorization checks, object ownership, tenant isolation, and machine-readable workflows that scanners often miss.

What API vulnerabilities do you usually find?

Common findings include IDOR/BOLA, broken object authorization, token scope failures, GraphQL enumeration, excessive data exposure, and business logic abuse.

What deliverables are provided?

You receive validated findings with affected endpoints, role context, reproduction steps, impact analysis, fix guidance, and retest criteria.

Next Step

Review the trust boundaries attackers test first

Validate authorization, tenant isolation, object access and the API paths that could expose customer data.

AuthorizationTenant IsolationObject Access