Key takeaways
- Every UAE instrument that asks for security testing is written in control families, and four of them land directly on an API: access control, cryptography, availability and logging. An API pentest is how each is evidenced at the endpoint rather than at the portal in front of it.
- A token is three controls at once: who it was issued to, what it may call, and how long it lives. The test holds one token per role, partner integrations included, and records what every endpoint answered to a function that role should not reach.
- An unthrottled verification endpoint turns a strong-authentication control into a six-digit guess. Rate limiting is tested as an authentication control, not only as a continuity one.
- The logging control is proved by the test itself. If the failed authorisation calls and the brute-force run do not appear in the entity's own logs, the finding is the absence, and it belongs under the logging control.
- A proposal's control mapping should name the edition of the OWASP API list and the instrument in force by version, because the categories moved between editions and an examiner holds the entity to the text.
The instruments say access, key, limit and log, never API
The four UAE regimes that ask for security testing are control sets before they are testing mandates. The UAE Information Assurance Regulation is organised into control families. The DESC Information Security Regulation and ADHICS are built the same way, and CBUAE's standards for licensed institutions read as requirements on the same subjects. Four of those families are the ones an API exposes directly: access control, cryptography and key management, availability, and logging and monitoring. What UAE regulators expect from an API pentest set out which regime reaches which API and what an examiner reads afterwards. This article is about the controls inside them.
The distinction matters because a control satisfied at the portal is not a control satisfied at the endpoint. A web front end can enforce a session timeout, hide an administrative function and throttle a login form. The endpoint behind it can do none of those things, because it was written to be called by that front end and trusts it. An examiner reading a control mapping wants to know where each control is enforced. The table sets out all four.
| Control family | The question at the endpoint | What the test produces |
|---|---|---|
| Access control | Does each token reach only the objects and functions its role and scope cover | A per-endpoint record of what each role's token received, with expiry and revocation tested |
| Cryptography and key management | Are secrets, API keys and tokens issued, stored, transmitted and rotated as the instrument asks | Where each secret lives, how it travels, and whether a retired one still works |
| Availability and resource limits | Can one caller exhaust the service, or a verification step, without being slowed or stopped | The request rate reached on each endpoint before a limit answered |
| Logging and monitoring | Did the entity's own logs record the calls the test made, and did any raise an alert | The test timeline held against the entity's log and alert record |
A token is three controls, and the test checks each one
The access control family in each instrument asks for identification, authentication and authorisation, and for a lifetime on the session. On an API those land on one artefact. A bearer token says who the caller authenticated as, what scope the caller was granted, and when the grant ends. Every endpoint is expected to check all three on every call. An API pentest holds a token per role, including a client-credentials token for each partner integration, and calls every endpoint with every token. The record it produces has a column per token rather than per user, because a partner integration is a role.
The finding this produces most directly is at function level: a customer's token accepted by an endpoint written for operations staff, because the front end never shows the button and the endpoint never asked. The OWASP API Security Top 10 lists it as broken function level authorisation, separate from the object-level class, and a control mapping should keep the two apart. One is a missing ownership check and the other is a missing role check, and they are fixed in different places. Lifetime is the third control, and the easiest to hand to the identity provider and forget. The test records whether a token past its expiry still answers, whether a revoked one does, and whether a refresh issued to one client is accepted from another.
Written generically, as an example, one line of that record reads: endpoint, account limits update, version three; role, customer; expected, refused; received, success, and the limit on the named account changed. That line names the control, the endpoint it was missing from and what the gap let through, and an examiner can read it without a tester in the room.
Issue
Client authenticated
Which credential the token was issued against, and to whom
Scope bound to the grant
Consent or role written into the token, never assumed
Use
Scope checked per call
Every endpoint, not only the ones the front end shows
Function checked per role
An operations endpoint refuses a customer token
Object checked per owner
The identifier reached belongs to the caller
End
Expiry enforced
A token past its lifetime answers nothing
Revocation honoured
Consent withdrawn means the next call fails
Rate limits: a continuity control with an authentication consequence
The availability family is written about service continuity, and a rate limit reads as a continuity control: one caller should not be able to exhaust the service for everyone else. On an API it is also an authentication control, and that is the reading a test has to make. Where an instrument asks for strong authentication on customer or privileged access, and the second factor is a code sent to a phone, the endpoint that verifies the code is the control. An endpoint that accepts unlimited guesses at a six-digit code has no second factor, whatever the login screen shows.
The chain below is the general shape, and MITRE ATT&CK records the technique as brute force. Every request is well-formed and every response is a normal refusal until the one that is not. The test records the request rate reached on each endpoint before it slowed or locked, and whether a lock on one identifier could be avoided by rotating another. The same measurement applies to password reset, to voucher redemption and to any endpoint that answers a right guess differently from a wrong one. A mobile app pentest reaches the same endpoint from the client side, and it should get the same answer.
- Attacker → Login API
Starts a login for a customer's phone number
A number from a leak, a receipt or a guess
- Login API → Customer
Sends a six-digit code to the customer's phone
A message the customer never asked for
- Attacker → Login API
Submits guesses at the code, one request each
A million possibilities, scripted
- Login API
Vulnerability
Checks each guess and never counts them
No lock, no delay, no limit per number
- Login API → Attacker
Objective reached
Accepts the right guess and issues a session
The second factor existed and never held
Keys and secrets: where the cryptography family lands on an API
The cryptography family asks that data in transit be protected and that keys be managed: generated, stored, rotated and retired. On an API the question is where each secret lives. A partner integration with a Dubai government entity under DESC authenticates with an API key or a client secret, and the test asks four things of it. How was it issued. Where does the supplier store it. Does it travel anywhere except inside the TLS session. Does the previous one still work after rotation. A key that has never been rotated since the integration went live is a finding under the key management control before any endpoint is called.
For a clinical integration under ADHICS the same four questions apply to the exchange connection, with the classification of the records setting how seriously the answer is read. The test also records the transport itself. Which TLS versions and ciphers does the endpoint accept, does the mobile or partner client verify the certificate it is shown, and does any endpoint answer over plain HTTP at all. All of it is what an examiner means by the cryptography control when the asset is an interface. A penetration test report should carry it as a control section of its own, not as a footnote to the authorisation findings.
Logging: the control an API test proves by being seen
The logging and monitoring family asks that access be recorded and that anomalies be noticed. An API test is a week of anomalies delivered on a schedule, which makes it the cheapest evidence of that control the entity will get. At the end of the engagement the tester's timeline of calls is held against the entity's own log and alert record. Each failed authorisation call, each token used past its expiry and the whole brute-force run should be in the log, and some of them should have raised an alert. Where they are not, the finding is the absence, and it belongs under the logging control rather than as a note inside the authorisation finding.
This is the API version of the argument in what your monitoring should catch during a web app pentest. The difference is where the log is written. When a gateway does the logging it records what it was configured to record, and a default of path and status omits the identifier in the request that made the call an authorisation failure. A test that reaches another customer's record through a well-formed success leaves a line in that log which reads as normal traffic. An examiner asks whether the entity could have seen it, and a gateway that logs path and status alone cannot answer yes.
What the control mapping in a proposal should say
A proposal for an API test aimed at any of these regimes should map what it will test to the control families it evidences. Two details decide whether that mapping is worth anything. The first is the edition of the OWASP API list, because the categories changed between the 2019 and 2023 editions and a mapping written against one does not read cleanly against the other. The second is the instrument in force, by name and version, because an examiner holds the entity to the text and not to a proposal's paraphrase of it. How to compare penetration testing proposals sets out the rest of what to read in one.
The mapping should also say when the test repeats. The UAE instruments read as periodic, the card standard adds testing after significant change, and an API changes in ways a web application does not. A new partner onboarded onto an existing API. A new scope added to the consent model. A new field in a response that raises the classification of the endpoint. Each is a change to what the controls protect, with no release to mark it, and a mapping that names those triggers and the retest behind each is the one an examiner can still read a year later.
Where the four families bind in Dubai and Abu Dhabi
In Dubai the two instruments most likely to read an API control mapping are CBUAE's, for the banks and payment institutions licensed there, and DESC's, for government entities and the suppliers that integrate with them. Both read the same four families and attach the obligation to the party holding the connection. A free-zone software supplier in Dubai with no sector regulator of its own inherits DESC's expectation the moment its API carries a government entity's classified data. From that moment its API keys, its rate limits and its gateway logs are part of the entity's control evidence, and the tender for the integration asks for a current report on them. Firms inside the DIFC carry the Centre's own data protection law on top, so a personal-data endpoint there is read under two instruments.
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 or to the emirate's health information exchange is tested to the clinical data its endpoints return, and onboarding asks for evidence of the same four families before the connection goes live. The ADGM's data protection regulations add the same second layer for firms inside it. Across the United Arab Emirates the families are constant. What varies is the examiner and the classification that sets the bar. Which endpoints, tokens and partners go into that scope is the work described in how to scope a penetration test. For an API it begins with the endpoint inventory and the list of secrets rather than with a hostname.
Frequently asked questions
Which UAE regulations cover API security?
No UAE instrument names an API. Four regimes ask for security testing of the systems that hold regulated data: CBUAE's standards for licensed financial institutions, the DESC Information Security Regulation for Dubai government entities and their suppliers, ADHICS for Abu Dhabi healthcare, and the UAE Information Assurance Regulation for federal entities and critical infrastructure. Each is organised in control families, and access control, cryptography, availability and logging are the four an API exposes directly.
Is rate limiting a regulatory requirement for APIs in the UAE?
Not by that name. The instruments ask for service continuity and for strong authentication, and an unthrottled verification endpoint fails the second whatever the login screen shows. An API pentest records the request rate each endpoint accepts before it slows or locks, and treats a one-time-code endpoint with no limit as an authentication finding rather than a continuity one.
What does an API pentest check about tokens?
Three things, matching the access control family: who the token was issued to, what scope and functions it may reach, and how long it lives. The test holds one token per role, including client-credentials tokens for partner integrations, calls every endpoint with each of them, and records whether expired or revoked tokens still answer and whether a refresh issued to one client is accepted from another.
How often does an API need to be retested under UAE rules?
The UAE instruments read as periodic, with the frequency set by the instrument in force and the classification of the data, and the card standard adds testing after significant change. For an API, a new partner, a new consent scope or a new field in a response is a change to what the controls protect. The control mapping in the proposal should name those as retest triggers.
