- Home
- Architecture & Hardening
- API security
Your APIs answer anyone who asks,
so test who they answer.
Manual testing of REST, GraphQL and gRPC APIs against the OWASP API Security Top 10: broken authorization, weak authentication, excessive data exposure and the business-logic abuse scanners cannot see.
The flaws that matter are about who, not what.
Modern applications are mostly APIs: the mobile app, the single-page front end, the partner integration and the internal microservices all talk through them. The most damaging API flaws are not injection bugs. They are authorization failures: a user who can read another customer's records by changing an ID, a regular account that can call an admin function, a field that should never have been writable.
Automated scanners rarely find these, because the request looks valid. Finding them takes a tester who understands what each endpoint is supposed to allow, and then tries everything it should not. We test with real accounts at different privilege levels, review your schema and documentation, and work through the workflows that matter to your business.
- Testing of every in-scope endpoint against the OWASP API Security Top 10
- Object-level and function-level authorization tested across user roles and tenants
- Authentication, token and session review, including JWT handling
- Schema and documentation review: undocumented endpoints, mass assignment, excessive data exposure
- Business-logic and workflow abuse scenarios specific to your application
- Findings with proof of exploit, business impact and a concrete fix, plus a re-test
Four steps, scope to re-test.
Scope and map
We collect your OpenAPI or GraphQL schema, documentation and test accounts at each privilege level, then map every endpoint and the data it touches.
Test authorization and authentication
Every endpoint is tested as every role: can one user reach another's data, can a standard account call admin functions, do tokens expire and validate as they should.
Abuse the logic
We test the workflows: skipping steps, replaying requests, racing concurrent operations, changing quantities and states, breaking tenant isolation.
Report and re-test
Findings are briefed to your developers with proof and a fix. Once fixes are in, we re-test and close them.
What we test.
Authorization
Broken object-level, property-level and function-level authorization, tenant isolation, privilege escalation.
Authentication
Login flows, token issuance and validation, session handling, password reset and account recovery.
Schema and inventory
Undocumented and deprecated endpoints, mass assignment, excessive data in responses, input validation.
Resource abuse
Rate limiting, enumeration, scraping and requests designed to exhaust resources.
Business logic
Workflow bypass, state manipulation, race conditions in payment, inventory and account operations.
API styles
REST, GraphQL (introspection, query depth, batching, field-level access), gRPC and WebSocket APIs.
Who it is for
Organizations whose product or customers depend on APIs: SaaS platforms, mobile-first services, financial and payment applications, and anyone exposing APIs to partners. Also teams preparing for a customer security review that will ask how the API was tested.
- Application security, code and design review behind the API
- Penetration testing, test the wider environment, Ragnarök
- DevSecOps, catch API flaws in the pipeline
- Cloud security, the platform your APIs run on
What buyers ask.
Our API gateway handles security.
A gateway handles authentication, rate limits and routing. It cannot know whether user A should see record B. Authorization lives in your application code, and that is where most serious API flaws are.
We already had a penetration test.
General penetration tests often cover APIs lightly. This test goes endpoint by endpoint, role by role, which is what finding authorization flaws requires.
Do you need our source code?
No, though it helps. We can test from the schema, documentation and test accounts. If you share code, we can review the authorization logic directly and find issues faster.
Will testing affect production?
We prefer a staging environment that mirrors production. If testing must run against production, we agree limits on volume and destructive actions before we start.
Find out who your API answers.
Put an engineer on a call to scope an API security test. No charge, no commitment.

