Strategy & Governance

Managed Security

Cyber Defense

Governance, Risk & Compliance

Operations & People

Talk to us

Cyber Defense

API security assessment for the endpoints nobody documented.

API security assessment services matter because your API has no interface to hide behind. There is no front end quietly enforcing which button a user may press. There is a URL, a token, and whatever your code decides to return. Most serious API findings are one missing check away from every customer record.

We enumerate the real surface, not the documented one: the endpoints in your specification, the ones your mobile and web clients call, the versions you deprecated but never switched off, and the internal service routes that ended up reachable. Then we test each of them as every role you have, and as no role at all.

The assessment follows the OWASP API Security Top 10 as a floor rather than a ceiling: broken object-level authorisation, broken function-level authorisation, excessive data exposure and unrestricted resource consumption are where the real findings cluster. Where the API serves an app, pair this with mobile app security testing; where it fronts cloud infrastructure, with cloud security testing.

Why you need it

01 / 06

Why APIs fail differently.

01

Object-level authorisation is checked per request, or not at all.

Every endpoint that takes an identifier has to independently verify that this caller may touch that object. One handler that forgets is enough. This is the single most common critical API finding, and it is invisible to any tool that does not know which records belong to whom.

02

The API returns more than the client shows.

Front ends filter for display; APIs frequently serialise the whole object. Password hashes, internal flags, other users' email addresses and full audit trails arrive in a response that renders as one harmless line in the interface.

03

Old versions never actually retire.

v1 is deprecated in the documentation and still routed in production, without the authorisation logic that was added in v2. Shadow and zombie endpoints are found by enumeration, not by reading the specification.

04

Machine clients make abuse cheap.

Without per-endpoint rate limiting and resource controls, an API is a data-extraction service. Enumeration of identifiers, credential stuffing and expensive GraphQL queries all scale in a way that no human interface allows.

Instrument

02 / 06

One endpoint, scanned and tested.

What the automated pass reports about an API, and what a tester confirms once two accounts are in play.

What we deliver

03 / 06

What the assessment covers.

01

Surface enumeration

Specification review where an OpenAPI, GraphQL schema or gRPC definition exists, plus discovery of what actually answers: undocumented routes, retired versions still live, debug and administrative endpoints, and the calls we recover from your own clients and JavaScript bundles.

02

Authentication and token handling

Credential and token flows end to end: OAuth 2.0 and OpenID Connect implementation, JWT signature validation and algorithm confusion, token lifetime and revocation, refresh handling, API key scoping, and whether an expired or forged token is actually rejected.

03

Object and function-level authorisation

The core of the engagement. Each endpoint is called as each role and as each of two peer accounts, with identifiers swapped, to establish whether the server enforces ownership and privilege on every path, including nested resources and bulk operations.

04

Data exposure and mass assignment

What each response actually contains versus what the consumer needs, and what each request body is allowed to set. Fields like role, tenant, isAdmin and balance that bind automatically from JSON are tested for direct assignment.

05

Input handling and injection

SQL and NoSQL injection, command injection, server-side request forgery through URL parameters, XML external entities, deserialisation, and GraphQL-specific abuse including introspection, batching and deeply nested queries.

06

Rate limiting and resource consumption

Per-endpoint and per-account limits, whether they can be evaded by rotating headers or credentials, pagination limits, file upload constraints, and the query that makes your database do a hundred times the work of a normal request.

How we run it

04 / 06

Five phases against the live surface.

  1. 01

    Scoping and access

    Environments, specification files where they exist, and at minimum two accounts per role so that cross-account authorisation can be tested at all. Rules of engagement, testing windows and an escalation contact are agreed in writing.

    Week 0
  2. 02

    Discovery and mapping

    The full reachable surface: specification-driven for what is documented, and traffic capture, client analysis and fuzzing for what is not. The map we produce is frequently the first complete inventory the client has had.

    Days 1-2
  3. 03

    Automated pass

    Schema-driven and template-driven checks with Nuclei and Burp Suite scanning to establish breadth. Useful for coverage; not the finding set.

    Day 2
  4. 04

    Manual testing

    Authorisation matrices executed request by request across accounts and roles, token manipulation, mass-assignment and data-exposure review, injection, and resource-consumption abuse. Confirmed findings are chained to establish what the combination reaches.

    Days 3-7
  5. 05

    Reporting, walkthrough and re-test

    A report with the request and response for every finding, ranked by data reached, delivered in a working session with the engineers who own the endpoints. Re-test and closure once fixes ship.

    Days 8-10, then on your schedule

