Dotting the I's and Crossing the T's of OWASP Top 10 for Mobile Devs (Part 1)

by OluwafemiApril 29th, 2025
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

The OWASP Top 10 is a list of the top 10 security risks for mobile apps. This article explores what mobile developers need to watch out for. The list will be updated in the second half of 2025.

Company Mentioned

Mention Thumbnail
featured image - Dotting the I's and Crossing the T's of OWASP Top 10 for Mobile Devs (Part 1)
Oluwafemi HackerNoon profile picture
0-item

You have probably come across the OWASP Top 10 before, maybe in a security checklist, buried in some dev docs, or casually dropped during a sprint when someone from QA says, “Hey, we need to be security compliant.”


It often feels like something for backend folks or web teams to worry about, but in all honesty, it concerns a mobile developer as well.

This is not a deep dive into what OWASP Top 10 is; if you are not familiar with it, you can read about it in detail here. Instead, we will be exploring how these security risks specifically relate to mobile app development and what you, as a mobile developer, need to watch out for. This is especially timely as we anticipate the updated list in the second half of 2025, so staying ahead of these issues is more crucial than ever.

1. Broken Access Control

Imagine you are building a user dashboard, or let’s say the transaction page of an app, and then you decide to hardcode a role check on the frontend like if (user.role === 'admin')Or maybe you hide buttons based on user type? That’s cool for UX, not for security. Because that admin button you hid? If the API still allows it, it’s game over. And yes, people will decompile your APK or sniff traffic to find those hidden gems.


I learned this the hard way when I thought, “If they can’t see it, they can’t use it.” Spoiler: Visibility is not access control.


What helped me was to start thinking of the front end as a glass wall. Everything we build is visible to someone out there. So now, I don’t just “hide”, I verify. I also test with tampered tokens, simulate different roles, and work closely with the backend and my wonderful QA team to flag when APIS return more than they should.


Access control may start on the server, but we are the gatekeepers of the user experience. If we don’t guard the gate properly, someone is getting in.

2. Cryptographic Failures

This was previously known as Sensitive Data Exposure.


We often assume anything wrapped with HTTPS automatically means security. Well, that’s not completely true. HTTPS handles the safe delivery of data between the client and server, but what happens to that data before it is sent or after it arrives is also important. If you are sending sensitive information to unsecured logs, caching data without proper safeguards, or your validation is weak, HTTPS alone will not save you.


Late last year, I worked with a back-end developer who claimed to be sending encrypted data, only to discover he was using base64 encoding. No keys, no algorithms, just vibes. This kind of implementation gives a false sense of protection. I have also made the mistake of assuming sensitive payloads were encrypted on the backend, only to learn they were not.


Mobile developers are often the final stop before data is displayed, stored, or shared. Let us face the reality, if we log this data carelessly, store it in plain text, we become part of the vulnerability. This is why I would advise taking the time to research and fully understand the differences between encoding, hashing, and encryption—and more importantly, how to apply each one correctly in your app.


Tools like react-native-keychain and react-native-encrypted-storage offer secure and native-level encryption. They exist to help us do things right.

3. Injection

Oftentimes, injection attacks are always related to backend APIS or database queries. However, here is what doesn’t get said enough: Mobile developers are also responsible for this. OWASP ranking Injection at number three, with 94% of apps tested showing some form of it, says a lot. Now that Cross-Site Scripting is part of this category, injection isn’t just about SQL anymore, it is about any spot where user input isn’t handled safely.


It is easy to assume that if we’re not writing server-side logic, injection isn’t our business; nevertheless, we pass user input around constantly, for example, to SQLite databases, to WebViews, to native modules, and of course to APIS. If we are not sanitizing that data properly, we are setting up the backend or the user for a hit.


Even if you are not on the backend side of things, you are still very much at the frontline of securing the flow of data in your applications. Avoid rendering dynamic HTML in a webview, DO NOT build raw SQL queries without parameterization.

4. Insecure Design

We need to plan for security from the get-go, not something we add later. Insecure design is what you failed to think about before you even wrote the first line of code.


Insecure Design was introduced as part of the OWASP Top 10 in 2021. People started realising that not all security issues come from poor coding issues; some of them arise when the ideas are still on paper. There were no rules for how sensitive data should move through the app; users were given more permissions than they needed, and most importantly, we didn’t even cater for what should happen if something goes wrong.


We need to ask ourselves these questions before even writing the first line of code: Is our app’s design set up to keep data safe? Did we account for things like proper validation, least privilege access, and secure data flow? If we don’t do this, those small design flaws could lead to bigger security issues down the road.

5. Security Misconfiguration

There are little things we often overlook that can leave the door open for the middleman. Exposing environmental variables or leaving sensitive information like API keys inside the app bundle is a big security risk we should avoid. I often use react-native-config to help me manage my environment variables properly.


Another common slip is when you forget to disable debugging tools before releasing a production build. If your production apps have tools like Redux DevTools or even console.log traces active, it gives attackers a roadmap to understand how your app works internally. Ensure you strip out these tools when building for production. There are several tools out there that can help you do this as well.


Additionally, when connecting to APIS, skipping SSL pinning or accepting self-signed certificates in production "just to make it work" is an open invitation to man-in-the-middle attacks. Libraries like react-native-ssl-pinning exist to help enforce secure connections, and it is worth the extra effort to implement them right.


React Native apps often rely on third-party libraries, which come with a lot of vulnerabilities. npm audit and yarn audit are useful tools you can always use to check the health of these packages before you install them into your app

To be continued…

Trending Topics

blockchaincryptocurrencyhackernoon-top-storyprogrammingsoftware-developmenttechnologystartuphackernoon-booksBitcoinbooks