10 Security Requirements for aSecure Mobile App in 2026

"Our last developer said the app was secure because it uses HTTPS and Firebase. Is that true?"

That's a paraphrase of a question I get, in some form, almost every month. My answer is that HTTPS and a managed backend cover maybe two of the ten things I'd check. The other eight are where apps actually get taken apart.

So here is the claim, with a date on it. On September 29, 2026, the most useful specification for secure mobile app development is still OWASP's Mobile Application Security Verification Standard, MASVS v2.1.0. It has 24 controls. I've boiled them into ten requirements you can hand to a developer, and each one below names the exact control IDs, the test that proves it, what breaks first and what skipping it costs.

If you want the general primer, we already wrote mobile app security best practices and compliance. This piece is narrower and more useful at contract time: acceptance criteria, not advice.

The belief a competent person holds goes like this: security is a list of features. Add encryption, add biometrics, add a jailbreak check, tick the boxes, ship.

It doesn't hold, because the app runs on a device you don't control. Anyone can install your release build on a phone they own, unpack it, read it, change it, and talk to your API directly with a script. Every check that lives only in the app can be switched off by the person holding the phone.

Think of the app as a customer at a bank counter. You can be polite to them, you can check their ID, but you would never let them walk behind the counter and update their own balance. Most insecure apps I review let the customer do exactly that. The app decides the price, the app decides the role, the app decides which appointment slots exist, and the server writes down whatever it's told.

Therefore:the ten requirements below split into two kinds. Some reduce what an attacker can learn from the device (secrets, storage, leaks, keys). The rest move authority off the device entirely. The second kind matters more, and it's the kind checklists skip.

OWASP's mobile project has three layers, and knowing which is which saves a lot of confused vendor conversations.

MASVS says what the app must do. The latest releaseis v2.1.0, from January 18, 2024, which added the MASVS-PRIVACY group. There are eight groups: STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE and PRIVACY, and 24 controls in total. Each control is one sentence. MASVS-STORAGE-1, for example, reads "The app securely stores sensitive data."

MASWE, the weakness enumeration, says what violating a control looks like. Under storage alone it lists things like sensitive data stored unencrypted in private storage, keys stored outside the platform keystore, and sensitive data hardcoded in the app package, per the MASVS-STORAGE page.

MASTG says how to test it. OWASP released MASTG v2.0.0 on July 4, 2026, the first stable version of a refactor that took about three years. The post counts 285 tests, 152 demos and 72 best practices, and every test now carries the MASWE weakness it checks. So the chain runs from a one-line requirement to a runnable test on a real device.

The old L1, L2 and R verification levels moved out of MASVS and into MASTG as testing profiles. In practice that means you pick the controls once and pick the rigor per app.

And the OWASP Mobile Top 10 2024? It's still the current list, and it's useful for explaining risk to a board. But it names categories, like M9 Insecure Data Storage, not pass or fail criteria. Write your contract against MASVS.

No secret that grants anything valuable ships inside the app. Not the payment provider key, not the AI provider key, not the admin token someone added to make a demo work.

Controls:MASVS-STORAGE-1 ("The app securely stores sensitive data.") and MASVS-CRYPTO-2 ("The app performs key management according to industry best practices."). The matching weakness is MASWE-0004, sensitive data hardcoded in the app package. Top 10 category: M1 Improper Credential Usage.

What to test:take the release build, not the debug one, unpack it, and search every string for anything shaped like a key, a token or a private URL. On Android that's the APK or bundle; on iOS the decrypted IPA. It takes about an hour with free tools.

What breaks first:the AI feature. Teams wire a model provider directly from the app to save a backend, and the key sits in the bundle. Obfuscation doesn't help much; the key has to be decoded at runtime, so it can be read at runtime.

Cost of skipping:someone else runs up your bill, or reads everything that key can read. And you can't fix it with an app update alone, because old installs keep the old key. You rotate the key, which breaks every old install at once.

The right model is a thin server proxy. The app calls your API with a short lived user token; your API holds the provider key and calls the provider. It adds a hop and a small hosting bill. That's the trade, and I'd take it every time.

Tokens go in the Keychain or the Android Keystore backed storage. Sensitive files use the platform's file protection. Nothing sensitive goes in plain preferences, a plain database or shared storage.

Controls: MASVS-STORAGE-1. Weaknesses: MASWE-0001 (unencrypted in private storage) and MASWE-0002 (unencrypted outside private storage). Top 10: M9 Insecure Data Storage.

Apple's Keychain Services exists for small secrets like passwords, keys and tokens. Its Data Protection system builds a hierarchy of keys on hardware encryption, with a fresh per-file key for each file. Both are free. You just have to use them instead of the convenient thing.

