Securing Mobile Apps on iOS and Android

Mobile applications sit at the centre of how Australians bank, shop, book health appointments and interact with government services. A single insecure endpoint or weakly protected API can expose millions of records, attract the attention of the Office of the Australian Information Commissioner and trigger mandatory reporting under the Notifiable Data Breaches scheme. That is why a structured mobile application security assessment is now considered a baseline control rather than an optional exercise, particularly for organisations in finance, healthcare and retail.

Performing this kind of review on iOS and Android requires more than running an automated scanner. Each platform ships with its own sandbox, keychain or keystore design, certificate model and runtime restrictions. Testers in Sydney, Melbourne and Brisbane regularly work across both ecosystems because their clients expect a single report that maps findings to the OWASP Mobile Application Security Verification Standard, the ACSC Essential Eight and, where applicable, APRA CPS 234 obligations.

A good assessment blends static review of the source code, dynamic analysis against a live build and hands-on testing on real devices. The goal is to understand how the application behaves under normal use, how it protects stored data, how it talks to backend services and what an attacker could do with a jailbroken iPhone or a rooted Android handset. The findings then feed back into a remediation roadmap that development teams can act on quickly.

Before any tools are fired up, scope, threat modelling and compliance alignment should be locked in. This upfront work saves time during testing and ensures the resulting report speaks the language of the business, the developers and the regulator watching over the deployment.

Scoping and Threat Modelling the Engagement

A successful review starts with a clear scope document that names the platforms, versions, backend services and integrations in play. For an Australian retailer shipping to web, iOS and Android, that scope typically covers the customer-facing app, the staff application used in warehouses, the underlying APIs and any third-party SDKs such as analytics or payment gateways. Threat modelling helps identify which assets matter most, who might want them and how they could be reached.

Local context shapes this stage heavily. A Brisbane-based superannuation app must align with APRA CPS 234, while a healthcare provider in Adelaide needs to consider the My Health Records Act and the Privacy Act 1988. Government contractors in Canberra usually reference the Information Security Registered Assessors Program and the Australian Government Information Security Manual. Setting these references at the scoping stage makes the final report directly usable by compliance teams.

Threat modelling exercises should catalogue authentication flows, data storage locations, payment integrations and any push notification mechanisms. From there, testers can prioritise the parts of the application that handle personally identifiable information, authentication tokens or financial data.

Static Analysis of Source Code and Binaries

Static analysis reviews the application without executing it, focusing on the source, compiled binaries and configuration files. Tools can decompile or disassemble the package, then flag insecure coding patterns such as hard-coded secrets, weak cryptographic choices, exposed debug flags and improper certificate validation. Both iOS IPA files and Android APK or AAB bundles can be unpacked to inspect the contents.

A careful reviewer also checks the manifest or Info.plist for over-permissive entries, looks at how third-party libraries are bundled and confirms that code obfuscation has not introduced new vulnerabilities. For Australian fintechs, the static stage often highlights issues around PCI DSS requirements, especially when payment data touches the device.

Dynamic and Runtime Testing

Dynamic analysis exercises the running application, usually on a real iPhone, iPad or Android device, observing traffic, memory and behaviour. Burp Suite, Frida and MobSF are commonly used to intercept API calls, tamper with requests and inspect runtime values. Testers can swap a production endpoint for a rogue server, replay captured sessions and watch how the app responds.

Runtime testing also covers how the app behaves on rooted or jailbroken devices, whether anti-tampering controls fire correctly and whether sensitive screens are masked in the background. Local use cases, from Melbourne ride-share apps to Perth mining field-service tools, often demand offline mode testing because crews lose signal in remote areas.

iOS Specific Security Checks

iOS assessments focus heavily on the keychain, the Secure Enclave and the App Transport Security settings. Reviewers verify that tokens are stored with appropriate access groups and that biometric prompts use the LocalAuthentication framework correctly. Jailbreak detection, certificate pinning and the handling of universal links all come under scrutiny.

Australian banks operating under CPS 234 frequently require that iOS apps enforce jailbreak detection, disable dynamic instrumentation and protect jailbreak bypass attempts. Sideloaded enterprise builds also need attention, particularly for staff using custom BAs distributed through Apple Business Manager.

Android Specific Security Checks

Android brings its own terrain. Reviewers check the Network Security Configuration, the use of cleartext traffic, the integrity of the Android keystore and whether exported components expose unnecessary functionality. Play Integrity API and SafetyNet replacements are evaluated for their ability to detect tampered environments.

For Australian Android developers, attention to scoped storage, runtime permissions and foreground service declarations has grown since Android 14. Mobile security audits frequently uncover overly broad intent filters, debuggable builds left in production and WebViews that load remote content with JavaScript enabled.

Reporting Findings and Driving Remediation

Reports should map each finding to the OWASP MASVS control it violates, the business risk it creates and a concrete remediation recommendation. Severity ratings need to align with how the organisation measures risk, especially for entities regulated under the Notifiable Data Breaches scheme, where a high-rated mobile flaw may itself constitute an eligible data breach.

Remediation workshops help developers reproduce issues, understand the exploit path and adopt secure coding patterns. Retesting closes the loop and gives security teams the evidence they need for internal audit committees and external assessors.

Quick Wins to Lift Mobile Posture

• Enforce certificate pinning on every production API endpoint.
• Remove hard-coded keys, tokens and debug endpoints from both platforms.
• Enable ProGuard or R8 for Android and strip symbols from iOS binaries.
• Use the platform keystore or keychain for all credential storage.
• Block cleartext traffic and require modern TLS ciphers.

Indicators That You Need a Deeper Mobile Review

• New customer-facing features ship faster than monthly security reviews can keep up.
• The app handles payments, health data or government-issued identifiers.
• Third-party SDKs are added without documented security review.
• Past incidents involved credential leakage or API abuse.
• Compliance audits are approaching and evidence of mobile testing is required.

Reach out to a trusted mobile security partner to scope an assessment that matches your platforms, users and regulatory landscape. A focused engagement today prevents headline-making breaches tomorrow, and it gives your customers in Sydney, Melbourne and every regional community the confidence that their data is handled with care.