Mobile API Security

Mobile API security is the practice of securing the backend APIs a mobile app depends on, and the way the app itself talks to them. It's the third of the three testing layers that make up MAST, alongside binary SAST and real-device DAST.

Most of a mobile app's real attack surface isn't the app itself. It's the conversation between the app and its backend. A lot of what makes that conversation different from a web app's comes down to one fact: a mobile app is what OAuth calls a public client. It can't keep a secret.

Why mobile is a "public client" problem

A web app running on a server the organization controls can hold a client secret, and nobody outside the company ever sees it. A mobile app ships to millions of individual devices, and anything embedded in its binary can eventually be extracted, decompiled, and inspected.

RFC 8252, OAuth's own specification for native apps, calls this out directly: mobile apps are public clients, and authentication has to be designed around that fact, not just patched around it.

Storing a secret in iOS's Keychain or the Android Keystore helps, but it isn't a fix on its own. On a rooted or jailbroken device, even that protected storage becomes reachable.

PKCE, and why the old approach doesn't work

For years, some mobile OAuth implementations used the implicit flow, returning a token directly in a redirect. That's now deprecated for native apps, because a token traveling through a redirect can be intercepted.

The current standard is the Authorization Code flow with PKCE (Proof Key for Code Exchange).

The app generates a one-time secret for that specific login attempt, so an intercepted authorization code is useless without it. The login itself should run in the device's system browser, not an embedded WebView the app controls, since a WebView can capture credentials in ways a shared, trusted browser session doesn't.

What mobile API security actually checks

Mobile API security checks the following:

• Whether authentication uses Authorization Code with PKCE rather than the implicit flow or a hardcoded secret,
• Whether authorization checks happen on the backend, not just in the app's own logic, since anything client-side can be bypassed by talking to the API directly,
• Whether an endpoint the app calls but doesn't surface in its UI is still reachable, and still needs the same access controls as the ones a user can actually see.

Mobile API Security vs. OWASP API Top 10

These sit at different altitudes. OWASP API Top 10 ranks the ten most critical risks across APIs generally, written mostly from a backend vantage point.

Mobile API security applies that same risk landscape to a client that's public by default, adding OAuth, PKCE, and binary-extraction concerns a purely backend-focused reading wouldn't surface on its own.

For the full risk list, see What is OWASP API Top 10?

Where Appknox fits

Appknox's API security testing covers the backend endpoints a mobile app calls, including ones never surfaced in the app's own UI, checking for authentication and authorization weaknesses, sensitive data exposure, and business logic bypass.

Findings map to the OWASP API Top 10 category and MASVS control they fall under, the same as binary SAST and DAST findings.

To check out the full testing methodology, See: Appknox Automated Vulnerability Assessment.

Frequently asked questions

What is Mobile API Security?

Mobile API security is the practice of securing the backend APIs a mobile app depends on, and how the app authenticates and communicates with them.

Why is a mobile app considered an OAuth "public client"?

Because it can't securely store a client secret. Anything embedded in a mobile app's binary can eventually be extracted, unlike a secret held on a server the organization controls.

What's wrong with the OAuth implicit flow for mobile apps?

It returns a token directly in a redirect, which can be intercepted. The current standard, Authorization Code with PKCE, avoids this by using a one-time secret unique to each login attempt.

Should mobile app logins use an embedded WebView?

No. Logins should run in the device's system browser; a WebView the app controls can capture credentials in ways a shared, trusted browser session doesn't.

Does Appknox test mobile API security?

Yes. Appknox tests the backend endpoints a mobile app calls, including undocumented ones, for authentication, authorization, and data exposure issues.

Related: What is OWASP API Top 10? | What is MAST? | Appknox Automated Vulnerability Assessment

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 testing mobile API authentication and authorization flows 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.