What to test:log in on a test device, use the app normally for ten minutes, then read the app's sandbox. Every file, every preferences store, every local database. Anything you can read in plain text, an attacker with the phone can read too.

What breaks first:caches. The login token is usually fine by the time I look. The API response cache holding a full patient list or order history usually isn't, because a networking library wrote it there without anyone deciding to.

Cost of skipping: one lost phone becomes a data incident. In healthcare, that can mean a breach assessment for every record the cache held.

The cheapest fix is not storing it. Ask of every cached field: does the app need this offline? Usually the answer is no, and the requirement is met by deleting code.

Sensitive data must not leave through logs, backups, the clipboard, keyboard caches, screenshots or the app switcher.

Controls:MASVS-STORAGE-2 ("The app prevents leakage of sensitive data.") and MASVS-PLATFORM-3 ("The app uses the user interface securely."). Weaknesses: MASWE-0005 (insertion of sensitive data into logs) and MASWE-0006 (sensitive data not excluded from backup).

What to test: attach to device logs during a full session and search for tokens, emails, names and IDs. Make a device backup and look inside it. Background the app on a sensitive screen and look at the switcher preview.

What breaks first: logging. Somebody added a line that prints the whole network response while debugging a bug in March, and it shipped. Crash reporters and analytics SDKs are the second most common path, because they collect screen names, form values and breadcrumbs by default.

Cost of skipping: data ends up with a third party you never listed in your privacy policy, which is a privacy problem on top of a security one.

On our healthcare work we treat logs as a place PHI is not allowed to exist, and we check it in CI rather than trusting reviewers to notice. More on that in the case study below.

Every connection uses current TLS, no cleartext exceptions in production, and the app pins the identity of the servers you control.

Controls:MASVS-NETWORK-1 ("The app secures all network traffic according to the current best practices.") and MASVS-NETWORK-2 ("The app performs identity pinning for all remote endpoints under the developer's control."). Top 10: M5 Insecure Communication.

The platforms do most of the first half for you now. Apple's App Transport Security requires TLS 1.2 or later with forward secrecy by default. Android's Network Security Configuration disables cleartext by default from Android 9 (API 28), and from API 24 trusts only system certificate authorities by default, not ones the user installed.

So the failure is almost never the default. It's the exception somebody added. A blanket ATS exception, a cleartext domain left in from a staging server, a debug trust override that made it into the release config.

What to test:read the Info.plist and the network security config first. Then route the device through an intercepting proxy with a user-installed certificate and watch what still connects. If your own API does, you're not pinning.

What breaks first with pinning:certificate rotation. Pin one key with no backup and no expiry, rotate the certificate, and every installed copy stops talking to your server. Android's own documentation says to always include a backup pin, and its pin-set takes an expiration date for this reason.

Cost of skipping:anyone on a hostile network, or anyone studying your API, reads and edits traffic freely. Pinning won't stop the device owner, who can strip it, but it stops the coffee shop.

Authentication uses a standard protocol and a maintained identity provider, tokens are short lived and revocable, and biometrics release a hardware key rather than flipping a boolean.

Controls:MASVS-AUTH-1 ("The app uses secure authentication and authorization protocols and follows the relevant best practices."), MASVS-AUTH-2 ("The app performs local authentication securely according to the platform best practices.") and MASVS-AUTH-3 ("The app secures sensitive operations with additional authentication."). Top 10: M3.

For the rules themselves I use NIST SP 800-63B-4, final since July 31, 2025. The parts that change app design:

• Passwords need at least 15 characters when a password is the only factor, and at least 8 when it is one part of multi-factor authentication.
• Composition rules (one capital, one symbol) are prohibited. Length and a blocklist of known bad passwords do the work instead.
• At AAL3, phishing resistance is required, and syncable authenticators such as synced passkeys shall not be used, because their keys can be exported.
• At AAL2, reauthenticate at least every 24 hours overall and after no more than an hour of inactivity.

Those come from the web version of the guideline. NIST writes for federal systems, so treat it as the best available yardstick rather than a legal requirement for a private app.

What to test:replay a token after logout. Replay a token after the password changes. Use account A's token to request account B's record. Then look at how the biometric prompt is wired: if a hooked function returning true opens the app, the biometric is decoration.

What breaks first: logout. The app deletes the token locally and the server keeps honoring it for thirty days.

Cost of skipping: a stolen token is a stolen account for as long as the token lives. Short lifetimes turn a permanent breach into a brief one.

