Ultimate security does not exist, but trying to ensure maximum security is a priority when developing applications. It not only protects the user’s data and the company’s data and logic, it also protects your reputation. App security starts in the backend
Authors: Dr. Rolf Kluge, Christian Amrell, Jakob Ulbrich
The onion approach and things to consider
While securing your app, think of it as an onion. It should have layers to make access to unauthorized third parties as hard as possible and thus protect the intellectual property of the company or developer. At least as important as that is protecting the user’s data, which could be especially sensitive if we are talking about banking apps or apps containing medical information. However, there will never be a 100% guarantee that the application is secure, as your solutions and methods could be bypassed by more advanced attackers. Also worth mentioning is the fact that most applications are backend-driven, so do not forget to properly secure the backend and API to avoid exposing sensitive and critical information related to it. This article encompasses protecting the app backend, obfuscating your source code and securing app user data.
These protective layers have your back(end)
Two-factor authentication (2FA for short) is widely known and used. It adds another layer of protection to logins and works by sending a PIN code or password from the backend to the user. The user receives the password or PIN code via email or SMS, an external device, or an authenticator application such as Google Authenticator. The user must then enter the PIN code or password, usually within a certain time frame, and send it back to the backend to verify the login and grant access to the account.
Another authentication method is Passkeys. This is a relatively new technology, but according to Apple it is the “next generation of account security”. They provide strong credentials and are considered safe from server leaks and phishing. Passkeys offer one-step account creation and password-free login using biometrics, such as Apple’s Face ID. There is no need to create or manage passwords. Passkeys are later shared between devices, for example via iCloud Keychain, and can also be shared with trusted contacts.
Regarding securing the traffic between the App and the Backend SSL pinning is worth mentioning. This method actively prevents third-party man-in-the-middle attacks. This ensures that the user is communicating through the app with the intended server by being pinned to a specific type of certificate. If there is a mismatch, the communication and therefore the connection will be interrupted. Since certificates expire at some point, maintenance must be planned and scheduled properly. Unplanned certificate changes in the backend will break the client.
If you want to learn more about maintenance and support and which services we at Appsfactory offer, check out our article here.
Furthermore, let us talk about “App Attestation”, an Apple framework which ensures that requests your server receives, come from legitimate instances of your app. The application creates a public and private key and provides an attestation object to the backend. This mechanism can be used to verify the identity of the client, whether it is a device or an app, and as a result detect modified or retired apps. However, app attestation is not suitable for all types of requests because it can slow down network calls. Also, the backend needs to adapt to the verification handling. The Google equivalent of App Attestation is called “Google Play Integrity API” and is working in a similar manner.
Finally, we want to acknowledge the blocking mechanisms because they add a layer of protection to prevent attacks on the backend. After multiple failed login attempts the user gets blocked from logging in for a specific period or has to unlock their account by email or SMS.
Fortress code: defend your work
Now that we have established ways to secure the backend, let us take a look at how to secure your code.
Jailbroken or rooted devices pose a security threat because they can bypass system restrictions. One way to mitigate the risk would be to automatically disable features in the app when a modified device is detected. You can also force the application to close and notify the user of the security implications and resulting functionality issues. Keep in mind that this may be annoying to the user, and that a modified device that receives regular updates may be more secure than a device that no longer receives security patches.
One of the most important and simplest steps is to handle secrets and keys properly to avoid exposing sensitive data and unauthorized use of keys. Keep sensitive data out of the repository as much as possible by storing and sharing keys only between developers, e.g. in .env files, or injecting keys as environment variables into CI/CD pipelines. Adding key obfuscation to the compiled binary is also helpful.
This brings us to the next point: code obfuscation. This solution is used to protect the code itself by using specific algorithms to transform the code in a way that preserves its functionality while obscuring its logic and structure, thus preventing reverse engineering and unauthorized modification. While Swift already creates compiled binaries, Apple currently lacks an official solution for additional code obfuscation. For Android, obfuscation can be integrated into the build toolchain but still requires configuration and setup.
Sensitive data needs some extra care
Finally, we want to talk about sensitive data, such as your bank account or medical information. When you use an app and switch between different apps, the system takes a snapshot of it and displays it in the app switcher. Obviously you want to avoid this with sensitive data. When working on iOS versions, clean up or replace your visible UI when the app goes into the background using delegate methods. And when working on Android versions, you can do the same, but you can also mark content as “secure”, which might mean that screenshots are prohibited. Screenshots and screen recordings can also be a threat, especially if they are taken accidentally or as part of an attack. The file could be accessible to other applications or shared with third parties. Usually, the recording of paid content is also prevented, e.g. streaming services do not want their content to be pirated. When an iOS user takes a screenshot, the system notifies the user. This feature can be stored in code and is available through common libraries for Swift. Screen capture detection can also be done in code, and while capturing, the visible UI is hidden. As mentioned above, Android offers the option to mark the content as “secure”, which prevents screen capturing altogether. Please note that on lower versions of Android there are no reliable mechanisms to detect screen captures.
In conclusion, there is no such thing as ultimate security, but the solutions and methods mentioned above give you a good idea of how developers try to secure your data as much as possible. As a user, make sure to keep your operating system and apps always up to data to benefit from this continuous effort. Further, especially in the ever-changing world of technology, it is crucial to stay informed — regardless of whether you are a developer or a user.
