Mobile app security requirements should be written as testable acceptance criteria before development starts—not reduced to a line saying the vendor will follow ‘industry best practice’. For every important control, define the risk it addresses, the implementation expectation, the evidence required and the person who accepts any exception.

That distinction matters because a polished iOS or Android interface can still expose data through weak API authorisation, unsafe local storage, unnecessary permissions, third-party SDKs or badly managed signing credentials. App Store or Google Play approval is a distribution gate; it is not your product-specific security assessment.

This guide is for business owners, product leaders and technology teams commissioning a customer, workforce or field application. It gives you an 18-point security schedule you can adapt to the app’s actual risk. It is not a claim that every app needs identical controls, nor is it legal or compliance advice.

Start with the risk profile, not the checklist

A useful security scope starts with four questions:

  • What data can the app read, create, change or transmit? Include cached data, photos, files, location, device identifiers, authentication tokens and information collected by embedded SDKs.
  • What can a compromised account or device do? Viewing public content is not the same risk as approving payments, changing inventory, accessing health information or controlling field work.
  • Where is trust enforced? The mobile client, backend API, identity provider, cloud services and third-party integrations form one system. A secure screen cannot compensate for an API that trusts a user-supplied record ID.
  • Which external duties apply? Privacy, sector, contractual and country requirements vary. Confirm them with the appropriate security and legal advisers instead of pasting a generic compliance list into the scope.

Classify the app’s data and business actions, sketch the system boundary, identify realistic abuse cases and then tailor the controls. The OWASP Mobile Application Security Verification Standard (MASVS) explicitly recommends a risk-based profile rather than treating every control as universally identical. NIST’s Secure Software Development Framework is also useful for defining how the supplier develops and maintains software, not just how one release is tested.

The 18 mobile app security requirements I would put in the scope

1. Client-owned accounts and release authority

The organisation commissioning the app should control its Apple Developer, App Store Connect, Google Play Console, cloud, domain, analytics and production-service accounts. The delivery team can be granted the access it needs without becoming the permanent owner of the product’s identity.

Acceptance evidence: named account owners, role assignments, recovery methods, multifactor authentication and a handover test completed before final payment or production cutover.

2. A complete data and action inventory

List every category of data the app collects, receives, derives, caches and shares. Map each data item to a feature, retention rule, storage location, user role and third party. Do the same for high-impact actions such as approving, refunding, deleting, exporting or changing another user’s records.

Acceptance evidence: a data-flow diagram and data register that match the implemented build—not only the initial wireframes.

3. Data minimisation by design

Do not collect data merely because a device or SDK makes it available. Remove unused fields, analytics events, identifiers and retention. If a feature can work with approximate location, a selected photo or an app-specific directory, do not ask for broader access.

Android’s official privacy and security guidance recommends minimising permissions, location access and data visibility. That is a design decision, not a final-week permissions cleanup.

4. Just-in-time permissions with a denied path

Each camera, microphone, location, contacts, Bluetooth, notifications or photo-library permission needs a named feature and a user-visible reason. Ask when the user invokes that feature. Define what still works if access is denied or later revoked.

Acceptance evidence: a permission matrix for iOS and Android plus tests for first request, denial, later approval, revocation and restricted-device states.

5. Store privacy declarations that match runtime behaviour

Apple privacy details, privacy manifests and required-reason API declarations must agree with the app and its included SDKs. Apple states that privacy manifests describe collected data and required-reason API use; since 1 May 2024, apps using covered required-reason APIs without an approved reason are not accepted by App Store Connect.

Google Play requires published apps—including closed and open testing tracks—to complete the Data safety form, subject to the documented exceptions. Google also makes the developer responsible for the declarations made by third-party libraries and SDKs.

Acceptance evidence: an SDK data inventory reconciled against the Apple privacy manifest, App Store privacy answers, the Google Play Data safety form and the published privacy policy.

6. Central identity with explicit assurance rules

Specify the identity provider and supported authentication flows. Prefer established protocols and platform-supported credential flows over a custom password implementation. Define when multifactor authentication, step-up authentication, passkeys or device biometrics are appropriate for the app’s risk.

Biometrics should normally unlock a credential or approve a sensitive action; they should not replace server-side identity and authorisation. Define enrolment, recovery, device change and account-locking behaviour as carefully as the happy-path login.

7. Token and session lifecycle

Write down access-token lifetime, refresh behaviour, secure storage, logout invalidation, inactivity handling, password-change consequences and the response to a lost device. Decide whether sessions can be viewed and revoked remotely.

Acceptance evidence: tests for expired, revoked, replayed and concurrently used credentials, plus proof that logs and crash reports do not capture tokens.