Every decision worth money or privacy is made and enforced on the server: prices, discounts, roles, which records a user may see, which appointment slots exist.This is the requirement I'd keep if I could only keep one.

Controls:MASVS-AUTH-1 for authorization, MASVS-AUTH-3 for sensitive operations, and MASVS-CODE-4 ("The app validates and sanitizes all untrusted inputs."), read from the server's side, where the app itself is the untrusted input. Top 10: M3 and M4.

What to test: capture a request that carries a price, a role, a user ID or a record ID. Change it. Send it again. If the server accepts it, the app was the authority.

What breaks first: row access in a managed database. Apps built on hosted backends often talk to the database straight from the phone, and whether that's safe depends entirely on row level security policies. We wrote up that failure pattern in the Supabase RLS security checklist; one missing policy means one user can list every row.

Cost of skipping:this is where the expensive incidents come from. Not a single phone leaking, but every user's data readable by anyone who looked at one request.

A pattern we use: when the server offers the app a choice, it hands over a signed, opaque token for each option rather than the raw data. The app can pick an option. It cannot invent one, because a forged or edited token fails the signature check. It costs a few dozen lines on the server and removes a whole class of tampering.

Any key the app needs is generated inside the platform keystore, marked non-exportable, and used through the platform APIs with current algorithms. No homegrown crypto, no hardcoded keys, no deprecated modes.

Controls:MASVS-CRYPTO-1 ("The app employs current strong cryptography and uses it according to industry best practices.") and MASVS-CRYPTO-2. Weakness: MASWE-0003, keys stored outside the platform keystore. Top 10: M10 Insufficient Cryptography.

The Android Keystorekeeps key material out of the app process, can bind keys to a trusted execution environment or StrongBox hardware, and can require biometric or lock screen authentication before each use. That last one is what turns a fingerprint prompt into real protection: the key literally won't work without it.

What to test:find where keys are created and whether they're ever serialized. Search for weak randomness too. The MASTG v2 release post uses exactly this example: MASWE-0027, predictable random number generation, checked by MASTG-TEST-0204 on Android.

What breaks first:a key derived from something guessable, like the device ID or a constant, so the "encrypted" data decrypts for anyone who reads the code.

Cost of skipping:your encryption becomes a speed bump with a published bypass. Worse, it lets you tell an auditor data is encrypted when in practice it isn't.

Deep links, intents, push payloads, clipboard contents and anything loaded in a WebView are treated as attacker controlled.

Controls:MASVS-CODE-4, MASVS-PLATFORM-1 ("The app uses IPC mechanisms securely.") and MASVS-PLATFORM-2 ("The app uses WebViews securely."). Top 10: M4 Insufficient Input/Output Validation.

What to test: list every registered URL scheme, universal or app link and exported component, then fire crafted links at each one. Does a link open a screen that should need login? Does a parameter end up in a WebView URL or a database query? The MASTG v2 post shows how granular this has become: the old 513-line universal links test was split into separate tests, including ones for missing input validation and missing source validation in custom URL scheme handlers.

What breaks first:a WebView with JavaScript and a native bridge enabled, loading a URL taken from a link parameter. That combination lets a web page call your app's native code.

Cost of skipping: one tapped link in a text message can drive actions inside a logged-in session.

You know every SDK in the app, you scan them for known vulnerabilities on every build, you set a sane minimum OS version, and you can force users off a dangerous version.

Controls:MASVS-CODE-1 ("The app requires an up-to-date platform version."), MASVS-CODE-2 ("The app has a mechanism for enforcing app updates.") and MASVS-CODE-3 ("The app only uses software components without known vulnerabilities."). Top 10: M2 Inadequate Supply Chain Security and M8 Security Misconfiguration.

Forced updates matter more than people expect, and here's why. Every fix in requirements 1 to 8 only protects users who update. Without a server-driven minimum version, a vulnerable build can stay in use for years.

What to test: generate a dependency list from the release build, including transitive packages, and check it against known vulnerability databases. Then ask the team to show you the kill switch: what happens if the server says version 3.1 is no longer allowed?

What breaks first: the analytics and ad SDKs nobody on the team chose, pulled in by one line during a growth push.

Cost of skipping:you inherit someone else's vulnerability and have no way to pull the affected build.

Apps with something worth stealing check platform and app integrity, and send the result to the server as one input to its decisions.Apps without that exposure can do less here, and that's fine.

Controls:MASVS-RESILIENCE-1 ("The app validates the integrity of the platform."), MASVS-RESILIENCE-2 ("The app implements anti-tampering mechanisms."), MASVS-RESILIENCE-3 ("The app implements anti-static analysis mechanisms.") and MASVS-RESILIENCE-4 ("The app implements anti-dynamic analysis techniques."). Top 10: M7 Insufficient Binary Protections.

