Securing an Enterprise Mobile App: The Non-Negotiable Basics

Introduction

An enterprise mobile application rarely handles trivial data: credentials, customer information, sometimes health or financial data. A vulnerability is therefore not just a technical incident — it is a legal, financial and reputational risk that can threaten an SMB's survival.

The good news: mobile security is not a mysterious art reserved for large corporations. It rests on public, proven frameworks and a few non-negotiable basics. This article presents the three pillars of a defensible mobile application: the OWASP Mobile Top 10, the OWASP MASVS (Mobile Application Security Verification Standard), and compliance obligations — Quebec's Law 25 and the GDPR in Europe.

The Baseline Framework: OWASP Mobile Top 10 (2024)

OWASP (Open Worldwide Application Security Project) publishes a list of the ten most common categories of risk for mobile applications. The 2024 edition (OWASP Mobile Top 10) serves as a universal reference grid, recognized by auditors and large enterprise clients.

The Ten Categories

• M1 — Improper Credential Usage: poor management of credentials and secrets.
• M2 — Inadequate Supply Chain Security: insufficient supply chain security (dependencies, third-party SDKs, tools).
• M3 — Insecure Authentication/Authorization: faulty authentication and authorization.
• M4 — Insufficient Input/Output Validation: insufficient validation of inputs and outputs.
• M5 — Insecure Communication: unsecured communications.
• M6 — Inadequate Privacy Controls: inadequate privacy controls.
• M7 — Insufficient Binary Protections: insufficient binary protection (no obfuscation, no tamper detection).
• M8 — Security Misconfiguration: poor security configuration.
• M9 — Insecure Data Storage: unsecured data storage.
• M10 — Insufficient Cryptography: insufficient cryptography.

Using this list as an architecture checklist, from the design stage, costs infinitely less than fixing things after a breach. For an SMB, it has a second merit: it structures the conversation with a client or auditor who asks "how do you handle security?".

MASVS: The Catalogue of Verifiable Controls

The OWASP MASVS (MASVS) goes further: it details the controls to put in place, organized into eight groups. It is the reference to cite in a statement of work.

• STORAGE — secure storage of sensitive data.
• CRYPTO — correct use of cryptography.
• AUTH — authentication and session management.
• NETWORK — communications security.
• PLATFORM — secure interactions with platform APIs and components.
• CODE — code quality and security (injections, error handling, secrets).
• RESILIENCE — resistance to tampering, debugging and reverse engineering.
• PRIVACY — respect for privacy and personal data.

The value of MASVS is that it is verifiable: each control lends itself to a test or to evidence. An SMB can ask its provider not "is your app secure?" (a useless question), but "which MASVS controls are covered, and how do you prove it?".

Secure Storage: Keychain and Keystore

This is the most frequently botched basic. Simple rule: no secrets in the clear.

• Never store an authentication token, API key or password in the clear in local preferences (SharedPreferences on Android, UserDefaults on iOS) or in a file.
• Use the secure storage mechanisms provided by the OS: the Keychain on iOS and the Keystore on Android. Keys there are managed by the system, and hardware protection (Secure Enclave on the Apple side, StrongBox on the Android side, where available) prevents their extraction even if the system is compromised.
• Encrypt sensitive local data, and never place the encryption key next to the data.
• Remember that obfuscation is not security: hiding a secret does not protect it.

These recommendations map directly to categories M9 (Insecure Data Storage), M10 (Insufficient Cryptography) and M1 (Improper Credential Usage) in the Top 10.

Authentication, Network and Code

Authentication (M3). Require strong authentication (multi-factor authentication when the context warrants it), short-lived sessions, revocable tokens, and a remote sign-out mechanism (sign-out on the server side, not just in the app).

Communications (M5). All traffic must go over TLS. A secret API key is never placed in a mobile application: an app's code can be extracted, so any embedded secret must be treated as public. It's a classic and costly mistake.

Code and Supply Chain (M2, M4, M7, M8). Lock dependencies, audit third-party SDKs, validate all inputs, sign and protect the binary, and harden default configurations. The supply chain (M2) is a growing concern: a compromised third-party library can contaminate an otherwise well-written application.

Compliance: Quebec's Law 25 and GDPR

Technical security is not enough: it must connect with legal obligations.

Quebec's Law 25

Québec's Law 25 ("An Act to modernize legislative provisions as regards the protection of personal information") governs the processing of personal information in Quebec. It requires, among other things:

• the appointment of a privacy officer;
• an accessible privacy policy, written in clear terms;
• valid, explicit, free and informed consent, collected separately for certain purposes;
• notification of privacy incidents presenting a risk of serious harm, to the Commission d'accès à l'information (CAI) and to the individuals concerned;
• access and rectification rights, along with a right to portability of certain information;
• a privacy impact assessment (PIA) for certain projects;
• rules governing the communication of information outside Quebec, with an assessment of the level of protection offered.

For a mobile application, this translates directly into the product: consent screens, a policy accessible from the app, handling of deletion requests, and mapping of the data collected.

GDPR (European Union)

The GDPR rests on principles that transpose almost word for word into the same requirements: lawfulness, minimization, purpose limitation, accuracy, storage limitation, integrity and confidentiality. It adds structural obligations — a record of processing activities, impact assessments (DPIA) for risky processing, rules for transfers outside the Union (standard contractual clauses, adequacy decisions) — and an administrative penalty regime that can reach, for the most serious infringements, a cap of 20 million euros or 4% of total worldwide annual turnover, whichever is higher (Article 83 of the GDPR).

For a Quebec-based SMB serving European clients, Law 25 and the GDPR stack: rigour is dictated by the most demanding regime applicable to the processing in question.

A Minimum, Non-Negotiable Checklist

1. No secrets in the clear: every credential goes through Keychain/Keystore.
2. TLS everywhere, without exception, and no secret keys embedded in the app.
3. Strong authentication and server-side revocable sessions.
4. Privacy policy accessible from the application.
5. Consents collected, logged and changeable.
6. Dependencies and third-party SDKs inventoried and tracked.
7. Logging without personal data in the clear.
8. Incident procedure: who notifies, whom, and within what deadlines.
9. Security testing before every major production release (static analysis, penetration testing according to risk).
10. Data mapping: where data goes, who accesses it, how long it is retained.

This list does not replace an audit, but it separates serious projects from dangerous ones.

Conclusion

The security of an enterprise mobile application is neither a luxury nor a mystery. It rests on three public foundations: the OWASP Mobile Top 10 (2024) for identifying risks, the MASVS for verifiable controls, and native secure storage (Keychain/Keystore) as the first technical reflex. Add to that compliance — Law 25 in Quebec and the GDPR in Europe — which turns these best practices into legal obligations.

For an SMB, the rational approach is to address these foundations from the design stage, not after the first breach. The cost of a security line properly placed at the start is out of all proportion to that of a data breach: penalties, loss of trust, damaged reputation. Security is not a brake on the product — it is what makes the product sellable to demanding clients.