menu
close_24px
✖
Back to glossary

Mobile Application Security

Mobile application security is the practice of protecting a mobile app and the systems it depends on, across its entire lifecycle: how it's built, how it's tested before release, whether it clears app store review, and what happens to it once it's actually live and in front of users.

That's a wider scope than any single tool or single test covers. This page maps the pieces, and links to where each one is covered in full.

A quick disambiguation

OWASP also uses "Mobile Application Security," shortened to MAS, as the name of the specific project that maintains MASVS, MASTG, and MASWE. This page covers the broader discipline. OWASP's MAS project is one part of it, the part focused on verification standards and testing guides.

Building it securely

Security starts before a single line of code ships to an app store, in the choices a development team makes:

  • How it handles authentication,
  • Where it stores sensitive data, and
  • Which third-party SDKs it pulls in.

MASVS defines what a secure mobile app actually has to do, organized into 8 categories a team can build against. MASVS itself was forked from ASVS, OWASP's equivalent standard for web applications and APIs, adapted for a compiled binary instead of a server-rendered page.

A growing share of that risk doesn't come from code the team wrote at all.

Software supply chain security covers the third-party SDKs and dependencies compiled directly into the binary, often without the team that shipped them ever reviewing their code.

Testing before release

Before a build reaches an app store, it needs testing across three layers:

Together, these three make up MAST (Mobile Application Security Testing), the combined methodology OWASP's MASTG documents test case by test case, mapped to the risks OWASP's Mobile Top 10 ranks as most critical.

Testing itself splits further by platform. Android Security Testing and iOS Security Testing each cover the specific technical surface: permissions and the Android Keystore on one side, Keychain Services and App Transport Security on the other, that a platform-agnostic description of MAST doesn't get into.

Clearing app store review

A secure, well-tested build can still get rejected by Apple or Google for reasons that have nothing to do with vulnerabilities: a missing privacy declaration, an undisclosed permission, a policy violation.

Store Release Readiness checks for this specifically, before a build enters formal submission, catching a different category of problem than any security test does.

What happens after it ships

Publishing an app isn't the end of the security story. Once it's live, someone else can repackage it, inject code, or publish a fake version using the same name and logo.

Drift detection and fake app detection cover this stage, the one most mobile security programs stop watching the moment a build goes live.

Proving it to regulators and auditors

For many organizations, none of the above matters unless it can be shown to a regulator or an auditor.

Depending on the industry and region, that could mean GDPR, HIPAA, PCI-DSS, DORA, SAMA, or NIST CSF, each with its own specific requirements, but the same underlying question: can the organization prove it tested for known risks, and defend that decision later?

CWE and its prioritized Top 25 sit underneath most of these frameworks as the shared vocabulary for naming what was actually found, the same way OWASP's API Top 10 does specifically for the backend side of a mobile app.

Where Appknox fits

Appknox runs binary SAST, real-device DAST, and API security testing as a single Automated Vulnerability Assessment, adds Store Release Readiness before submission and Storeknox's drift and fake-app detection after release, and maps every finding across all of it to the relevant OWASP, CWE, and regulatory frameworks automatically.

Most vendors cover one or two of these stages well. Appknox is built to cover the lifecycle end-to-end.

See the full platform: Appknox Automated Vulnerability Assessment.

Frequently asked questions

What is mobile application security?

Mobile application security is the practice of protecting a mobile app and the systems it depends on across its full lifecycle: secure development, pre-release testing, app store submission, and post-release monitoring.

Is "Mobile Application Security" the same as OWASP's MAS project?

Not quite. OWASP's MAS project maintains MASVS, MASTG, and MASWE specifically. Mobile application security, as a discipline, is the broader practice those OWASP projects are one part of.

What's the difference between mobile application security and MAST?

MAST (Mobile Application Security Testing) is the pre-release testing stage: binary SAST, real-device DAST, and API testing combined. Mobile application security is the whole lifecycle MAST is one stage of.

Does mobile application security stop once an app is published?

No. Drift detection and fake app detection specifically cover what happens after an app is live, since a published app can still be repackaged, tampered with, or impersonated.

Where should a mobile security program start?

Most start with MASVS to define requirements, move to MAST to test against them, and extend into store release readiness and post-release monitoring as the program matures.

By Aadarsh Anand, Security Researcher, Appknox Security Research Team

Appknox is an enterprise mobile application security testing platform. This page was written by Appknox's security research team based on direct experience building and running mobile security programs, end-to-end, across financial services, healthcare, and enterprise mobile app portfolios.

This page was drafted with AI assistance and reviewed and verified by the Appknox security research team.

DISCOVER MORE