On Android, the Play Integrity API returns verdicts on whether the binary is the one Google Play recognizes, whether the device passes integrity checks and whether the user got the app from Play. Google is explicit that verdicts are checked on your server, including the request hash or nonce that stops replays, and that the API should not be your sole anti-abuse mechanism. The default quota is 10,000 requests a day across all installs, so plan when you call it.

On iOS, App Attest generates a key in the Secure Enclave and lets your server verify that requests come from a genuine instance of your app.

What to test: run the app on a rooted or jailbroken device with a hooking framework and watch what the server does. Not what the app does: what the server does.

What breaks first:checks that live only in the app. A local "is this device rooted" function is the first thing an attacker patches out. Google also warns that caching verdicts opens you to proxying, where a verdict from a good device is reused elsewhere.

Cost of skipping:for a banking, payments or controlled substances app, automated abuse at scale. For a clinic's appointment reminder app, probably not much, which is why this is the requirement I size rather than mandate.

MASVS-PRIVACY isn't an eleventh requirement so much as a filter over the other ten. Its four controls read, verbatim: "The app minimizes access to sensitive data and resources." "The app prevents identification of the user." "The app is transparent about data collection and usage." "The app offers user control over their data."

The practical effect is on scope. Every permission you don't request, every field you don't collect and every SDK you don't embed is one fewer thing requirements 2, 3 and 9 have to protect. Minimization is the only security control that gets cheaper as you do more of it.

The Top 10 lists this as M6 Inadequate Privacy Controls, and it's the category most often missed in audits, because nothing technically breaks. The app just knows more than it should.

If your app handles electronic protected health information for a covered entity or business associate, the HIPAA Security Rule applies, and its technical safeguards map cleanly onto the ten.

The safeguards live in 45 CFR 164.312: access control, audit controls, integrity, person or entity authentication and transmission security. Under the current rule, several specifications, including encryption at rest and in transit, are "addressable", which means you implement them or document why an equivalent measure is reasonable. In a mobile app in 2026, I can't think of a defensible reason not to encrypt.

Status precision matters here. HHS published a proposed rewrite of the Security Rule on January 6, 2025 that would remove most of the addressable distinction and make encryption and MFA mandatory. As of today it's still only proposed. Coverage of the federal regulatory agenda reports the projected final action moved to July 2027, from May 2026. The 2003 rule governs. Building to the proposed rule now is a sensible hedge, not a legal obligation.

HIPAA also reaches past the app into hosting, vendors and business associate agreements. For the broader picture, see our healthcare app development page, and for who to hire, the cluster's pillar, the top 10 healthcare app development companies for 2026. I'm not a lawyer, and none of this is legal advice.

On breach cost. IBM's Cost of a Data Breach Report 2026, researched by the Ponemon Institute, puts the global average at $4.99 million. Per coverage of the report, healthcare averaged $6.64 million, down from $7.42 million, and led every industry for the 13th year running. To be clear about what that is: an average across breached organizations of all kinds and all breach types. It is not a mobile app figure, and I wouldn't let anyone present it as one.

The clearest example I can give is Zero Front Desk for Wisdom Tooth Clinic Miami, Dr. Peter K. Cudjoe's oral surgery practice. It's a bilingual voice and scheduling system rather than a consumer app, but the requirements that matter most here showed up in exactly the way this article describes.

And one mistake worth telling, because it's ours. At one point 47 booking links pointed at a hostname with no DNS. Nothing leaked, but nothing booked either. We fixed them and added a check that every link resolves. Separately, prompts drifting in a vendor console led us to version them in the repo. Both are the same lesson as requirement 9: if a thing can change without a build, it will.

Performance figures on that project are targets, not measured results, so I won't quote any as outcomes. For a mobile example in a clinical setting, we also built an internal mobile app for staff at Clinique CGSA, a medical psychology clinic, alongside a HIPAA-compliant scheduling system.

This is a scenario, not a client. A three location physical therapy group wants a patient app: book visits, see home exercise plans, message the front desk. iOS and Android. It will hold PHI.

Here's how I'd scope the ten, and roughly what each adds to a build. I'm hedging these because they are estimates from our own work, not published benchmarks.

