Mobile app security

It was necessary to think about this in advance and, for example, introduce a system of tokens for authentication. That is, each application passes authorization, receives an access key and sends it with each request. Without authentication, your server is open to everyone, and if you watch and analyze the logs of requests to the server, you will see a lot of interesting things and not only on port 80.

If your application does not work with finance, it is not so bad. Nowadays, DDoS attacks from which in my opinion a small project is more difficult to defend are used more often.

Do not forget about HTTPS when developing mobile applications.

UPD

You can implement, for example, via a static key, but for this you need to use the HTTPS protocol so that nobody would get it with a simple traffic sniffer.

But a dynamic token is better, for example, obtained when opening an application. Or issue for a while and at the end of the validity period passes re-authorization. The token can be passed in the headers, and you can also in the request parameters.

Enter statistics. For example, where your application is downloading something you add un to the database. then when it is launched, it is tapped into a php script somewhere. in php - make a check if there is an SP in the database that downloaded the application. If there is no ip, then it is either a bot, or someone clumsily climbs to you for these, for such you can add a black list of ips. For the purity of the statistics of bots, it is better to filter;

1. Creating a bot without documentation of your API is very difficult.
2. If you streamline the channel of your mobile application with the server, it is not always possible to get the full API

In such cases I did the following.

1. In the server and in the application did "stitched encryption." That is, all data between the application and the server is encrypted from both sides. - It helps with sniffering protection
2. You can attach your encryption algorithm inside the SSL (https) channel. - It will protect you from reading data from the provider
3. With each request to the server, if your data goes sequentially, change the session key (token) so that your requests cannot be duplicated. - Usually, in order to create interference, they make a copy of the packet sent from the mobile to the server and this packet is sent several times. So the server will work on the empty data. If you frequently change the key (token), then the second request will not be processed.
4. Use EDS or hashing or CRC (EDS - Electronic digital signature. This is done so that no one changes the integrity of the packet (request). A hash value is created from the data and added to the end of the request. The server checks this hash, also by hashing the sent data)