Key benefits

05 / 06

What changes after.

You have a real endpoint inventory

Including the versions and routes that were not in the specification. Several clients have switched off more surface than they patched.

Authorisation is enforced server-side, per object

The class of bug that leaks every customer record is tested per endpoint, per role, per account, and once fixed, re-tested the same way.

Partners get a straight answer

A dated assessment against the OWASP API Security Top 10, with verified remediation, satisfies the API section of enterprise due diligence without further negotiation.

Tools we use

06 / 06

Named, and used on your engagement.

No “latest tech tools”. These are the ones your report will cite, alongside the manual work that a tool cannot do for you.

Interception and testing

  • Burp Suite Professional
  • OWASP ZAP
  • Postman
  • mitmproxy

Discovery and fuzzing

  • ffuf
  • Kiterunner
  • Nuclei
  • Arjun

Protocol-specific

  • GraphQL Voyager
  • InQL
  • grpcurl
  • jwt_tool

Code and schema

  • Semgrep
  • Spectral
  • Trivy

Methodology

  • OWASP API Security Top 10
  • OWASP ASVS
  • PTES

Why Aphelion

Shared

Four things you can check.

01

The work is done by people with names.

Darshap Nayak, formerly of KPMG, holds a master’s degree in cybersecurity and more than seven years in security operations. Jaimin Somani brings fifteen-plus years of academic and hands-on VAPT. Hemang Desai is an ICT network specialist from Australia. You will meet them, not a logo.

Meet the team
02

Evidence, not adjectives.

Every finding arrives with the reproduction steps, the affected asset and the fix, ranked by what it actually reaches in your environment, not by a CVSS number copied from a scanner. You get the report and the raw output, not a summary of a summary.

See how we test
03

Two offices, one practice.

Ahmedabad and Sharjah, working the same methodology on the same tooling. Indian data-residency requirements and UAE delivery are both ordinary here, and the AphelioNYX AD Pen-Test module runs entirely inside your perimeter when regulation says it must.

The platform
04

What we will not do.

Invent a statistic to make a slide land. Publish your name as a client without written permission. Print an award badge nobody awarded. Founded in 2024. We say so, and we attribute experience to the people who have it.

Ask us anything

100+ organizations secured

Across the globe, and across eight industries. We name a client only with their written permission.

  • Finance & Banking
  • Healthcare
  • Retail & E-commerce
  • Technology
  • SaaS
  • Hospitality
  • Manufacturing
  • Pharmaceuticals

AphelioNYX is SOC 2, ISO and GDPR compliant; attestations are available on request under NDA. We would rather hand you the report than print a badge.

Questions

FAQ

What clients ask before an API test.

Can you test without an OpenAPI specification?
Yes. A specification makes coverage faster and lets us prove we reached everything, so share one if you have it. Without it we build the map from traffic capture, client-side analysis and route fuzzing, which has the side benefit of finding endpoints the specification would have omitted anyway.
How many accounts do you need?
At least two per role, and where the product is multi-tenant, two tenants. Broken object-level authorisation can only be demonstrated by attempting to read account A's data with account B's token. With a single account we can test injection and configuration but not the finding class that matters most.
Do you test GraphQL and gRPC as well as REST?
Yes. GraphQL brings its own surface: introspection exposure, query batching for credential stuffing, deeply nested queries as a resource attack, and field-level authorisation that has to be enforced per resolver. gRPC needs the proto definitions or reflection enabled; we work from either.
Will testing generate load or corrupt data?
Rate-limit testing generates deliberate load, which is why it runs in an agreed window with a named contact. Write operations are performed with test accounts on test records wherever the environment allows. Where we must write in production, the objects created are tagged and listed in the report so your team can remove them.
How often should an API be assessed?
Annually as a baseline, and after any change to the authentication model, the authorisation logic or the data model. Continuous integration checks (schema linting, dependency scanning, automated authorisation tests) should carry the load between assessments; a full manual test is for the logic those checks cannot express.

Forty-five minutes. Your environment, not a slide deck.

A personalised walkthrough and a free readiness assessment against the frameworks you are actually being asked for. Pick a time that suits you, or write to us. We reply within one business day.