5 Steps to Take for Mobile App Security

Security is easy to treat as someone else's problem. Developers assume the platform handles it. Product owners assume the developers are on it. Designers assume it lives in the backend. And then a peer-to-peer currency exchange app we built, which let travellers swap leftover foreign currency at interbank rates without paying commission, got flagged by Apple for being a potential vehicle for money laundering. The core transfer mechanism worked well. The compliance layer did not exist.

Mobile security shapes architecture, feature design, and copy, not just the backend configuration.

That experience sits with us. We had built something genuinely useful, but we had not thought carefully enough about what unlimited peer-to-peer transfers look like to a regulator, or to an app store reviewer. Security on a mobile product is not a final checklist. It shapes app architecture design, feature design, copy, and the order in which users are asked to do things.

The steps below draw from real products we have built, including an anonymous messaging app, a performance coaching survey tool, and a fitness social network, because abstract advice on this subject is plentiful and largely useless. What matters is what the decisions look like when the product is in front of you and the tradeoffs are real.

Implement Proper Authentication and Access Controls

Authentication is the first question a security model has to answer: who is allowed to do what, and how do we know they are who they say they are? On the performance coaching survey app we built, we structured this carefully from the start. Only authenticated coach accounts could create surveys. That single rule stopped a large class of abuse before it could begin, because the ability to generate a survey was tied to a verified identity, not just anyone with the URL.

Access controls then determined what each authenticated party could see or write. Each QR code the presenter generated contained a unique key granting read access to only that specific survey. A respondent scanning a different code could not see another survey's data, because the key only opened one door. This kind of scoped access, where each credential unlocks the minimum required rather than a broad set of permissions, is the principle worth applying across any product that handles user data.

Map every role in your product (creator, respondent, admin, guest) and write out exactly what each role can read and write before you build. Gaps in that map become security gaps in the product.

The practical implication is that authentication decisions belong in the design phase, not the development sprint before launch. Once a data model is built around broad access, retrofitting granular controls is slow and costly. The architecture we used on the survey app, scoped keys per survey, meant the controls were part of the structure rather than bolted on afterwards.

Protect Data in Transit and at Rest

Data protection has two distinct problems that get conflated. Data in transit is what moves between a device and a server when a user taps something. Data at rest is what sits in a database waiting to be read. Both need attention, and the risks are different enough that they want separate answers.

On the performance coaching survey app, we used iOS's built-in libraries to generate QR codes entirely within the presenter's native app. The codes were never stored externally. The code was only ever live and visible in the venue at the time of the presentation. Once the presenter marked a survey as finished, no further responses could be recorded. That meant the survey window was time-limited, and the data was never sitting in an accessible external store waiting to be found.

We also used a cookie and device fingerprinting combination to restrict write access to the responses collection to one submission per device per survey. This prevented duplicate responses while ensuring respondents could not read other participants' answers. The fingerprinting approach here addressed a specific vulnerability: an open web form with no write restriction is trivially abused. By tying write access to a device signature for the duration of that survey, we closed that without requiring respondents to create an account.

According to NowSecure, 70% of analysed mobile apps can leak personal data through storage, APIs, logs, and SDKs. The response is not panic but precision: audit every path data travels, and every location it rests, and ask whether each is the minimum exposure necessary.

Build Security Rules Without Relying on an API Layer

The biggest technical challenge on the performance coaching survey app was locking down Firebase security rules without the protection of a dedicated API layer. We made a deliberate early decision to skip a traditional API for the MVP, which was reasonable for the scope. But that decision created a consequence: there was no controlled intermediary between the client and the database. Every security rule had to be written to account for the fact that a determined user could interact with the database directly if the rules allowed it.

We had to scrutinise every rule carefully. The app itself and the web response page both needed to be unable to exploit the database, even without an API acting as a gatekeeper. That kind of rigour is harder when there is no API, because an API can reject malformed or unauthorised requests before they reach the data layer. Without one, the security rules carry the full weight.

Without an API acting as gatekeeper, security rules carry the full weight of every request reaching the data layer.

The lesson is not that skipping an API is wrong. For an MVP with limited scope, it was the right call. The lesson is that the security implications of that choice have to be thought through at the point the decision is made, not discovered later. If you remove one protective layer, the layers that remain need to compensate.

If your product skips a traditional API layer, write out every data collection in your database and define explicitly which roles can read and write each one. Then test those rules by attempting to breach them from the client before you ship.

Design Features Around Real User Safety Risks

