DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workkloads.

Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Secure API Design With OpenAPI Specification
  • OWASP TOP 10 API Security Part 2 (Broken Object Level Authorization)
  • Exploring API Headers
  • What D'Hack Is DPoP?

Trending

  • Beyond Microservices: The Emerging Post-Monolith Architecture for 2025
  • APIs for Logistics Orchestration: Designing for Compliance, Exceptions, and Edge Cases
  • Mastering Fluent Bit: Installing and Configuring Fluent Bit Using Container Images (Part 2)
  • Building a Simple Todo App With Model Context Protocol (MCP)
  1. DZone
  2. Data Engineering
  3. Databases
  4. Mobile Apps, APIs, and Secrets

Mobile Apps, APIs, and Secrets

We take a look at how to secure mobile applications in several different ways, such as user authentication and app attestation.

By 
Paulo Renato user avatar
Paulo Renato
·
Nov. 20, 18 · Tutorial
Likes (1)
Comment
Save
Tweet
Share
15.8K Views

Join the DZone community and get the full member experience.

Join For Free

This article is featured in the new DZone Guide to Dynamic Web and Mobile Development. Get your free copy for more insightful articles, industry statistics, and more!

With consumers now preferring mobile apps on their portable devices rather than websites on their laptops/desktops, mobile app development is an essential component in any enterprise software product lifecycle. While websites don't necessarily need APIs to serve their content, APIs are needed in the majority of the use cases for mobile apps. This adds a new layer of complexity in terms of software development, deployment, maintenance, and, as will be explained in this article, security.

Before APIs existed, in order to get data from third-party websites, the approach was to scrape the website HTML — producing unstructured data through a process that was both complex and prone to error. Helpfully, for the scrapers, modern APIs have a set of endpoints that return structured data, making its unauthorized collection and reuse so much easier.

Let's now take a look at how to keep a mobile app secure and free of risky secrets while guaranteeing that the API backend server knows with certainty that it is communicating with a genuine instance of the mobile app, even when the app is running in compromised environments, such as on rooted and jailbroken devices.

Securing the Communication Channel

First up, the mobile app must only communicate over an HTTPS secure channel to protect the confidentiality, integrity, and authentication of the requests from man-in-the-middle-attacks.

Image title

While the inexperienced developer may imagine that this is sufficient to secure communications between a mobile and an API server to keep all sensitive information away from attackers, experience tells us that these protocols are vulnerable. Older SSL or TLS 1.0 implementation shave been deprecated due to recent attacks against them, such as the Poodle attack, that in the end allows an attacker to gain access to supposedly protected data.

Even with the use of more secure protocols, an attacker can perform man-in-the-middle attacks against the API server and a mobile app installed in a device he controls in order to be able to extract all secrets and understand how the app queries the API server and what responses he gets back.

For further security, Certificate Pinning should be used so that the mobile app and the API server know exactly which certificate public keys to expect from each other, protecting themselves from rogue certificates provided by man in the middle attacks used to decrypt the data in transit. Unfortunately, even Certificate Pinning can be bypassed with the use of instrumentation frameworks, so we must look further for a more complete solution.

Mobile App Identification

The most common way for a mobile app to identify itself to the API server is with the use of an API Key, a unique ID string present in the headers of each API call or as a query parameter in the URL. The latter method is not recommended since it may be logged in any server that handles the URL and then extracted.

Image title

Note: Read the client as the mobile app and the resource server as the API server.

API keys help identify the origin of a request and can be used to rate-limit the frequency of API calls. They provide all users of the app with the same set of access permissions and call statistics gathering. Typically, though, API keys are static secrets within an app which are vulnerable to discovery and abuse, and blacklisting a compromised key will disable not just one but all installed app instances.

User Authentication

The most common user identification approach is to use the OAUTH2 authorization flow that provides an access token, also known asa bearer token, in the form of an JWT token, consisting of a JSON payload containing a set of claims with an expiration time. The token must be signed by the OAUTH 2 provider with a secret that is shared with the API server. Per best practices, it should be passed in the header of each HTTPS request so that the API server can validate the signature and check that the claims have not expired.

Image title

Note: Read user agent as a browser, client as the mobile app, authorization server as the OAUTH2 provider, and resource server as the API server.

User access tokens often have long lifetimes — hours, days, or eve weeks in order to improve the user experience. This makes life easier for attackers to steal and reuse them frequently until they are detected and revoked.

Though using a user OAUTH 2 access token appears to be an improvement over using an API key, it still leaves a security risk within the mobile app, API, and backend server ecosystem. Simply put, it does not resolve the problem of the API server responding to requests from a cloned or tampered mobile app or from an automated script or bot. Additional techniques such as mobile app attestation are needed.

Mobile App Attestation

A mobile app attestation service uses unique characteristics of the mobile app to attest its integrity and authenticity. An example of a unique characteristic might be a simple hash of the application package. The integrity of this simple attestation depends on the integrity of the hashing computation. Such a simple scheme might befairly easy to spoof.

