Learn · Mobile app security · Updated
Mobile application security keeps your app, the data on your users’ phones and the APIs behind it safe from attack. It works by checking the app at every step of how it is made: the code, the build, the running app and the version in the store.
Why mobile is its own problem
Anyone can open it
Once it is in the store, anyone can download your app, pull it apart and read what you shipped: keys, endpoints and debug settings.
Data lives on the phone
Tokens, caches, logs and backups sit on a device you do not control, next to every other app.
Every screen calls an API
Each request can be copied, replayed or changed. The server has to check every one, not trust the app.
You ship other people’s code
SDKs and open-source packages run inside your app with the same access as the code you wrote.
OWASP MASVS areasStorageCryptoAuthNetworkPlatformCodeResiliencePrivacy
How it works
Security is not one scan before launch. Each step of building an app can let a different problem in, so each step gets its own check. Pick a step to see what can go wrong and what Nandee does about it.
Every change is a pull request. This is the cheapest place to catch a mistake, before it is copied into a build.
// LoginService.swift let apiKey = "sk_live_4f9a"
hardcoded key
Nandee SAST reads the source on each pull request and flags the key. Nandee Green Agent opens the fix: move the key out of the app and read it from the Keychain.
Most of what ships is not your code. Every package and SDK runs with the same access as the code you wrote.
// build.gradle implementation "com.example:analytics:3.1.0"
known vulnerability
Nandee SCA lists every package and SDK in the build, checks each version against known vulnerabilities and license rules, and points to the version that fixes it.
Some problems only show up when the app is running: what it sends, what the server accepts, and what it lets one user see.
GET /v1/accounts/1043 → 200 OK, another user's account
server never checked who asked
Nandee DAST runs the app and probes the traffic it sends. Nandee Red Agent connects smaller issues the way an attacker would, to show what they add up to.
The release build is not always the build you tested. Debug settings, test endpoints and exceptions can slip in at the last step.
<!-- AndroidManifest.xml --> <application android:debuggable="true">
debug flag in release
Nandee SAST and Nandee SCA check the exact build you ship, so what was tested is what goes out.
An app that was safe at launch can become unsafe without a single code change: a new vulnerability in an SDK, or a new API behind an old screen.
// new advisory analytics 3.2.1 affected, fixed in 3.2.4
shipped last month
Nandee SCA flags new advisories for the versions you already shipped. Nandee DAST and Nandee Red Agent test again as your APIs change.
The five checks, in plain English
SAST, DAST and SCA find problems in what you write, what you run and what you include. Green Agent writes the fix. Red Agent shows what an attacker could do with what is left.
A spell-checker for security bugs in your code.
Tries every door and window of your running app.
Reads the ingredient label on every open-source package you use.
Writes the fix, ready for your developers to merge.
Connects small weaknesses the way a real attacker would.
One finding, start to finish
Here is how a single hardcoded key moves through the lifecycle, from the line that caused it to the test that proves it is gone.
let apiKey = "sk_live_4f9a"SAST flags a live key written into the app, where anyone who downloads it can read it.
reachable: release build exposed: yes
The finding is confirmed as real and in the release build, so it goes to the top of the list.
- let apiKey = "sk_live_4f9a" + let apiKey = try Keychain.read("api")
Green Agent writes the change and explains it. A developer reviews and merges it.
key in binary: no re-test: pass
The next build is tested again, so you can show the fix worked, not just say it.
Questions
They share a lot: both need secure APIs, authentication and safe handling of data. The difference is that a mobile app is installed on a device you do not control. Anyone can download it, pull it apart and read what you shipped, and the app keeps data on the phone itself.
SAST reads your code without running it, like a spell-checker for security bugs. DAST runs the app and tests how it behaves. Each catches problems the other misses, which is why mobile app security testing (MAST) uses both.
Software composition analysis lists the open-source packages and SDKs inside your app and checks them for known vulnerabilities and license issues. Mobile apps often ship more third-party code than first-party code, so this is where many issues come from.
The OWASP Mobile Application Security Verification Standard (MASVS) is the most widely used. It groups requirements into eight areas: storage, crypto, authentication, network, platform, code, resilience and privacy. The OWASP Mobile Application Security Testing Guide (MASTG) explains how to test each one.
They cover different parts of the lifecycle. SAST and SCA cover what you write and what you include. DAST and Red Agent cover how the running app behaves. Green Agent turns what they find into fixes. Start where your biggest risk is, and add the rest as you grow.