Security decisions are not only about protecting data from external attackers. Some of the most important ones are about protecting users from risks the product itself creates. On a fitness social network we worked on, the original design showed users' real-time locations on a map so people could find workout partners nearby. The research revealed that a high proportion of the user base would be female, and that made precise location sharing a significant safety concern. The feature that was meant to be the product's core value was also its biggest risk.

We redesigned the feature to introduce randomised location offsets. Instead of a precise pin, users could see only the vague area where a potential workout partner was located, expressed as a radius rather than an exact point. They could then view that person's profile and message them via built-in chat before choosing to share their precise location and arrange a meetup. The opt-in sequencing preserved the core value of the feature, knowing someone nearby wanted to exercise, without forcing users to expose their exact whereabouts before they had decided they wanted to.

On a separate project involving anonymous messaging, we added in-product reporting features as we got deeper into the product and began examining what anonymous communication makes possible. Anonymity lowers the threshold for inappropriate or bullying behaviour, so we built structures that allowed users to escalate concerns directly to the client's admin team. Safety thinking arrived mid-project rather than at the start, which meant some redesign. The better approach is to ask what the product makes possible beyond its intended use, and build the safety response into the first version.

Plan for Compliance Before You Ship, Not After

Compliance is the area where skipping ahead costs the most. On the peer-to-peer currency exchange app, we built the core transfer mechanism well. Users could exchange leftover foreign currency with other travellers at interbank rates, avoiding commission. The product worked. Then Apple flagged it as a potential vehicle for money laundering because there were no limits on the number of transfers between any two parties and no KYC checks adequate for a financial product of that type.

We had to go back and retrofit several layers of compliance. That meant more stringent Know Your Customer checks, enhanced transfer security, and hard limits on the number of transfers permitted between any two parties. Each of those things is straightforward to build in at the design stage. Retrofitting them into a live product, or a product under app store review, is slower and more expensive, and it delays launch.

According to Pye Tait Consulting, 2023, 48% of app developers whose products did not fully align with security and privacy requirements had an organisational plan in place over the next 12 months to address it. Planning to fix it later is common. It is also the wrong order. The compliance requirements that apply to your product, whether that is financial regulation, data protection law, or platform-specific rules, are knowable before you build. They want to be in the requirements document, not the post-launch retrospective.

Questions to Ask Before You Ship

1. Does your product handle financial transfers, health data, or location data? Each carries distinct regulatory requirements.
2. Have you reviewed the app store guidelines for the specific categories your app touches?
3. If your product allows peer-to-peer interaction, what limits exist on what one user can do to or with another?
4. Where does your product sit under GDPR or equivalent data protection law, and does your data architecture reflect that?

Communicate Security So Users Can Feel It

Technical security that users cannot perceive does only half the job. A user who feels unsafe will not complete a sign-up, will not share their location, and will not enter their payment details, regardless of how well-locked the backend is. The feeling of security is a design problem as much as an engineering one.

One of the most reliable ways to create that feeling is to ask for permissions rather than simply requesting them. On products where we have changed the framing of a permission request from a direct system prompt to a brief explanation of why the permission matters and what control the user retains, the response improves. People are more engaged and more likely to stay in a product when they feel they have made an active choice rather than been extracted from. That is a framing and tone of voice change, not a technical one.

The sequencing of trust-building matters too. Asking for high-stakes information, a location, a payment method, a contact list, before a user has had any reason to trust the product creates a friction that often reads as a threat. On the fitness social network, allowing users to view a potential partner's profile and exchange messages before choosing to share their exact location meant the high-stakes disclosure came after a relationship, however brief, had formed. That sequence converts far better than leading with the ask.

Audit every permission request in your product and write a one-sentence explanation for each one that explains what the user gets in exchange for granting it. If you cannot write that sentence clearly, the request is either too early or too broad.

Conclusion

Mobile app security is a set of decisions that run through the product from the data model to the copy on a permission request. The five steps above are not abstract principles: they come from products where we got things right and products where we had to go back and fix them.

The currency exchange app taught us that compliance requirements are knowable before you build, and that learning them from an app store rejection is an expensive way to find out. The performance coaching survey app showed that you can build a robust, multi-layered security model without a traditional API, but only if you know from the start that the security rules will have to carry the full weight. The fitness app reminded us that safety risks sometimes live inside the features that define the product, not outside them.

What connects all of these is that security thinking arrived late or incompletely, and the cost was time, redesign, or delayed launch. The earlier these questions enter the process, the less they cost to answer well. That applies whether you are pre-launch, mid-build, or looking at a product that shipped without enough of this in place.

If you are building a mobile product and want to think through the security and safety decisions before they become problems, let's talk about your product.

Frequently Asked Questions