Data behind every request
Every API request carries an identifier or an access token, and any gap in checking them can let one user read or change another user's data.
Our services · API penetration testing
API Penetration Testing in Saudi Arabia
We test the REST and GraphQL APIs your applications and partners depend on by hand, the way a real attacker would. Every finding we approve is verified and reproduced step by step before delivery.
- Pay only when a Critical or High finding is confirmed
- Manual testing by Saudi researchers ranked top 10 on bugbounty.sa
- Free retests until the finding truly closes
01 · Why it matters
Why your APIs need a penetration test
APIs are the direct route to your data and your systems' functions, and your web apps, mobile apps and partner integrations all depend on them. A single authorization flaw can expose every customer's data without ever showing in the user interface.
They grow faster than their docs
New endpoints and versions are added all the time, and old or undocumented versions sometimes stay exposed to the internet without anyone noticing.
Regulatory requirements
We document the penetration test report in line with the NCA Essential Cybersecurity Controls (ECC) and the SAMA Cyber Security Framework (CSF), to help you evidence that penetration-testing requirements are met.
What tools don't find
Authorization flaws between users and roles, and business-logic flaws in the order of requests, are not caught by automated scans; a human tester who understands how your API is used finds them.
02 · Scope
01
02
03
04
05
06
07
08
09
10
What API penetration testing covers
We cover the OWASP API Security Top 10 categories and beyond, with checks on every endpoint and every role, for REST and GraphQL APIs, including mobile backends and partner APIs.
Object-level authorization (BOLA / IDOR)
We verify that every request returns only its owner's data, testing whether another user's orders, invoices or files can be reached by changing the identifier in the path, parameters or request body.
Authentication and tokens
We review how JWTs are issued and how their signature and expiry are checked, OAuth flows, and how API keys are protected, looking for tokens that stay valid after logout or a password change, or that work outside the purpose they were issued for.
Function-level authorization (BFLA)
We test whether a regular user can call administrative endpoints or functions meant for a higher role, such as deleting users, changing settings or exporting data.
Mass assignment and excessive data exposure
We check that the API does not accept changes to protected fields sent in a request, such as role, balance or account status (mass assignment), and does not return sensitive fields the calling application never needs.
Rate limits and resource consumption
We review limits on request rate, size and page size, looking for paths that allow guessing tokens or passwords or consuming server resources without bound, always within the limits agreed in the rules of engagement.
Injection and SSRF
We test parameters that reach the database or backend systems for injection flaws, including data the API receives from third-party APIs it consumes, and fields that accept URLs, such as webhooks and file imports, to make sure the server cannot be made to request internal resources (SSRF).
Security configuration and information leaks
We review CORS settings, allowed HTTP methods, error messages that reveal technical internals, security headers, and documentation or debug endpoints exposed by mistake.
GraphQL-specific testing
We test schema exposure through introspection, authorization on every field and every operation (queries and mutations), and deeply nested queries and batched requests that can bypass usage limits.
API inventory and versions
Within the agreed scope, we look for old versions, undocumented endpoints and test environments that are still running, as they are often less protected than the current version.
Business logic across requests
We test the order of operations in the API, such as purchases, transfers and refunds, looking for skipped mandatory steps, repeated operations and race conditions when requests are sent at the same time.
03 · Our methodology
How we run an API penetration test
Reliant is a Saudi penetration-testing-as-a-service (PTaaS) platform based in Riyadh and licensed by the National Cybersecurity Authority. The researcher starts by understanding your API: its endpoints, its roles, and the data each user owns. They then test it by hand with a real attacker's mindset, guided by the OWASP API Security Top 10, the OWASP Top 10 and PTES, and chain small flaws into exploitation paths that show their real business impact. We document the report in line with NCA ECC and SAMA CSF, and every finding is reviewed, verified and reproduced before delivery.
OWASP API Security Top 10OWASP Top 10PTESNCA ECCSAMA CSF
04 · How it works
API penetration testing, from first contact to retest
- 01
Share your requirements
Share your requirements or book a 30-minute consultation with a lead penetration tester to define the target APIs, their versions and their user roles.
- 02
Create the program
Your company creates a program on the platform that sets in-scope and out-of-scope assets, rules of engagement (testing windows, forbidden techniques such as DoS, rate limits, escalation channels), and a suggested budget.
- 03
Review and access
Reliant reviews the scope and agrees the budget with you, and you prepare the API documentation, if any, and test accounts for each role. The program runs under Reliant's standard Engagement Agreement or your own contract once we accept it, and an NDA is signed before any testing starts.
- 04
Testing and triage
The assigned researchers start testing and Reliant triages every submission. Any approved Critical or High finding can be sent to you immediately, ahead of the report.
- 05
Report and discussion
We deliver the report with every approved finding, you discuss each finding with us in the comments, and we may ask for your view on some of them through Company review.
- 06
Free retest
After fixing, you request a free retest while the program is in its report or retest stage, and the result reaches you as soon as the check is done.
05 · Deliverables
What you receive from an API penetration test
- A stable reference for every finding, in the RLT-000123 format
- A CVSS score for every finding
- A clear description of the finding and its business impact
- Step-by-step reproduction (proof of concept) with the supporting requests and responses
- Practical remediation guidance for every finding
- All results in the client dashboard, plus an auditable PDF report from the report stage or on request
- Free retests until the finding truly closes
06 · Pricing
No Critical or High finding, no fee
You pay only if Reliant confirms at least one Critical or High finding; the fee is then the program's agreed budget, one amount for the whole engagement, and the invoice is issued automatically with the report. The budget depends on scope size (how many APIs and endpoints), testing depth and timeline, and there is no minimum engagement: a single API on a small scope is priced the same way.
- No Critical or High finding confirmed? The invoice is zero, and the test and its report are delivered free.
- When one is confirmed: one amount, the agreed budget, with no per-finding charge and no hidden fees.
- Duplicate, invalid or out-of-scope reports are never billed.
07 · FAQ
All frequently asked questions
API penetration testing FAQ
What do you need from us to start an API penetration test?
We need the URL of the agreed environment, the API documentation if you have it (an OpenAPI/Swagger file, a Postman collection, or the GraphQL schema), and test accounts for each role, ideally at least two per role so we can test whether users can reach each other's data. If the API uses API keys or OAuth, we need credentials issued for the test.
Do you test GraphQL APIs?
Yes. We test GraphQL APIs as thoroughly as REST APIs and add GraphQL-specific checks: schema exposure through introspection, authorization on every field and operation, and deeply nested queries and batched requests that can bypass usage limits.
Can you test an API without documentation?
Yes. We map the endpoints from the applications that use the API and from the traffic they send in normal use, within the agreed scope. Documentation and test accounts make the test deeper and faster, though, because the researcher reaches every endpoint and every role directly.
Will testing affect our production APIs?
We agree the environment, testing windows, rate limits and immediate escalation channels in the rules of engagement beforehand, and we never run denial-of-service attacks. A staging environment that mirrors production is the best option when available; when we test production, we test like a real attacker without disrupting your services.
How long does an API penetration test take?
It depends on the number of APIs, endpoints and roles and on the testing depth. Most engagements are completed within 5 to 10 working days, and we agree the timeline when we set the scope.
How is an API penetration test priced?
The budget depends on scope size, testing depth and timeline, and you pay it only if we confirm at least one Critical or High finding. Then you pay one amount, the agreed budget, with no per-finding charge; otherwise the invoice is zero and the test and its report are delivered free.
Do you test a mobile app's backend APIs?
Yes. The APIs a mobile app uses are part of this service when they are in scope. If you also want the app itself tested on the device, mobile application penetration testing covers the app and its backend APIs together.
Test your APIs before an attacker finds their flaws
Share your requirements or book a 30-minute consultation with a lead penetration tester.
- info@reliant.sa
- +966 54 966 9661
- Riyadh, Saudi Arabia