Testing an API you do not operate: who authorises it, and what UAE rules still ask of you

Outsourcing moves the API, not the obligation

The four UAE regimes that ask for security testing attach the obligation to the entity that holds the licence or the data, and none of them lets go of it when the system belongs to somebody else. A bank licensed by CBUAE that runs its account endpoints on a vendor's platform is still the party the examiner asks, and the Central Bank's rules on outsourcing keep responsibility for an outsourced activity with the institution. DESC reaches a supplier by contract, ADHICS reaches the vendors inside a hospital's environment, and the federal Information Assurance Regulation treats third-party security as a control family of its own. What UAE regulators expect from an API pentest set out which regime reaches which API. This article is about the case all four now meet: the API the rule reaches is not one the entity runs.

That case is the ordinary one. Between a caller and a record there are commonly five layers, with five operators. A third party's application makes the call. A gateway terminates it, a managed cloud service that the entity configures and the provider runs. An identity provider issues the token, often a vendor's hosted product. The service that makes the authorisation decision is a vendor's software, sometimes a shared platform serving other customers. The data store behind it is the vendor's, and in a multi-tenant design it holds other tenants' records in the same tables. The stack below is that path. Each layer needs a different answer to who may authorise a test against it, and the obligation to produce the evidence sits with the one party who operates almost none of it.

Who can authorise the test at each layer

Accessing an information system without authorisation is an offence under Federal Decree-Law No. 34 of 2021 on Countering Rumours and Cybercrimes, and authorisation can only be given by a party entitled to give it. Authorising a Red Team under UAE law set out that principle for an engagement against your own estate: you can authorise access to what is yours, and nobody can authorise access to what is not. An API test meets the principle in a sharper form, because the estate is layered and the layers are other people's. The entity's letter covers its own configuration, its own tenant and its own data. It does not cover the provider's machines, the vendor's platform beyond the tenant boundary, or a partner's endpoint.

The table sets out where the authority comes from at each layer and what the pack can say as a result. Two rows carry most of the weight. The large cloud providers publish testing policies for their managed services, and for most of them a customer may test its own resources without notice, with named exclusions such as denial of service. That policy is the authorisation for the gateway, and the letter should cite it by name and date. A multi-tenant vendor is the opposite case: its written consent is needed before the first request, and the next section is about what it consents to. The UAE Information Assurance Regulation carries third-party security as a control family, and the contract that created each of these relationships is where a right to test should already have been written. Where it was not, the consent is asked for now and the clause is added at renewal.

The multi-tenant vendor, and the test it least wants to allow

A vendor that serves several regulated entities from one platform is asked for consent by each of them, and the answer it prefers is its own report. That report is evidence and belongs in the pack. It is not the same evidence as a test the entity commissioned, for two reasons. The vendor scoped it, so what it left out is invisible to the reader. And it describes the platform in general, when the examiner's question is about this entity's tenant, this entity's roles and this entity's data. An API pentest commissioned against the entity's own tenant answers that question directly, and the vendor's consent should extend to it.

The finding that makes the negotiation difficult is the one the OWASP API Security Top 10 ranks first. On a shared platform an object level authorisation flaw is a tenant boundary flaw: a record from one customer reached with a token issued to another. Testing for it means the tester's requests carry identifiers that do not belong to the entity's tenant, and the vendor will say, correctly, that nobody can authorise access to another customer's data. The working answer is a second tenant. The vendor provisions a test tenant that belongs to nobody, seeded with generated records, and the boundary is tested between the entity's tenant and that one. Where the vendor refuses even that, the refusal is recorded in the pack with whatever compensating evidence the vendor offered, and the entity's risk owner signs the decision to proceed on it. An examiner would rather read that decision than discover the gap.

Downstream calls: the partner's live system your API calls for you

An API under test rarely stops at its own data store. A payment initiation endpoint calls a scheme or a correspondent. A hospital's integration calls the health information exchange. A government service calls a supplier's platform for the record it needs. One hop after the tester's request reaches the entity's endpoint, it has become the entity's request to a partner's live system, and no letter the entity holds authorises hostile traffic into that. The rules of engagement that NIST SP 800-115 describes are where this is settled, and for an API the settlement is per endpoint. Which downstream calls run live, which are pointed at the partner's sandbox for the duration, and which endpoints are excluded because neither is possible.

Two consequences follow. A sandbox does not behave like the live partner, so an endpoint tested against one has been tested for its own authorisation and input handling and not for how it treats what comes back. The 2023 edition of the OWASP API list closes with unsafe consumption of APIs for that reason, and the pack should say which endpoints were tested for it and which were not. And the join of logs across layers, described in where an API pentest should be seen, now crosses organisations. The partner's record of what arrived is evidence the entity cannot read, and a line in the letter asking the partner to preserve and share it for the window costs less than asking afterwards.

Before day one: name, ask, record

The pre-engagement work is the sequence in the figure, and each phase leaves a document the examiner will read. Name: the endpoint inventory, built the way how an API pentest builds its endpoint inventory describes, gains a column for the operator of each layer the endpoint crosses and another for where its downstream calls go. Ask: the entity's own letter for what it runs, the provider policy cited for the gateway, written consent from each vendor with the tenant boundary named, and a sandbox, a consent or an exclusion for each partner. Record: what was tested live, what was tested against a sandbox or a test tenant, and every refusal, with the decision taken on it and the name of the person who took it.

One more line belongs in the ask. Personal records reached during the test are personal data under Federal Decree-Law No. 45 of 2021, which distinguishes the controller from the processor, and the UAE government's summary of its data protection laws notes that the financial free zones carry their own. A tester who reaches those records on the entity's instruction is processing them on its behalf, and the engagement contract is where that is written down. Records are counted and not copied. Generated data is used wherever a test tenant allows it, and the vendor whose platform holds the records is told that the entity gave the instruction. None of this is new law for an API. It is the same law meeting an asset with five operators, and the pack is where the five answers are kept together.

Five operators, two emirates: who is asked in Dubai and Abu Dhabi

In Dubai this arrangement is the normal shape of a regulated estate. A bank or payment institution licensed by the Central Bank runs on hosted platforms, fronts them with a managed gateway and, under open finance, answers calls from licensed third parties it does not control. The examiner asks the institution, whose pack has to show consent from each operator and a result for each layer. A supplier to a Dubai government entity under DESC stands on the other side of the same relationship: it is the vendor being asked for consent, and the right-to-test clause it agreed at tender is what it is now held to. Firms inside the DIFC add the Centre's own data protection law to the contract that governs the tester's processing.

In Abu Dhabi the vendor inside a hospital's environment is held to ADHICS through the entity it serves, and the integration with the emirate's health information exchange is the downstream partner whose sandbox and consent have to be arranged before the test. The ADGM's data protection regulations add the same second layer for firms inside it. Across the United Arab Emirates the practical difference between the emirates shows up in procurement. Did the tender for a platform or an integration ask for a right to test, a right to the vendor's own report, and a duty to provide a test tenant? Where a mobile app pentest is bought alongside the API test, the same consents cover both, because the client sends its traffic through the same five layers. Ask for the clauses at the next renewal. They cost far less to write into a contract than to negotiate the week before a test.

Frequently asked questions