For endpoints other systems already depend on
API Security
An API gets attacked differently from the application behind it, because the attacker never sees your code, only the contract you exposed. Broken object-level authorization, leaked tokens and unbounded rate limits top most API breach reports, and a general code scan catches none of them. This practice tests that exact boundary, whether the API is going public, already carries production traffic, or is about to hand a partner credentials.
How an API gets tested against the OWASP Top 10
Authentication, object-level access and the report a development team can act on.
90 secSample frame · video pending01Before choosing an authentication model
API keys or OAuth is a real engineering decision.
Both get chosen too casually, often by copying whatever the last project used. Four questions settle it against who is actually calling your API.
Are your callers other services or human users?
API keys suit service-to-service traffic well. OAuth earns its added complexity once a human needs to grant delegated access on their own behalf.
Does access need to expire or be revoked per user?
A static API key is awkward to revoke selectively. OAuth's token expiry and scoping handle fine-grained revocation far more naturally.
How many distinct permission levels does the API need?
A single all-or-nothing key is simpler to issue and audit. Multiple scopes across many callers is exactly what OAuth scoping was built to express.
What can your team actually operate under pressure?
A correctly implemented API key beats a poorly implemented OAuth flow every time an incident happens at an inconvenient hour.
| API keys | OAuth 2.0 | |
|---|---|---|
| Best caller type | Service-to-service | Human-delegated access |
| Revocation granularity | Coarse, per key | Fine, per token and scope |
| Implementation effort | Low | Higher, but standardised |
| Best fit | Internal or trusted integrations | Public or multi-tenant APIs |
02Agreed before testing begins
The ledger that keeps API testing honest
API testing drifts when the line between the endpoint and the system behind it is assumed rather than written down. Here it gets written down instead: what you supply, what gets tested, what comes back afterward, and what never leaves your side of the line.
- Your side
You bring
- The API's current endpoints and authentication method
- Any existing consumers or partners already calling it
- Rate limits or thresholds already agreed with stakeholders
- Our side
We build
- A structured test against the OWASP API Top 10
- Findings on broken authentication and object-level access
- A remediation list ranked by exploitability and impact
- Your side
You receive
- A written report naming every vulnerability found
- Proof-of-concept detail for anything rated high or critical
- A retest confirming each fix actually closed the gap
Never leaves you
- The API's source code and hosting infrastructure
- The decision on which fixes ship before launch
- The relationship with any partner consuming the API
Where the line sitsWe test the boundary; you own everything behind it. A finding here describes an exposure, not a request for code access we do not need.
03From endpoint map to retest
Four stages, each closing on evidence
APIs that get breached usually skipped a stage somewhere in this sequence. This system closes each one with something a development team can act on directly.
Map the endpoint surface
Every documented and undocumented endpoint gets catalogued first, because an endpoint nobody remembers is exactly where an object-level access flaw hides.
Every route the API actually exposesAttempt exploitation directly
Authentication bypass, broken object-level authorization and rate limit evasion get tried against the mapped surface, the way a real attacker would sequence it.
Against the OWASP API Top 10, not a generic checklistDocument with proof-of-concept detail
Each finding ships with enough reproduction detail that an engineer can confirm it independently, rather than taking a severity rating on faith.
Proof, not a severity guessRetest before closing the engagement
Every high or critical finding gets a retest once a fix ships, so the report closes on confirmation rather than an assumption.
Confirmation the fix actually worked
04What actually moves the number
Four drivers, priced from the endpoint map
API security work is priced against a short scoping call, because these four factors change effort by multiples of the base estimate.
Number of endpoints in scope
A handful of internal endpoints tests faster than a public API surface spanning dozens of resources and versions.
Authentication and authorization complexity
A single API key is quicker to assess than a multi-tenant OAuth flow with several scopes and delegated permissions.
Access level granted for testing
Black-box testing against a live API with no internal visibility takes longer than a grey-box test with documentation provided upfront.
Depth of retest required
A quick confirmation on a handful of fixes costs less than a full retest across every finding after a larger remediation pass.
05Evidence and proof
Endpoints tested the way an attacker actually calls them.
API security proof is a finding with proof-of-concept detail and a retest that confirms the fix held. Every record here waits for written client approval before production.
Explore case studiesA logistics API cleared for partner traffic after a scoped test.
Tern needed a carrier-facing API tested before three new logistics partners connected to it. A structured OWASP API Top 10 test found and closed two object-level authorization flaws before launch.
- Authorization flaws found and closed
- 2
- Partner integrations launched on schedule
- 3
An industrial API's rate limits verified before a device rollout.
Nexa Foundry's equipment-monitoring API had no verified rate limiting ahead of a large device fleet rollout. Testing confirmed the limits held under realistic burst traffic before deployment.
- Rate limit bypass attempts succeeded
- Zero
- Devices connected at rollout
- Over 4,000
They found the token replay issue our own load testing had completely missed.
Sample · pending client approval
06Read this first
When API security testing is the wrong first move
Scoping a contract-layer test when the real question is about the whole codebase or the cloud it runs on wastes the engagement's focus. The exits are marked plainly below.
- Application Security
The concern spans the whole application, not just its API
Source code, business logic and the frontend all need coverage, which calls for the broader lifecycle discipline instead.
- Application Security
You need an ongoing practice, not a single test
A one-time API test does not catch what a new release introduces next quarter. An SDLC-integrated practice does.
- Cloud Security
The exposure is really about cloud configuration
Exposed storage or an over-permissioned IAM role sitting behind the API is a cloud security question, not an endpoint one.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped test | One API, a defined launch date | Which findings ship before go-live | Testing, report and retest |
| Recurring test | The API changes every release cycle | Release cadence and priorities | Testing scheduled against each release |
| Retainer | Multiple APIs across several teams | Which API gets tested next | Standing capacity across the estate |
07Straight answers
Asked before an API takes real traffic.
01What is the OWASP API Top 10?
A list of the most common API vulnerability categories, from broken object-level authorization to security misconfiguration. Testing here is structured directly against it, so every engagement covers the same recognised ground.
02Do you test GraphQL APIs as well as REST?
Yes, though the technique differs. GraphQL introduces its own risks around query depth and introspection that a REST-focused test would miss entirely.
03Do you need access to our source code?
Not necessarily. Black-box testing works from the outside with no code access, while a grey-box test with limited documentation usually finds deeper issues faster.
04How is this different from a full penetration test?
This stays scoped to the API contract layer specifically. A full penetration test can include the API but usually spans a wider set of systems and attack paths.
05Can you test an API that's still in staging?
Yes, and testing before public launch is usually the more valuable timing. A staging environment that mirrors production closely enough gives realistic results.
06What happens after you find a vulnerability?
Every finding ships with severity, reproduction steps and a fix recommendation your engineers can act on immediately. A retest then confirms the fix actually closed the gap.
07How long does an API security engagement take?
A single API with a defined scope typically closes in two to three weeks. A larger surface with many endpoints or a deeper grey-box review runs longer.
08What does API security testing cost?
Pricing follows endpoint count, authentication complexity and the access level granted for testing, set during a short scoping call. A recurring test priced per release usually costs less per cycle than repeated one-off engagements.