Mobile App Security Basics: Logins and Tokens, Sensitive Data, API Authorization, and Third-Party SDKs, and What Owners Should Ask

When many owners hear mobile app security, their first reaction is “We’re not a bank; nobody’s going to target us.” But the app security incidents seen in practice are rarely the elaborate break-ins from the movies. They are more basic oversights: a former employee’s account can still log in, a user’s old phone stays signed in after they switch to a new one, or changing a request slightly lets someone see another customer’s orders.

What these problems have in common is that an owner does not need to understand the technology to ask the right questions before development and to ask for evidence at acceptance. This article does not teach attack techniques. It explains the basics of app security from an owner’s point of view.

What follows covers, in order, account logins and tokens, sensitive data storage, API authorization, the risks of third-party SDKs, and when to schedule security testing.

First, understand this: everything on the app side can be seen

Most of a website’s code runs on a server where users cannot see it. An app, by contrast, is installed whole on the user’s phone. That means:

• The code inside the app can be taken apart and studied. Keys hard-coded into it, test accounts, and hidden admin functions can all be found.
• Requests the app sends can be intercepted and modified. Users can bypass the app’s screens entirely and send requests straight to your server.
• Data stored on the phone is not necessarily safe. If a phone is lost, lent to someone, or infected with malware, the data may be read.

So the core principle of app security comes down to one sentence: do not trust the phone; make every important decision on the server. Each section below is an extension of that principle.

Account logins and token management

After a user logs in, the app usually receives a credential representing the logged-in identity, generally called a token. Every later request for data carries this token to prove who the user is. Poor token management is like handing out your house key with no way to get it back.

Owners can confirm these points with the development team:

• Do tokens expire? Short-lived access credentials paired with a renewal mechanism are safer than tokens that are valid forever.
• Does logging out invalidate the token on the server? Deleting it only on the phone is not really logging out.
• When a password changes or an account is suspended, are all devices forced to log out?
• Can users see the devices they are logged in on and log them out remotely?
• Is there protection against brute-force login attempts? For example, a temporary lock or an extra verification step after repeated failures.
• Do important actions require re-verification? For example, entering the password or a verification code again when changing the linked phone number, withdrawing funds, or deleting the account.

If the app offers Google, Apple, or LINE login (LINE is the dominant messaging app in Taiwan), connecting third-party logins and merging accounts has its own subtleties. See the Social Login and SSO Guide.

Where sensitive data is stored, and for how long

The first question is not “how do we encrypt it?” but “does this data really need to be on the phone at all?” Not storing what you do not need is the most effective protection.

A self-check list for sensitive data

Owners can take this list and ask the development team to answer each item:

• Passwords: no plain-text passwords on the phone, and the server stores only a hashed result.
• Tokens and credentials: stored in the secure storage the system provides (Keychain on iOS, the Keystore mechanism on Android), not in an ordinary settings file.
• Personal data: national ID numbers, addresses, medical records, and the like. Are they fetched from the server only when needed and not left on the phone afterward?
• Caches and temporary files: do screenshots, cached images, or logs carry personal data?
• Keys inside the app: private keys for third-party services should not be written into the app; the server should make those calls on its behalf.
• Data in transit: every connection uses an encrypted channel, with no fallback to an unencrypted one.
• Retention: how long data is kept on the server, and how it is deleted when that period ends.

Which personal data you collect and why should also go into your privacy policy and be disclosed honestly in the app store listing. See Privacy Policies and Personal Data Protection for Websites.

API authorization: permissions must be checked on the server

A button the user “can’t see” on screen does not mean the user “can’t do” that thing. If the server simply accepts whatever requests the app sends, someone determined only has to alter a request to see another person’s orders, change another person’s data, or even perform actions reserved for administrators.

The principles owners should confirm:

• Every API checks whether this person may do this to this piece of data, not just whether they are logged in.
• Identity is never taken from a user ID the app sends; it is derived from the token on the server side.
• Admin functions are kept separate from regular user functions. Do not put the admin back office in the same app behind a hidden toggle.
• Request rates are limited, to prevent mass queries or automated abuse.
• Error messages do not reveal too much, for example by not returning full system error details.

For planning roles and permissions, see User Roles and Permissions Design. At acceptance, the most direct check is to log in as account A, try to access account B’s data, and confirm that the server refuses.

Third-party SDKs: convenient, with risks you cannot see

Apps often integrate many third-party packages, such as analytics, advertising, push notifications, maps, and support chat. Every additional SDK is another piece of code running on users’ phones that you do not fully control.

Risks to watch:

• More data collection than expected: some SDKs collect device information or location on their own, which your privacy policy and store data disclosure may not mention.
• Expanded permission requests: after integrating an SDK, the app suddenly asks for more phone permissions.
• Vulnerabilities in the package itself: older versions may have known security issues.
• Abandonment: the SDK vendor stops updating it, and it becomes incompatible with new operating system versions.

Owners can ask the development team for a third-party package list: name, purpose, what data it collects, current version, and who is responsible for updating it. Before adding an SDK, ask “Do we really need this? Is there a lighter way?” After launch, check for updates regularly; this is part of App Maintenance and OS Updates.

Security testing: when, and what

Security is not something to bolt on in the final week before launch. Schedule it by phase:

• Planning: the requirements document states what data must be protected, roles and permissions, login methods, and the security acceptance items.
• Development: code review includes security checks, and the source and maintenance status of every package is confirmed before it is added.
• Before launch: focused testing on logins, API authorization, and data storage. If payments, health data, or other sensitive data are involved, arrange independent third-party testing.
• Major updates: a new login method, a new type of data, or a new third-party integration all call for retesting the affected scope.
• Regularly after launch: check package updates, server configuration, and records of unusual logins.

For a reference basis, you can use the mobile app security test items common across the industry, or the rules set by your industry regulator. How far to go in practice depends on how sensitive your data is and what your partners require, so consult a security professional.

What matters after testing is not receiving a report but that every finding has someone responsible for fixing it, and someone retests after the fix. Security acceptance can be folded into the overall acceptance process; see How Software Acceptance Works.

Dividing the work with website security

If you also run a company website, its own security priorities, such as hosting and admin accounts, plugin updates, encrypted connections, and backups, are covered in Website Security Basics for Business. Apps and websites often share the same backend and APIs, so server-side permission checks and account management need one standard for both, rather than a strict app and a website that leaves a back door open.

Owners may not be able to tell whether an app’s security is done well, but when something goes wrong, they are the first to bear it. When NETVANA develops an app, we put login and token management, server-side permission checks, sensitive data storage, and the third-party package list into the specification and acceptance items from the planning stage. Software work is quoted after a consultation, based on how sensitive the app’s data is and its scope. To review the security basics of your app plan or an existing app, get in touch with us, and see the software services overview for what we offer.

Further reading: for looking after your company website’s security, see Website Security Basics for Business. For connecting third-party logins, read the Social Login and SSO Guide. For dividing roles and permissions, see User Roles and Permissions Design. For personal data notices and privacy policies, read Privacy Policies and Personal Data Protection for Websites. And for package and system updates after launch, see App Maintenance and OS Updates.