Your business app has just reached 10 thousand downloads. Then one morning, your support team receives the same complaint from three different users: "I logged in on my new phone, and another person's account history appeared in my app." Investigation reveals the app stores session tokens on the device without protection, and a small gap on the server side lets other users' data leak through. Now you must choose: take the app down for emergency repairs and lose user trust, or keep it running with a leak that stays open.
Mobile apps are no longer an add-on product. For many Indonesian businesses — online stores, delivery services, clinics, cooperatives, even restaurants — the app is simultaneously the main storefront, the transaction channel, and the customer data warehouse. The more data flows through it, the higher the stakes. The Personal Data Protection Law now binds app controllers, and Indonesian users are increasingly quick to abandon apps that feel unsafe.
This article covers mobile app security from a business owner's perspective: why apps become targets, the most common vulnerabilities according to OWASP, secure development practices from day one, and what securing an app costs.
Why Mobile Apps Become Targets
Indonesia's internet user base keeps growing — the APJII survey records more than 220 million internet users with penetration approaching 80 percent — and most online time is spent in mobile apps. Banks, e-wallets, marketplaces, government apps: all of them now live in people's hands. For attackers, a mobile app is a bag of data the owner carries everywhere.
Several reasons make mobile apps attractive targets:
- Personal data in large volumes. Phone numbers, addresses, transaction history, even health data. Once breached, the data can be sold, used for targeted phishing, or turned into extortion material.
- Access to money. An app connected to a payment gateway is a magnet for stealing balances, cards, and OTP codes.
- Classic gaps still found everywhere. Many business apps are built in a hurry: API keys embedded in code, data stored without encryption, communication without HTTPS. These weaknesses are well known, and scanning bots can find them without special skills.
- User devices cannot be controlled. Unlike servers, the app runs on phones that may be rooted, connected to public Wi-Fi, or borrowed by someone else. Security cannot be handed over to the device entirely.
The pattern we see most often: business owners invest tens of millions to build an app, but treat security as a feature that "can be added later." Patching security after an app is released is far more expensive — and far more embarrassing — than building it in from the start.
The OWASP Mobile Top 10: A Map of Vulnerabilities
OWASP (the Open Worldwide Application Security Project) publishes a list of the ten most common security risks in mobile apps. This is not theory: it is a list compiled from thousands of security-tested applications. Get to know the five most relevant ones for business apps:
M1: Improper Credential Usage
Apps that store passwords on the device, reuse credentials across services, or force users to retype PINs constantly. Credentials are the keys to your warehouse; store them per standard (hashed with a strong algorithm on the server side) and never on the device.
M3: Insecure Authentication and Authorization
Logins that can be bypassed, tokens that never expire, or users who can access other users' data just by changing a number in the URL. This is the same category as the "someone else's account history appeared in my app" gap — and one of the most common causes of data leaks in Indonesian apps.
M9: Insecure Data Storage
Shopping records, chat history, tokens, even passwords stored in plain text in device storage. Anyone holding the phone — or malware that gets in — can read them. Data that does not need to be stored on the device should not be stored there at all.
M5: Insecure Communication
Apps that still communicate over plain HTTP, without encryption, or without certificate verification (certificate pinning). Anyone on the same public Wi-Fi can eavesdrop on the conversation between app and server. This is the equivalent of sending data on postcards: readable along the whole route.
M10: Insufficient Cryptography
Encryption built from scratch ("custom encryption"), outdated algorithms like MD5, or encryption keys embedded inside the app. Cryptography is not a do-it-yourself field; use proven standards and the platform's official libraries.
The other four risks — supply chain (M2), input/output validation (M4), privacy (M6), binary protection (M7), and misconfiguration (M8) — also matter, especially for apps handling payments or sensitive data. The full list is available on the OWASP website, and it is reading worth giving to your development team.
The Gaps Most Often Found in Business Apps
Here are the findings that appear most frequently when auditing mobile apps built by local vendors — not a complete list, but recurring patterns:
- API keys and secrets embedded in the app code. Keys that should be secret get downloaded by every user instead. Once an app is unpacked, anyone can read the keys.
- Session tokens without expiry. Users who log out are not really logged out; tokens remain valid for months, including on devices that have changed owners.
- Endpoints that do not check data ownership. The server answers any request without confirming the data actually belongs to the user asking for it.
- No protection against app tampering. Apps running on rooted devices or emulators go undetected, making them easy to analyze and manipulate.
- Security features that exist "only on screen." The login screen looks secure, but data on the server side sits unencrypted or without access control.
Notice: nearly all of these gaps live on the design and server side, not in the interface buttons. A mobile app's security is invisible from its appearance; it is determined by how the app is built behind the scenes. That is why choosing a development partner that takes security seriously matters as much as choosing the features to build — a full discussion of the selection process is in our guide to mobile app development services.
Security Practices That Must Exist from the Start
Mobile app security cannot be "attached" after completion. It must be part of every stage, from design to maintenance. Here are the practices you should demand from your development team:
Strong Authentication and Session Management
Use established authentication standards (OAuth 2.0 on the server side, not a homegrown login). Short-lived access tokens, securely stored refresh tokens, and all tokens revoked at logout or when an account is suspected of compromise. Enable two-factor authentication for accounts touching sensitive data.
Authorization at Every Endpoint
Every request to the server must be checked: does this user have the right to this data? The check happens on the server, not in the app — because users can manipulate the app. This is the only way to close the "change a number, see someone else's data" gap.
Encryption at Every Layer
App-server communication must be HTTPS with certificate verification. Sensitive data on devices goes into the platform's secure storage (Keychain on iOS, Keystore on Android). Data on the server is encrypted at rest. And never embed secret keys inside the app.
Minimize Collected Data
The simplest yet most violated principle: collect only what you truly need. An app storing ID card numbers "just in case" is storing a time bomb. The less data you hold, the smaller your attack surface and the lighter your obligations under the Personal Data Protection Law.
App Integrity Protection
Detect root/jailbreak devices, verify the app signature at runtime, and protect code from unpacking. This layer does not make the app invulnerable, but it raises the cost of an attack high enough that attackers move to easier targets.
Security Testing Before Release, Not After Incidents
Combine static analysis (SAST) that checks source code automatically, dynamic analysis (DAST) against the running app, and penetration testing by a third party that tries to break the app like a real attacker. For apps handling transactions, a pre-release pentest is not a luxury — it is a fitness check.
Android and iOS: Two Different Worlds
Different platforms, slightly different ways of securing them:
- Android. An open ecosystem: apps can be downloaded from outside the Play Store, and many Indonesian users install APKs from other sources. Make sure the app uses proper signing, review requested permissions, and handle rooted devices. Android's Keystore provides secure key storage — make sure it is used, not just available.
- iOS. Distribution is more locked down, but that does not mean it is gap-free: apps can still be analyzed from jailbroken devices, and requested permissions must still be minimal. Use Keychain for sensitive data and make sure business logic does not run entirely on the client side.
The rule that applies to both: never trust the client side. Anything the app can do on a user's device, an attacker can do too. All important decisions — verification, authorization, price calculations — belong on the server.
Types of Security Testing You Should Know
Many business owners think "security testing" is one thing. In reality there are several types, each answering a different question:
Static Analysis (SAST)
Examines source code automatically without running the app. It looks for dangerous patterns: hardcoded secrets, use of unsafe functions, or data leaks in logs. SAST is fast and cheap — it can run every time the code changes — but it only sees code, not the app's behavior at runtime.
Dynamic Analysis (DAST)
Tests the running app from the outside, like an attacker who does not know the code. It tries malicious inputs, checks server responses, and looks for gaps such as SQL injection or unprotected endpoints. DAST complements SAST: code that looks clean can behave dangerously at runtime.
Penetration Testing
A thorough examination by human experts: the security team tries to break your app — manipulating requests, unpacking the app, and testing the server — then produces a findings report with severity levels and remediation steps. Good mobile pentests include testing on rooted devices, network traffic analysis, and inspection of data storage on the device.
Security Code Review
Humans read the code line by line with a security focus, looking for gaps automated tools miss. This is the most thorough and most expensive testing type, usually reserved for the most sensitive parts: authentication, payments, and customer data handling.
When to run which? SAST and DAST from early development onward, repeated with every change. Security code review before release for sensitive modules. Full pentest before the first release, then repeated annually or after major changes. This sequence ensures no gap is only discovered after an incident.
Pre-Release Checklist: 10 Final Questions
Before the "publish" button is pressed, make sure your team can answer:
- Does all app-server communication use HTTPS with certificate verification?
- Is there an authorization check at every server endpoint?
- Do session tokens have an expiry and get revoked at logout?
- Are there no API keys or secrets inside the app code?
- Is sensitive data on devices stored in the platform's secure storage?
- Are the permissions the app requests truly minimal?
- Does the app refuse to run on rooted/jailbroken devices?
- Do logs avoid recording sensitive data like passwords or tokens?
- Have data backups and the recovery plan been tested?
- Have SAST, DAST, and pentest been run, with critical findings fixed?
These ten questions can be pinned on the development team's wall. A "not yet" before release costs far less than a "sorry" after an incident.
After Release: Security Is an Ongoing Process
A released app is not the end of security work. Software is a moving target: operating systems change, new vulnerabilities surface, and attackers keep probing.
- A regular update schedule. Fix vulnerabilities found in third-party libraries as soon as patches are available. Many leaks happen because an app uses an old library with known gaps.
- Monitor app behavior. Crash and error reports can be early signals of an attack. Anomalies such as a surge in failed logins or unusual traffic patterns deserve investigation, not dismissal.
- An incident response plan. Who gets called when the app is breached? How is the app patched urgently, and how are users notified? Write the answers before you need them.
- Periodic audits. Re-run the pentest once a year — or after any major change — to make sure new features did not introduce new gaps.
This is the same pattern as website security maintenance: security is not a one-time project, it is a maintained habit. An app launched and then abandoned is an invitation to attackers, just like a website that never gets updated.
The Consumer and Compliance Dimension
There is a dimension often forgotten: your app is also judged by users and regulators. The Personal Data Protection Law requires data controllers — including app developers — to keep users' personal data confidential, state the purpose of data collection, and process data with consent. An app that asks for excessive permissions or stores data without clarity is building legal risk.
Healthy practices: a privacy policy written in human language, clear consent choices, and a way for users to delete their account along with their data. This is not just compliance — Indonesian users are increasingly aware, and a one-star review saying "the app asks for contact access it doesn't need" is publicity you cannot delete.
How Much Mobile App Security Costs
The cost of app security depends heavily on complexity. Here are realistic ranges in the Indonesian market:
| Security layer | Estimated cost | Notes |
|---|---|---|
| Secure development practices from the start | Included in development cost | 10-20 percent of the development budget if counted honestly |
| Automated SAST/DAST | Rp 0-15 million/year | Free tools exist for small teams; commercial versions for larger organizations |
| Mobile penetration testing | Rp 15-50 million/session | Depends on feature count and app complexity |
| Monitoring and incident response plan | Rp 1-5 million/month | Includes monitoring and emergency support |
| Developer store fees | USD 25 (Play) / USD 99 (Apple) per year | The entry ticket to official distribution |
For comparison: a single data leak incident can mean cleanup costs, user claims, a lower app rating, and lost trust worth far more than every row above. The cost context for building the app itself is in our guide to business app development costs.
Questions to Ask Prospective Developers
Before signing a development contract, ask these — the answers are more honest than any portfolio:
- How do you store user passwords and session tokens?
- Does all app-server communication use HTTPS with certificate verification?
- Where are API keys and secrets stored, and who can access them?
- Is there an authorization check at every server endpoint?
- How long do session tokens last, and what happens when a user logs out?
- Have your apps ever been penetration tested? May we see the report?
- How do you handle vulnerabilities discovered after release?
Serious developers will answer calmly and specifically. Developers who dodge — "later, that's expensive" — are telling you something.
App Security Is a Selling Point, Not a Cost
In an increasingly crowded app market, security is actually a differentiator. An app that can answer "your data is safe" with evidence — encryption, access control, regular audits — wins trust that advertising cannot buy. Conversely, one data breach headline wipes out months of marketing investment overnight.
The Kartech. team in Bandar Lampung builds mobile apps with security as part of the process, not an afterthought: from architecture design and secure development practices to pre-release testing and post-launch maintenance. We start from your business problem, then translate it into an app that is secure and maintainable — see how we work on our services page or discuss your needs via our contact page.
Your mobile app is your business's face in your customers' hands. Make sure that face is not just attractive, but trustworthy.