8. Server-side authorisation for every protected action

The API must verify the caller’s identity, role, tenant and permission for the specific record or action. Hiding an edit button in the app is user experience—not authorisation. Record IDs, prices, roles, approval states and ownership sent by a device must be treated as untrusted input.

Acceptance evidence: negative API tests showing that a user cannot read or alter another organisation’s records, elevate a role, bypass workflow state or repeat a privileged request.

9. Platform secure storage for secrets and credentials

Passwords, refresh tokens, private keys and similarly sensitive small values should not sit in plain preferences, ordinary files or an unencrypted local database. Apple describes Keychain Services as encrypted storage for small pieces of sensitive user data. Android’s Keystore makes cryptographic key material more difficult to extract and can keep key material non-exportable depending on the device and configuration.

Acceptance evidence: storage review against Apple Keychain Services and the Android Keystore, including backup and migration behaviour.

10. Deliberate local-data, cache and screen-exposure rules

Decide what can remain on the device, for how long and in which protection class. Cover SQLite or other databases, web views, thumbnails, downloaded files, clipboard content, notifications, screenshots, app-switcher previews, backups and diagnostic logs.

Do not demand blanket screenshot blocking without considering accessibility, support and user workflows. Use it where the information and threat justify it. The requirement should name the sensitive screens and the expected behaviour.

11. Secure transport without broad exceptions

Require encrypted transport, correct certificate and hostname validation, and a documented list of any exceptions. Apple’s App Transport Security applies secure-connection policies to Apple-platform apps. Android provides Network Security Configuration to declare trust sources, cleartext rules and related network settings without scattering them through code.

Certificate pinning is not automatically the right answer. It can reduce some trust risks, but it also creates certificate-rotation and emergency-recovery failure modes. Android’s own SSL guidance notes that server changes can leave a pinned app unable to connect until users receive an update. Make pinning a threat-based architecture decision with a rotation and recovery plan.

Acceptance evidence: release-build network tests, no unintended cleartext traffic and reviewed ATS/Android network configuration.

12. No reusable secrets inside the app package

An installed app is in the user’s possession and can be inspected. Do not treat embedded API secrets, service-account keys or encryption master keys as confidential. Public client identifiers may be required, but privileged credentials belong in controlled backend services or a suitable secret-management system.

Acceptance evidence: secret scanning of source, build configuration and release artefacts, followed by a manual review of findings and false positives.

13. Signing and build-pipeline custody

Define who controls Apple distribution certificates, provisioning profiles, App Store Connect API keys and Android signing keys. Limit production signing access, protect recovery material and keep an auditable release path. A developer’s personal laptop should not be the only place from which the company can ship an emergency update.

Acceptance evidence: documented release roles, protected CI/CD variables, branch and approval controls, key-recovery procedure and a reproducible production build.

14. Third-party SDK and dependency governance

Maintain an inventory of frameworks, plugins, SDKs and native libraries, including version, purpose, publisher, licence and data behaviour. Set rules for adding a dependency and for addressing vulnerable or abandoned packages. Advertising, analytics, crash reporting, chat and attribution SDKs deserve the same scrutiny as code written by the project team.

Acceptance evidence: a dependency inventory or software bill of materials, automated vulnerability results, privacy review and an owner for updates.

15. Safe offline and synchronisation behaviour

If the app works without connectivity, define which data is cached, whether it is encrypted, how long it persists, who can open it after a user or role changes, and what happens when competing edits synchronise. Queue replay, duplicate submission and stale authorisation are security as well as reliability issues.

For the wider architecture and acceptance tests, use my offline-first mobile app checklist. The security schedule should reference the same conflict, retry and deletion rules rather than inventing a separate sync model.

16. Layered verification mapped to an agreed baseline

Automated static analysis, dependency scanning and secret scanning are useful gates, but they do not prove that business authorisation, storage or runtime behaviour is secure. Map the app’s risk profile to selected MASVS controls, then use the OWASP Mobile Application Security Testing Guide for relevant static and dynamic tests.

Test the backend API separately. OWASP notes that MASVS is app-centric; remote endpoints require complementary web/API assessment. For higher-risk apps, define when an independent tester reviews the release candidate and how retesting will be evidenced.

17. Findings, exceptions and release decisions

Agree on a severity method, evidence format, remediation owner and release authority. Avoid vague statements such as “no high issues” unless the scope, build hash, platforms, test method, exclusions and unresolved findings are visible.

An exception should identify the control, reason, risk owner, compensating control and expiry or review date. This stops a temporary workaround becoming an undocumented permanent design.

18. Vulnerability response and supported lifetime