A more robust integrity attestation service might use a random set of high-coverage challenges to detect any mobile app replacement, tampering, or signature replay. If the responses satisfy the challenges, the mobile app attestation service returns to the mobile app a very time-limited integrity token signed by a secret that is known only by the attestation service and the API server. On failure, the mobile app attestation service will sign the integrity token with a random secret that is not known to the API server so that the server can distinguish between an integrity token that passed the challenges from one that failed to pass them or from one that was forged by an attacker while trying to reverse engineer the mobile app.

Image title

This means that with every API call, both the mobile app attestation token and the OAUTH 2 access token must be sent in the request headers in order for the API server to be able to validate both tokens, before handling the request.

Unlike the user authentication flow, the mobile app attestation service doesn't require user interaction. Thus, the token lifetimes can be extremely short, and no refresh tokens are needed as in a user authentication flow.

Crucially, once the mobile app attestation service has provided the integrity token that makes it possible for the API server to distinguish requests coming from a genuine mobile app, we have now effectively protected the OAUTH 2 access token from unauthorized reuse. We could also go further and remove all secrets in the mobile app and instead delegate to the API server the authentication of all calls to third-party APIs.

Image title

Mobile App Secrets

When the need to use secrets in a mobile app to access an API server or third-party service arises, those secrets commonly appear as plain text in the source code. More advanced developers use code obfuscation techniques to hide them while others calculate the required secrets dynamically at runtime and apply code obfuscation techniques to hide the related source code.

It should come as no surprise to anyone that any secrets or decision-making code that lives on the mobile device is at risk. In fact, any secret stored statically or calculated dynamically in a mobile app can be reverse-engineered by using techniques ranging from proxy tools to instrumentation frameworks to code decompilers.

While iOS developers may use the Keychain Services API to store the secrets in the encrypted database, Android developers will encrypt the secrets and save them in SharedPreferences, using at the same time the Android Keystore to keep the encryption keys safe. However, as described above, both iOS and Android solutions can be reverse-engineered at runtime.

A good approach is to delegate access management to an API Gateway of all third-party services that a mobile app needs to work with, thus removing the need for the app to handle all these different secrets. However, this still leaves the mobile app needing to store and present the required secret expected by the API Gateway; thus, an obvious exploit remains for attackers.

Considering the mobile app attestation service described earlier, it should be clear that employing such a technique will remove the need to have secrets in the mobile app source code or, if they are necessary for other reasons, at least to protect them more effectively.

Reverse-Engineering

The best way to know how to properly secure a mobile app is to think like an attacker would. The first step in that direction is to know what tools exist and how they can be used to reverse-engineer a mobile app to gain valuable insights on what the app's security strengths and weaknesses are.

Reverse-engineering may seem like a daunting task, one that is only achievable by a few, but, in fact, it is readily achievable by "normal" engineers due to the proliferation of open-source tools which were initially aimed at helping security researchers, pentesters, and whitehats to automate their tasks.

The use of a set of combined tools (like Apktool, Dex2Jar, and JD-GUI for Android or Clutch in conjunction with IPA or a Hopper disassembler for iOS) will allow an attacker to extract the source code from any mobile app binary for further analysis using a tool like TruffleHog to identify all secrets in the source code.

With a proxy tool like MiTMproxy, an attacker can intercept, observe, and manipulate the traffic between the mobile app and the API server in order to see how requests and responses are made, how they are structured, and what secrets are used.

If using an MitM proxy is not enough, then an instrumentation framework like Frida or Xposed will allow an attacker to run the mobile app on a device or emulator to intercept system or method calls and/or manipulate the memory of the device in order to understand how the code works, bypass security checks, or extract whatever sensitive data the attacker is interested in.

Image title

An all-in-one solution for reverse-engineering exists by the name of Mobile Security Framework. It only requires the mobile app binary to be uploaded — and then the process of extracting the source code, finding secrets, and potential security vulnerabilities is automated, and a very detailed report is given in the end. This tool can also be used while the mobile app is running to perform a dynamic analysis of what the code is doing and what traffic is going in and out, just like you would do with a discrete set of tools.

Summary

With the increase in mobile app deployment and the common practice of embedding secrets in the source code to access in-house and third-party APIs, mobile apps and their APIs have become an attractive target for attackers and a liability for the businesses that they represent in terms of security and attack surface.

The use of a secure communication channel in conjunction with mobile app attestation is a solid and complete solution to reduce the attack surface and strengthen the security between a mobile app and an API server, because if you're using only a secure communication channel with an API key, user authentication and code obfuscation techniques will not prevent the API server from being abused by other sources.

So, the takeaway is to develop mobile apps with security in mind from day one, minimizing the use of embedded secrets and delegating access management to an API Gateway as needed. While mobile attestation techniques significantly improve app and API security, the developer should continuously conduct reverse engineering tests to probe the security and resilience of the code he writes following practices recommended in the OWASP Mobile Security Testing Guide.

This article is featured in the new DZone Guide to Dynamic Web and Mobile Development. Get your free copy for more insightful articles, industry statistics, and more!

mobile app API security authentication Web Service Database Integrity (operating system) Requests

Opinions expressed by DZone contributors are their own.

Related

  • Secure API Design With OpenAPI Specification
  • OWASP TOP 10 API Security Part 2 (Broken Object Level Authorization)
  • Exploring API Headers
  • What D'Hack Is DPoP?

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!