Dott

dott

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… 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. here 1. Broken Access Control 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. if (user.role === 'admin') 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. we 2. Cryptographic Failures 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. react-native-keychain react-native-encrypted-storage 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. react-native-config 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-ssl-pinning 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 npm audit yarn audit To be continued…

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

The third ever annual Noonies have concluded! For 3 months, netizens have cast over 105k votes for 4,961 nominees across 586 awards from 6 different categories! Now that (congrats!), we would like to share more about the prizes that they all win, and a bit more about HackerNoon’s stance on web3, privacy and the internet! This series is sponsored by our partners and . all winners have been announced Get.Tech Avast have been old friends of HackerNoon. They’ve not just sponsored the Noonies events (hosted on ), but are also giving away free domains for all winners. Dottech Domains noonies.tech If you’re a first prize winner, you’ll get a free domain for 5 years, second-place winners get a 3-year registration, and the third-place winners get a 1-year registration. What even is a domain? You know that computers only read 0s and 1s. Right? ** ** But humans read letters and words too!** ** Thus, while you might type in twitter.com or hackernoon.com, your browser converts that text into what is called an IP address. The IP address is the real location where the website is hosted and help make the task of seamless conversion of something like a hackernoon.com typed by you to an IP address like 104.21.54.123. Domain Registries In hackernoon.com, the hackernoon part is called a domain name and the .com is called the TLD (Top-Level Domain). Just as there are several domain names, there are several TLDs. For example, in noonies.tech, noonies is the domain name and .tech is the TLD. As a Noonies winner, depending on whether you came in 1st, 2nd, or 3rd, you’ll get a coupon code to redeem any non-premium .tech domain name for FREE. ** **

How to Claim Your Free Dottech Domain: For Noonies Winners with Love

, the leading new domain extension for the tech ecosystem, has launched , a pitch competition in partnership with , the world’s largest community of startups, founders, innovators, and creators, for idea-stage entrepreneurs to win $10,000 in equity-free funding and over $100,000 in startup benefits. .Tech Domains Pitch.Tech Startup Grind The virtual competition comes as innovation and digitization fueled by the COVID-19 crisis continues to surge across industries and power a startup boom, causing global VC funding to reach an with $125B invested. With just over 3% of that global funding going to seed stage entrepreneurs, .Tech Domains and Startup Grind are coming together to provide a platform that empowers idea-stage entrepreneurs at the start of their journey while minimizing the common barriers and hurdles that are often present during the early stages of building a startup. all-time high in the first quarter of 2021 Following approval, applicants will be assigned a unique pitch.tech url to promote their ideas and receive votes. The top ideas will participate in cohort finals where Startup Grind chapter directors from Phoenix, Miami, Boston, Hollywood/West LA and New Haven will choose which finalists will proceed to the Grand Finals. The ultimate prize winner of Pitch.Tech will be chosen at the grand finale where finalists will participate in a virtual pitch battle presided over by a jury of industry experts and investors who will evaluate the ideas, validate the business models, and choose the winner based on various aspects such as the entrepreneur’s creativity, confidence and impact. “We are proud to partner with Startup Grind on Pitch.Tech to support idea-stage entrepreneurs in bringing their innovations to life,” said Suman Das, Sr. Director of Brand Operations, .Tech Domains. “This virtual competition provides an opportunity for idea-stage entrepreneurs from all backgrounds to kickstart their startup journey and get access to resources and visibility that they need in the launch-phase.” “Startup Grind’s mission has always been to help founders, entrepreneurs, and startups succeed, regardless of geographic location or socioeconomic circumstance,” said Derek Andersen, Co-founder & CEO, Startup Grind. “We are excited to partner with .Tech Domains to further our work supporting the startup community. Pitch.Tech is the perfect extension of our mission and presents a rare opportunity to support idea-stage entrepreneurs with the resources they need to take the first step towards launch.” For more information on the competition and to apply, please visit: . www.pitch.tech

[ANN] Pitch.Tech - A Dottech Domains & Startup Grind Competition For Ideapreneurs

How We Monitor Jupiter’s Fiery Moon Without Leaving Earth

What’s Next for Jupiter’s Fiery Moon, Io?

Jupiter’s Plasma Torus Throws a Tantrum—Blame It on Io?

Io’s Mass Supply to Jupiter’s Magnetosphere: What We Know and What We Don’t

How Jupiter’s Fiery Moon Feeds the Jovian Magnetosphere

Jupiter’s Moon Io Keeps Leaking, and Scientists Are Watching

How Jupiter’s Plasma Torus Strips Away Io’s Atmosphere

Stories, News & Mentions about DOTT

Categories

Trending Topics

Stories, News & Mentions about DOTT

Dott’s Stories on HackerNoon

Categories

Trending Topics