NESA auditors are no longer satisfied with a generic vulnerability scan and a checklist. When they assess your mobile applications, they are looking for specific evidence of security controls mapped to recognised standards and they know what the most common failures look like.
This post describes seven vulnerability classes that we see consistently in mobile applications across the UAE market all of which would result in audit findings if discovered during a NESA recertification review. For each one, we explain what the vulnerability is, why it matters in the context of NESA compliance, and what you can do about it.
1. Cleartext HTTP Traffic in Production
What it is: The application communicates with backend servers over unencrypted HTTP instead of HTTPS, or the Android Network Security Configuration permits cleartext traffic to specific domains.
Why NESA auditors care: Any data transmitted over cleartext HTTP authentication tokens, personal data, transaction details can be intercepted by anyone on the same network. In a UAE context, where public Wi-Fi usage is common in malls, hotels, and airports, this is not a theoretical risk. It is a practical, demonstrable exposure. Under NESA’s secure communication requirements, all data in transit must be encrypted using current cryptographic standards. Cleartext HTTP is a direct failure of that control.
MASVS mapping: MASVS-NETWORK-1 The app secures all network traffic according to the current best practices.
How to detect it: HEXMobileSuite checks the AndroidManifest for android:usesCleartextTraffic="true", inspects the network security configuration for cleartext domain exceptions, and identifies hardcoded HTTP URLs in the codebase. For iOS, it checks App Transport Security (ATS) exceptions in the Info.plist.
How to fix it: Enforce HTTPS across all endpoints. On Android, set android:usesCleartextTraffic="false" in the manifest and remove any cleartext exceptions from the network security configuration. On iOS, remove ATS exceptions or limit them to specific, justified domains with documented rationale.
2. Hardcoded API Keys and Secrets
What it is: The application contains API keys, client secrets, database credentials, or encryption keys embedded directly in the source code or compiled binary.
Why NESA auditors care: Hardcoded secrets are trivially extractable from an APK or IPA using standard decompilation tools. An attacker who extracts a backend API key gains direct access to the service the key protects potentially including customer data, payment systems, or administrative functions. NESA’s access control and credential management requirements mandate that secrets are stored securely and rotated regularly. Hardcoded secrets fail both requirements simultaneously.
MASVS mapping: MASVS-STORAGE-1 The app securely stores sensitive data.
How to detect it: HEXMobileSuite scans decompiled source code and binary strings for patterns that match API keys, OAuth secrets, Firebase configuration tokens, AWS access keys, and other common credential formats. Findings include the exact string and its location in the codebase.
How to fix it: Move all secrets to server-side storage. Use environment variables, secure vaults (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault), or server-mediated token exchange. The application should never contain a secret that would grant access to a backend system if extracted.
3. Debugging Enabled in Production Builds
What it is: The application is compiled with debugging enabled android:debuggable="true" in the AndroidManifest, or the iOS build includes debug symbols and is not compiled with optimisation flags.
Why NESA auditors care: A debuggable application can be attached to a debugger at runtime, allowing an attacker to inspect memory, intercept function calls, modify variables, and bypass security controls. This is the first thing a skilled attacker checks, and it is one of the easiest findings for an auditor to verify. Under NESA’s code security requirements, production applications must be hardened against runtime analysis.
MASVS mapping: MASVS-CODE-2 The app is built in release mode, with settings appropriate for a release build.
How to detect it: HEXMobileSuite checks the AndroidManifest for the debuggable flag, inspects build configurations, and identifies debug-related code paths and logging statements that should not be present in a production release.
How to fix it: Ensure that all production builds are compiled in release mode with debugging disabled. Implement build pipeline checks that reject builds with debuggable="true". Strip debug symbols from iOS production builds.
4. Insecure Data Storage
What it is: The application stores sensitive data authentication tokens, personal information, financial details in insecure locations. On Android, this includes SharedPreferences in MODE_WORLD_READABLE, data written to external storage, or sensitive data stored in SQLite databases without encryption. On iOS, this includes data stored in NSUserDefaults, the Documents directory without data protection, or the Keychain with insufficient access control flags.
Why NESA auditors care: Data stored insecurely on a device is accessible to other applications, to anyone with physical access to the device, and in some cases to remote attackers who exploit other vulnerabilities to gain file system access. NESA’s data protection requirements mandate that sensitive data at rest is encrypted and access-controlled. Storing authentication tokens in cleartext SharedPreferences is a direct failure of that control.
MASVS mapping: MASVS-STORAGE-1 and MASVS-STORAGE-2 The app securely stores sensitive data and prevents sensitive data from leaking.
How to detect it: HEXMobileSuite identifies usage of insecure storage APIs, checks for data written to world-readable locations, detects unencrypted database usage, and flags sensitive data types stored without appropriate protection mechanisms.
How to fix it: Use Android’s EncryptedSharedPreferences or the Jetpack Security library for sensitive data. Use SQLCipher for database encryption. On iOS, use the Keychain with appropriate access control attributes and enable file data protection classes.
5. Missing Certificate Pinning
What it is: The application does not implement certificate pinning meaning it trusts any valid SSL/TLS certificate presented by the server, including certificates issued by compromised or attacker-controlled certificate authorities.
Why NESA auditors care: Without certificate pinning, the application is vulnerable to man-in-the-middle (MITM) attacks where an attacker intercepts the HTTPS connection using a fraudulently issued certificate. This is particularly relevant for banking and financial applications where the data in transit includes authentication credentials and transaction details. NESA’s network security requirements expect applications that handle sensitive data to implement additional transport security beyond basic HTTPS.
MASVS mapping: MASVS-NETWORK-2 The app performs identity pinning for all connections to remote endpoints.
How to detect it: HEXMobileSuite checks for the presence of certificate pinning implementations Android’s Network Security Configuration pinning directives, OkHttp CertificatePinner, TrustKit, or custom TrustManager implementations. For iOS, it checks for NSPinnedDomains in the Info.plist or TrustKit integration.
How to fix it: Implement certificate pinning using the platform-native approach. On Android, use the Network Security Configuration with pin-set directives including backup pins. On iOS, use NSPinnedDomains in the Info.plist. Plan for pin rotation by including backup pins for your next certificate.
6. Exported Components Without Proper Protection
What it is: On Android, the application exports activities, services, broadcast receivers, or content providers that can be invoked by any other application on the device without requiring permissions, authentication, or input validation.
Why NESA auditors care: Exported components are accessible to any application on the device. If an exported activity handles sensitive functionality (password reset, payment confirmation, account settings) without verifying the caller, any malicious application can invoke it directly. This is a common vector for privilege escalation and data theft. NESA’s platform security requirements mandate that inter-application communication is controlled and authenticated.
MASVS mapping: MASVS-PLATFORM-1 The app uses IPC mechanisms securely.
How to detect it: HEXMobileSuite parses the AndroidManifest to identify all exported components, checks whether they require permissions or signature verification, and flags components that handle sensitive functionality without protection.
How to fix it: Set android:exported="false" for any component that does not need to be accessible to other applications. For components that must be exported, define custom permissions with android:protectionLevel="signature" to restrict access to applications signed with the same key. Validate all input received through exported components.
7. Weak or Deprecated Cryptographic Algorithms
What it is: The application uses cryptographic algorithms that are known to be weak or have been deprecated DES, 3DES, RC4, MD5 for hashing, SHA-1 for digital signatures, or RSA with key lengths below 2048 bits.
Why NESA auditors care: Weak cryptography provides a false sense of security. Data encrypted with DES can be brute-forced in hours. MD5 hashes can be collided trivially. SHA-1 signatures can be forged. NESA’s cryptographic requirements mandate the use of current, approved algorithms with appropriate key lengths typically AES-256 for symmetric encryption, SHA-256 or higher for hashing, and RSA-2048 or higher (or equivalent elliptic curve) for asymmetric operations.
MASVS mapping: MASVS-CRYPTO-1 The app employs current strong cryptography and uses it according to industry best practices.
How to detect it: HEXMobileSuite scans the decompiled codebase for usage of deprecated cryptographic APIs Cipher.getInstance(“DES”), MessageDigest.getInstance(“MD5”), and similar patterns and flags them with the specific code location and recommended replacement.
How to fix it: Replace all deprecated algorithms with current standards: AES-256-GCM for symmetric encryption, SHA-256 or SHA-3 for hashing, RSA-2048+ or ECDSA P-256+ for asymmetric operations. Audit all cryptographic operations and ensure keys are generated using secure random number generators.
How Many of These Apply to Your App?
The uncomfortable truth is that most mobile applications including those published by large, well-resourced UAE organisations contain at least three of these seven vulnerability classes. Many contain all seven.
The only way to know is to scan. HEXMobileSuite checks for all seven of these vulnerability classes and 117 more mapped to OWASP MASVS v2.1, in a single automated scan that completes in minutes.
Scan your app before your auditor does: hexmobsuite.hiesencyber.com free, no credit card required.
Hiesen Cyber Security | Hoisting Digital Fortresses Through the Storm hiesencyber.com