Ways to Protect Your Application from Hackers

Once your application makes it to the App Store or Google Play and gains any visibility, it will inevitably be targeted by hackers or curious programmers. There can be many reasons for this—rival companies, malicious individuals interested in new technologies, or simply "colleagues in the field."

If your application offers bonuses or benefits from using its services, this list expands to include those who may try to exploit your protocol to gain advantages or circumvent the main rules.

Additionally, the application and its related services can serve as sources of data mining for other services, especially if you provide valuable directories or catalogs via an API.

There are several ways to protect against this, and we’ll discuss a few of them.

Protocol Protection

First and foremost, don’t hesitate to use non-standard protocols and your own encryption and obfuscation algorithms. Remember— the more common your protection method, the faster an attacker will find a "lockpick" for your service.

There are many options to make your protocol unique and unrecognizable:

• Creating an additional abstraction (tunnel) over the standard HTTP protocol.
• Encrypting the request body with a key that changes with each call.
• Limiting requests based on time or API key.

Proper Protocol Architecture

It’s essential not only to prevent the misuse of the API but also to ensure that architectural vulnerabilities do not lead to data leaks.

For all requests involving personal data, you must verify that the user specified in the request matches the session owner making the request. All arguments in every request should undergo data substitution tests to exclude the selection of neighboring or foreign data.

All transaction IDs, object IDs, and user IDs should ideally be multi-digit and not simple auto-incrementing numbers. For this purpose, a standard 128-bit UUID works well.

HTTPS vs. HTTP

In today’s environment, all protocols should be secured through SSL (HTTPS) because hackers, bots, and other malicious actors are now joined by service providers who eagerly monitor their users' traffic.

Unsecured HTTP should only be used for CDN requests for static content, but even then, care should be taken to ensure that personal data cannot be extracted from their URL requests, such as user IDs.

Database Encryption

If there’s a risk that a device might physically fall into the hands of a malicious actor, it’s wise to additionally encrypt the database. For this purpose, both ready-made solutions (like SQLCipher) and custom file encryption methods can be used. In this case, proper key generation (password hashing) is critical to prevent offline attacks on the database file.

In any other case, you can rely on automatic file system encryption, which is now default on all modern smartphones.

How NOT to Protect Your Application

Here are some poor practices that are often found among application developers:

• Using non-standard ports (like 80, 443) to "hide" server connections will create issues in closed (corporate) environments.
• Not transmitting user biometrics back to the application or generating passwords based on them, but merely returning YES/NO based on fingerprint verification. Such checks can easily be bypassed through debugging tools or simply by jailbreaking the device.