1. 1.Requirements 1, 2 and 7 (secrets, storage, keys): mostly discipline. Maybe 3 to 5 days, most of it the server proxy for third party APIs.
2. 2.Requirement 3 (leaks): about 2 days to wire log scrubbing, backup exclusion and screen protection, plus a CI check that runs forever after.
3. 3.Requirement 4 (network): about 1 day, including pinning with a backup pin and an expiry.
4. 4.Requirement 5 (login): 3 to 5 days on a maintained identity provider, with reauthentication inside the NIST AAL2 limits.
5. 5.Requirement 6 (server authority): the big one. Maybe 8 to 12 days for authorization rules, row level policies, signed booking tokens and audit logs.
6. 6.Requirements 8 and 9 (input, dependencies): about 3 days, then a scan on every build.
7. 7.Requirement 10 (integrity): about 2 days for Play Integrity and App Attest feeding server risk scores. No heavy obfuscation, because the threat doesn't justify it.

Add it up: roughly 22 to 30 working days of the build go to security. On a 14 week regulated build, that's 70 working days, so security is about 31% to 43% of engineering time. Call it a third.

That sounds like a lot. But roughly half of it is requirement 6, which is also just the backend doing its job properly. Strip that out and the pure security overhead is closer to one day in five or six.

These are Frenchy Digital's published bands. Security is built in, not sold as an add-on, which is why it doesn't appear as its own line except for audits of existing apps.

For an existing app, the security audit is where I'd start: it maps the app against MASVS and hands you a ranked fix list. For new builds, it's part of native iOS app development and Android app development from the first sprint. Senior time is $150 to $225 an hour, proposals are fixed-price and phased within 5 business days, there's a 30-day post-launch warranty, and you own the full source code and IP.

Let me argue against my own list for a minute.

Pinning can take you offline. Get certificate rotation wrong and every install stops working at once. The bound on that downside is a backup pin and an expiry date, plus a forced update path from requirement 9. With those, the worst case is a bad afternoon, not a dead app.

Integrity checks can lock out real users.People on older or uncertified devices can fail device verdicts. That's why I send verdicts to the server as a risk signal and step up (ask for reauthentication, limit an action) rather than hard blocking.

Server authority adds latency and backend cost.Every decision is a round trip. For most apps that's tens of milliseconds and a modest hosting bill, and the alternative is trusting the phone. Still the right call.

Standards drift. MASTG changed shape completely this July. A requirement list pinned to specific test IDs will need updating. Pin your contract to MASVS control IDs, which are far more stable, and reference tests as the current method.

A few things I'd treat as a reason to slow down when hiring someone to build or audit a mobile app.

• They describe security as features (biometrics, encryption, jailbreak detection) and can't explain what the server enforces.
• They can't name the MASVS controls their work maps to, or they cite the Mobile Top 10 as if it were a test plan.
• Their pitch leans on a statistic about what share of apps are vulnerable, sourced to their own scanning product.
• Third party API keys are called directly from the app to save time.
• They promise an app that cannot be hacked. Nobody can promise that; ask what happens when one phone is fully compromised.
• For healthcare, they say they are HIPAA certified. There is no official HIPAA certification for a vendor or an app.

Here's what I couldn't verify or chose not to print.

Numbers I refuse.Mobile security vendors publish figures on what share of apps leak data or carry a serious flaw. I didn't print any. Each one comes from the vendor's own scans of its own customers' apps, which is not a neutral sample, and the methodology rarely says how "vulnerable" was defined. I also refuse any "cost of a mobile app breach" figure: IBM doesn't break out mobile apps, so any such number is an extrapolation somebody else made.

The healthcare breach averagecame from secondary coverage of the IBM report, because the healthcare figure wasn't in the IBM page text I could read. The global $4.99 million I read on IBM's own page.

The HIPAA agenda date of July 2027 comes from coverage of the regulatory agenda; the agenda entry I could load still showed the earlier May 2026 target. Either way, the rule is proposed, not final.

The MAS checklist.OWASP's old checklist page now redirects to a removal notice I couldn't load, so I haven't described its current state. The MASVS to MASWE to MASTG chain covers what it used to do.

The scenario estimates are from our own builds, not a benchmark. Your stack and team will move them. For the general practices article this one sits beside, see essential mobile app security practices.

You don't need an audit to find out where you stand. Here's what I'd do before Friday.

1. 1.Unpack your current release build and search it for keys and private URLs. If you find a third party secret, rotate it and move the call behind your server.
2. 2.Pick the one request in your app that carries money, a role or someone else's record ID. Edit it, resend it, and see whether the server says no.
3. 3.Paste the table of ten requirements into your next contract or statement of work as acceptance criteria, with the MASVS control IDs, and ask your developer which ones they can show passing today.

If the answers make you uncomfortable, that's useful information, and it's cheaper to get this week than after an incident. Time to go unpack a build.