What UAE regulators expect from an API pentest: open finance, supplier links and the evidence

The rule reaches the data and the connection, never the screen

No UAE instrument names an API, any more than one names a web application. The four regimes that ask for security testing are written about systems that hold classified information and about the connections that carry it to somebody else, and an API is both of those things at once. The UAE rules that ask for a web application pentest sets out which regime binds which sector. This article is about what changes when the asset under the rule has no screen. An API is called by other software, so nothing a person sees in a browser limits what it will answer, and the obligation to test it attaches to the data it returns rather than to the front end that usually asks.

That distinction decides scope. A bank's mobile application, its partner portal and the third-party apps onboarded under open finance can all sit on one set of endpoints, and the examiner's interest is in the endpoints. A Dubai government entity's supplier connection is an API. A hospital's integration with a health information exchange is an API. An API pentest is the test that treats those endpoints as the asset, calls each one directly with each role's token, and records what came back. The table sets out where each regime's language lands when the system in question is an interface rather than a page.

Open finance makes the API the regulated surface

For an institution licensed by CBUAE, the API has moved from an implementation detail to the thing the framework is about. Under the Central Bank's open finance framework a licensed third party, with the customer's consent, calls the institution's endpoints to read account data and to initiate payments. The consent has a scope, the token issued against it has a lifetime, and every endpoint is expected to enforce both. A testing obligation written for systems in general lands, for these institutions, on a specific set of endpoints whose expected behaviour the framework describes, and an examiner can hold what the test found against it.

The finding that matters here is authorisation at the object level, and open finance gives it a precise form. A token is valid, the consent it was issued against is real, and the endpoint still returns an account that consent never covered. The chain below is the general shape. Nothing in it is exotic and none of it appears on a scanner, because every response is a well-formed success. A test that evidences this side of the framework is the technical half: consent enforcement, scope handling and authorisation per endpoint. It is not the certification process, and a proposal that presents it as one should be read again.

Read the instrument in force for what it asks of testing and how often. Article numbers are not quoted here, because the wording changes between versions and an examiner holds the institution to the text rather than to a paraphrase in a proposal.

Supplier connections and exchange integrations are APIs

The DESC Information Security Regulation reaches Dubai government entities directly and their suppliers by contract, and it asks that testing be proportionate to the classification of the information handled. The supplier connection is explicitly within that. In current designs the connection is an API: the supplier's platform calls the entity's service, or the entity's system calls the supplier's, and a classified record crosses in a response body. The classification of the highest field any endpoint returns is what sets the level the test has to reach, and a supplier who scopes the test to its own public website has tested the wrong asset.

In Abu Dhabi, ADHICS holds healthcare entities and the vendors inside their environments to the same shape. A patient portal, the mobile application that speaks to it, and the integration with a health information exchange all terminate in endpoints that return clinical records, and an authorisation flaw in any of them is reached through an identifier rather than a screen. Federal entities and critical infrastructure under the UAE Information Assurance Regulation carry service interfaces between government systems the same way. In each case the obligation is inherited by whoever holds the connection, and the party at the far end of it is the one who asks for the report.

One consequence for scoping: the mobile client and the API behind it are two assets under one obligation. A mobile app pentest tests the client and what it stores. The endpoints are tested as endpoints, with every role's token and every object-owning call, because the client's own restraint is not a control an examiner will accept.

The evidence pack for an API starts with an inventory

For a web application the scope line names a hostname and a release. For an API it names a list of endpoints, and the first thing an examiner reads is where that list came from. A specification is a claim about what the API does; traffic is a record of what it accepts. The scope statement gives both and says how they were reconciled, because an endpoint that is in traffic and not in the specification was never reviewed by anyone, and that is where an authorisation check goes missing. Written generically, as an example, the lines look like this. Scope: api.example.ae, version 3, 64 endpoints in the published specification plus 7 observed in traffic and undocumented, all in scope. Roles held: anonymous, customer, partner under client credentials, operations administrator. Method: OWASP API Security Top 10 with the WSTG, authenticated, source code not provided.

Below the scope line the pack is the same stack as any penetration test report, with one layer an API test adds: the per-endpoint authorisation record. It is a grid of endpoints against roles, each cell recording what the endpoint returned when called with that role's token for an object the role does not own. An examiner can read that grid without a tester in the room, and a finding sits on it as a marked cell rather than as an assertion. The OWASP API Security Top 10 is the list proposals cite for the method. Cite the edition, because the categories changed between the 2019 and 2023 lists and a control mapping written against one does not read cleanly against the other.

The finding that is also a disclosure

An object level authorisation finding on an API that returns personal records is, at the moment it is proved, an access to personal data the data subject never authorised. Federal Decree-Law 45 of 2021 applies to controllers of personal data across the UAE, with sectoral exclusions, and the financial free zones carry their own regimes. None of that turns a test finding into a breach, because the access was authorised by the engagement, but it does decide how the finding is evidenced. The proof is the request, the token, and the identifier of the record reached. The record itself is counted, not copied, and the report carries the count.

Cardholder data raises the bar the same way. An endpoint in a cardholder data environment is tested at the intervals that standard sets and after significant change, and a new partner onboarded onto an existing API is a significant change to what the API is exposed to, even when no line of code moved. What a finding has to show, and why a role-by-role method is the only one that produces it, is set out in how authorisation is tested role by role. The API version of that method holds a token per role and a record per endpoint instead of a page per role.

Two things close the file. The retest, run with the same request that produced the finding, and the decision record for any finding the institution chose to accept, with the name of whoever accepted it. Both go in the pack. An accepted authorisation flaw on a personal-data endpoint is a decision an examiner will ask about, and the pack is the only place the answer survives.

Open finance in Dubai, health exchanges in Abu Dhabi, and who inherits the rule

In Dubai the two regimes that reach an API most directly are CBUAE's, through the banks and payment institutions licensed there, and DESC's, through the government entities whose suppliers integrate with them. A free-zone software supplier with no regulator of its own inherits DESC's expectation the moment its API carries a Dubai government entity's classified data, and the contract that creates the connection generally asks for a current test report covering it. Entities inside the DIFC carry the Centre's own data protection law alongside whatever their sector regulator asks, so a personal-data endpoint there answers to two instruments at once.

In Abu Dhabi the picture is set by ADHICS for healthcare and by the federal instruments for government. A vendor whose platform connects to a hospital's systems or to the emirate's health information exchange is tested to the clinical data its endpoints return, and the ADGM's data protection regulations add the same second layer for firms inside it. Across the United Arab Emirates the rule is consistent: the obligation follows the data, the connection is in scope, and the party who holds the connection is the one asked for evidence. Deciding which endpoints, roles and partners go into that scope is the work described in how to scope a penetration test, and for an API it starts from the inventory rather than from a URL.

Frequently asked questions