What a security review of a UAE-facing app looks like
Imagine a retailer launching an Arabic and English app with Apple Pay checkout, UAE Pass sign-in, order tracking and an admin dashboard for support staff. This is hypothetical, not client work. The review starts from the product's flows, not from a scanner.
- Scope. What is in and out: the app, the API, admin tools, the hosting account and the outside services that touch customer data.
- Threat review. We map the core flows and ask what could go wrong at each step, as described in threat modelling.
- Code and configuration review. We read the risky code, such as sign-in, permissions and payment callbacks, against the OWASP Top 10, and check the cloud settings behind it.
- Testing. Penetration testing attacks the running product, with written permission and an agreed scope, to find logic flaws that code reading misses.
- Fix list and retest. Each finding has a severity, evidence, steps to reproduce and a recommended fix, and we retest after the fixes.
| Flow | What we look at | A typical weakness |
|---|---|---|
| Sign-in and recovery | Session length, multi-factor authentication, reset links | A reset link that never expires |
| Checkout and refunds | Server-side price checks, payment status, refund rights | A price the app can change before sending |
| Document upload | File checks, storage permissions | An ID scan that anyone with the link can open |
| Admin and support tools | Roles, audit logs, data visible to one agent | Every agent can export all customers |
Security messages in Arabic and English
A reset email, a sign-in alert, a one-time code and a payment warning are messages a person must read, trust and act on, in the language they chose. Write the Arabic as an Arabic writer would, not as a translation, and keep the sender name, domain and tone steady, because people learn what a genuine message looks like and attackers copy it.
- Digits. Some users type Arabic-Indic digits on an Arabic keyboard. Normalise them on the server before checking a one-time code, phone number or ID number, or genuine users fail and support is tempted to switch the check off.
- Mixed direction. User-typed names, file names and invoice lines can hide direction-control characters that reorder text on screen. Strip or isolate them wherever user text appears, so a line cannot be made to look like something else.
- Links. A Latin web address inside an Arabic sentence is easy to misread. Show the full domain on its own line, and state your rule for links, such as 'we never ask you to sign in from a link', in both languages.
Who is called when something goes wrong
Incident plans most often fail because nobody knows who to call, or the person who knows is away.
- Cover the whole week. Many UAE organisations work Monday to Friday, with shorter Fridays, but attackers do not. Alerts for sign-in abuse, failed payments and unusual exports must reach a named person on Saturday, Sunday and Friday afternoon too.
- Write the contact tree in both languages. Support staff who read Arabic complaints, engineers who read logs and the manager who speaks to customers should each know their part, with a customer notice drafted in Arabic and English in advance.
- Give researchers a route. A published address and a short policy, such as a security.txt file, let a person who finds a flaw tell you instead of posting it. Our own vulnerability disclosure policy shows the idea.
- Name who decides. One person can take a feature offline, one speaks to customers and one speaks to counsel.
Whether you must tell a regulator, customers or a partner bank after a breach, and how quickly, depends on the law, your sector and your contracts. Ask qualified UAE counsel, then write the answer into the plan.
Customer data and data location: the security side
Where data lives and who can reach it is a legal question and a security question. The UAE page lists the questions to bring to counsel. Engineering can prepare the facts:
- A data map. Every field, why you collect it, where it is stored, who sees it and which outside service gets a copy.
- Sensitive identifiers. Emirates ID numbers, passport details and identity scans carry high risk. Collect them only when needed, store them encrypted, show only the last digits and keep them out of logs, URLs and analytics.
- Quiet copies. Backups, error trackers, analytics, email providers, support desks and screen recordings often hold personal data in another region without anyone deciding that.
- Cloud region. Some providers run regions in the UAE. Check that every service you plan to use exists in your region, and decide who can administer production, and from where.
Awareness, not legal advice. Which data protection law applies, whether data may leave the country and what you must report are questions for qualified UAE counsel. We design with awareness of these rules and do not promise compliance.
Payments and identity as security review topics
Payments
- Server-side truth. The provider confirms payment to your server. Verify that message's signature, process each one once and never mark an order paid because the app said so.
- Amounts and refunds. Check price, quantity and discount codes on the server, use idempotency keys against double charges when a phone drops its connection, and give refunds their own permission and audit entry.
- Wallets, buy-now-pay-later and cash on delivery. Each adds states and callbacks to test. Cash on delivery also invites fake orders and repeated refusals.
- Card data. Use the provider's hosted fields so card numbers never reach your servers, and ask the provider and counsel which card-industry rules (PCI DSS) apply.
Identity sign-in with UAE Pass
A redirect-based sign-in such as UAE Pass has a few places to check: the return address must be on a fixed allow list, your server must validate the response instead of trusting the app, and the returned identity must link to the right account. Weak linking is the common failure, for example merging with an existing account because an email address matches. Keep your own recovery path, with multi-factor authentication, and check that it is not an easier way in. Onboarding requirements come from the identity programme, so confirm them with it.
Remote delivery and planning around the UAE week
Everything here works remotely. We review documents, architecture and code, test the running product over the internet or through an agreed access route, and walk your team through findings on video, at times that suit your working day. The UAE keeps one time zone, UTC+4, all year.
- Test windows. Agree days and hours, and a person on your side who can say stop.
- Freezes. Avoid testing or releasing fixes around Eid, in the last days of Ramadan and just before a major sales season. The UAE page covers the calendar.
- Read-out and retest. Walk through the report on a call, and plan the retest when you plan the test, so fixes are confirmed before launch.
Ramadan changes the rhythm of the day more than the week: hours are commonly shorter and activity moves to the evening, so book calls with that in mind.
What to ask any security provider
- What is in scope and out, and who gives written permission for testing?
- Will testing run against production or a staging copy, and when?
- Does the report separate confirmed issues from scanner noise, with steps to reproduce and a fix for each?
- Is a retest included, and what does the final report show?
- What happens to the data and credentials you must hand to the tester?
Be careful with a provider who promises compliance or a pass. A test gives evidence at one point in time, and compliance is decided by your compliance team, counsel or the regulator. Our method is the same everywhere: a threat review at the start, secure coding practice, testing before every release and a security review before launch with a prioritised fix list. The guide to secure app development covers the controls, and cybersecurity describes the service.