Set a special User Agent before calling it in the app, such as "My own app". When the program starts, check the User Agent sent by the browser. If it is not "My own app", an error will be reported directly.
But if you meet an expert, they can forge User Agent at will. As long as they intercept the communication between your App and your server, they can know what kind of User Agent you use, and then forge a follower in the browser. Just the exact same string you requested will do.
Get the current time and then add salt and encrypt it, send it to the server for parsing through url or ua, compare the parsed time with the server time, and throw away any time that exceeds 1 minute. In this way, even if someone else forges ua, they can only use it for 1 minute and then forge a new ua.
The ultimate solution is that @markov said to enable two-way authentication of https on the server side. To be simpler, you can also use the app to generate a verification code and pass it to the server as an http header. The server will get the verification code, decrypt it and verify it.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
It can only be said to be partially prohibited.
Set a special User Agent before calling it in the app, such as "My own app". When the program starts, check the User Agent sent by the browser. If it is not "My own app", an error will be reported directly.
But if you meet an expert, they can forge User Agent at will. As long as they intercept the communication between your App and your server, they can know what kind of User Agent you use, and then forge a follower in the browser. Just the exact same string you requested will do.
Get the current time and then add salt and encrypt it, send it to the server for parsing through url or ua, compare the parsed time with the server time, and throw away any time that exceeds 1 minute. In this way, even if someone else forges ua, they can only use it for 1 minute and then forge a new ua.
https client authentication
If you use the http interface, you might as well add a layer of authentication logic;
Or use a non-http interface, so that the web side cannot call it
The ultimate solution is that @markov said to enable two-way authentication of https on the server side.
To be simpler, you can also use the app to generate a verification code and pass it to the server as an http header. The server will get the verification code, decrypt it and verify it.