JavaScript-How to prevent third-party Web sites from calling back-end interfaces

For sites with a completely detached front and back end, the backend uses Php/java/python to output JSON-formatted data to the front-end, while the front end invokes the interface via AJAX to fetch the data. In this case, the backend interface if not taken a certain amount of protection is very easy to be used by other people malicious to do some illegal operation. So, what is the mainstream approach to back-end interface protection in this completely decoupled site architecture?

Reply content:

For sites with a completely detached front and back end, the backend uses Php/java/python to output JSON-formatted data to the front-end, while the front end invokes the interface via AJAX to fetch the data. In this case, the backend interface if not taken a certain amount of protection is very easy to be used by other people malicious to do some illegal operation. So, what is the mainstream approach to back-end interface protection in this completely decoupled site architecture?

1) to give you the API user authentication key, the requested data content in accordance with the rules defined by the two parties to encode the key, the back end to the request after decoding the checksum is expected, and set the frequency of access to each key ~ ~
Content does not meet the expected direct rejection response
Access is too frequent, then this user is not allowed to access within a certain time ~ ~ ~

2) also can issue SSH private key/public key way to guarantee ~ ~ ~

Use Access-Control-Allow-Origin the header and CSRF token to control it.
Some need to limit the number of times will also be added in the headers X-RateLimit-Limit and X-RateLimit-Remaining to control access

At the moment my idea is to limit the frequency of operations to control, because no matter what you do, the Chrome plugin development script The little Prince can always use your user experience needs to bypass all restrictions.

It is also recommended that you open the API permissions to control the good, such as

http://api.xxx.com/customer/user/get?id=12345

Do not design this API as a random change of ID to be able to query all user information, in the filter to the incoming ID and the session in the maintenance of the login user information to verify the authentication.

If this page is designed to be viewed as a static page that does not require a user to log in, then I would recommend that you do not use the scenario to implement this page. Because it's hard to do seq and CDN

Give you a simple scenario: Determine whether the request source is Ajax, and if not, reject the request. Then the request from Ajax can be counted, and if the unit time request is too frequent, the request is forbidden (this will arbitrarily block the case of a large company behind an IP).

In the case of Ajax, you simply cannot tell if the other person is asking for a malicious request because it is likely that it really comes from your own page.

Do a token verification. In front of the backend to invoke the back-end interface, send an encrypted token come on the line

It's usually token, and there's the source ... That would kill a piece of it.

It is most important to do a good job of back-end verification.
The data passed can be added with JS, can slightly increase the difficulty of grasping the bag

I've been thinking about it lately.

Try OAuth Validation

Back end no record session, how to get data?

Later, I thought about a bit, some are not very sensitive data, do not need to log on to load, if it is sensitive data need to be logged in to the user before the asynchronous call.

Verification code, session, limit IP These are all things you can do ...

What you see is what you get, no way.

The stateless nature of the HTTP protocol determines that it is not possible to completely avoid third-party calls to your backend services. The previous methods have certain functions, including CRSF, interface call frequency, user behavior analysis and so on in some aspects, can only increase the difficulty of third-party calls.

12306 site is the best example.

Login data can be used session, if you do not need to log in, you can use the parameter key time authentication.

 test.php?a=1&b=2&time=12345678&code=xxxx

XXXX is the authentication code, simple point can be used MD5 (A1B2TIME12345678PASSWD), that is, the parameter list, plus the current time, plus the password. You can use multiple passwords, that is, a client one password, each client sends a AppID, which adds a parameter,

`test.php?appid=1&a=1&b=2&time=12345678&code=xxxx`，

This allows you to modify a client's password at any time, or discard a client request.

Illegal access is usually solved using authentication, many Session,oauth and so on.
There is often a limit to the frequency and number of visits to legitimate authenticated access, and various API frameworks are supported, such as Django Restframework throttling.
For denial-of-service access, it is often necessary to do more control at the front end, such as configuring rate limit on Nginx.

Refer to each large open interface, do a token verification, each request must be validated. Will not be arbitrarily called.

HTTP requests support authentication, using base auth to authenticate access. Or use OAUTH2 to authenticate the request.

LZ can refer to the next JS interface