Security continues after store approval. Define the supported OS range, dependency update process, vulnerability-reporting channel, triage owner, incident contacts and method for shipping urgent fixes. Response targets should reflect severity and contractual needs; do not copy arbitrary times from another product.

Acceptance evidence: a tested incident path, ownership matrix, release procedure, dependency-monitoring output and an agreed end-of-support process.

Turn every requirement into an acceptance test

The most useful format is simple:

Field What to write
Risk The data, action or abuse case being controlled
Requirement A specific outcome using “must”, with the relevant platform and environment
Verification Review, static test, dynamic test, API test or operational exercise
Evidence Report, configuration, screenshot, test result, build hash or access record
Owner The person who implements it and the person who accepts the result
Exception Documented reason, compensating control, risk owner and review date

For example, replace “tokens must be stored securely” with: “The iOS release build must store refresh tokens in Keychain; the Android release build must protect the corresponding credential using Keystore-backed key material. The assessor will verify storage on both platforms and confirm that diagnostic logs contain no token values.”

That statement can be designed, priced, built and tested. The original sentence cannot.

What evidence should you receive before launch?

  • Approved architecture, data-flow and threat-model documents.
  • A traceability matrix linking requirements to tests and results.
  • Dependency/SDK inventory and privacy-data mapping.
  • Release-build identifiers and environment details.
  • Static, dependency, secret and dynamic testing results with reviewed findings.
  • Mobile and API penetration-test scope and report where the risk warrants it.
  • Store privacy declarations reconciled with the implemented app and SDKs.
  • Open findings, accepted exceptions and named risk owners.
  • Signing, store, cloud and repository access under client-controlled accounts.
  • Incident, update, backup and handover procedures tested by the people who will operate them.

Security evidence is not a pile of screenshots. It should let another competent person identify what was tested, against which build, what was excluded and what remains unresolved.

Common procurement mistakes

  • Buying a penetration test at the end: useful findings arrive when architecture and deadlines are hardest to change.
  • Assuming cross-platform means one security implementation: Flutter and React Native still rely on iOS and Android permissions, storage, signing and native dependencies.
  • Checking only the mobile binary: the backend API may carry the greater authorisation and data risk.
  • Accepting tool screenshots as proof: scanners miss business-logic flaws and need human interpretation.
  • Leaving production ownership with the vendor: this creates avoidable release, continuity and exit risk.
  • Copying every possible control: an oversized checklist produces exceptions and theatre. Tailor the baseline to the product.

If you are still comparing suppliers, start with my broader mobile app development quote checklist. Use this security schedule as the detailed appendix behind the security and acceptance sections.

My practical recommendation

Define the app’s data and high-impact actions first. Select a risk-based MASVS profile, add platform and API requirements, then agree on evidence and release authority before the build is priced. Keep the security schedule in the delivery backlog so it is demonstrated during sprints—not rediscovered days before store submission.

If you want an independent review of a proposed mobile architecture or development scope, see my mobile app development service or book a 15-minute call. I will help you identify the decisions and evidence the project needs; any scope, timing or commercial commitment follows only after reviewing the actual requirements.

Frequently asked questions

Is App Store or Google Play approval a security assessment?

No. Store review checks platform policies and distribution requirements, but it does not verify every product-specific threat, backend authorisation rule, data flow or business risk. Treat approval and security verification as separate gates.

Do Flutter and React Native apps need the same security controls as native apps?

Yes. Cross-platform frameworks can share application code, but the app still depends on iOS and Android permissions, secure storage, signing, native plugins and platform privacy rules. The backend API also needs its own controls and tests.

Is certificate pinning mandatory for a secure mobile app?

No. Pinning can be appropriate for a defined threat model, but it adds certificate-rotation and recovery risk. Decide deliberately, document the operational plan and avoid using pinning as a substitute for correct TLS and certificate validation.

When should a mobile app receive penetration testing?

Plan testing early enough to influence architecture, then assess a release candidate before production where the app’s risk warrants it. Retest material fixes and reconsider the scope after significant authentication, payment, data or API changes.

Does OWASP MASVS cover the backend API?

MASVS is primarily focused on the mobile application. The remote API and web services need complementary security requirements and testing, including authentication, object-level authorisation, input validation and business-logic abuse cases.

Who owns mobile app security when development is outsourced?

The buyer owns the business risk and must define acceptable outcomes. The delivery team designs and implements the controls and supplies evidence. An independent specialist can verify higher-risk areas. The contract should make those responsibilities explicit.

Primary references

Have something to build or fix?
Book a free 15-minute call.
Get honest advice and a clear next step, whether or not we work together.
Book a 15-minute call →
AYArsalan YasinOdoo, AI automation, software and mobile app specialist based in Sydney. Ten years of hands-on delivery.