there is no good way, because any trust credential that can be sent to the client can be obtained after the attacker gets the client source code.

even the construction of private protocols and encryption are powerless when there is client source code.

if you rely on the client version or other trust credentials that require the cooperation of the client, the attacker can do the next source code for the second time. From this point of view, the attacker is a legitimate client, and you have no way to distinguish it. After all, it's a public network client, and it can't be done by adding a whitelist.

HTTP can be constructed at will.

this problem is a cost problem, that is, you can only judge that a session interface is an illegal call when it is accessed frequently. As for how to define this frequency, you can only define it according to the frequency of normal users.

so this is like anti-crawling, all you can do is to "judge whether it is a normal user's operation".

speaking, in the case of Mini Program, it is estimated that the IP blacklist does not work very well, because the mobile IP is easy to become, in case it is mistakenly sealed (such as public wifi).

the above is limited to my current knowledge, maybe there are bosses who will have a good solution.

It is almost impossible for the
1. interface to be completely unaccessed, especially if you can already fully understand how you normally access it.
2. APIs that need to be protected are generally in session state, that is, you need to "log in" to obtain token. In this way, the front-end security problem becomes the acquisition, transmission and preservation of token, which narrows the scope
.