This is an incomplete list of things you should consider when you want to prevent your users being attacked by others.
Note this is about protecting individual consumers with username/password pairs, rather than application clients such as third-party companies, who normally carry AppKey/AppSecret pairs.
Authentication
There are several options.
Sending username/password as http request parameters every time an API is called. In this case you should,
1. POST rather than GET. A password in URL can be more easily exposed
2. HTTPS has to be used to prevent eavesdropping.
Basic Authentication: Sending username/password as http headers every time an API is called. In this case, make sure to use HTTPS to ensure privacy.
Authentication based on cookies or session tokens : The user "login" for once, then the client application receives a cookie or a session token, and send it along with the request every time an API is called. In this case you should,
1. POST rather than GET
2. Use HTTPS to protect password when calling Login API if possible. However, you may be confident to think that this can rarely happen since the password is transferred in clear text for only once.
3. Use HTTPS to secure the cookies or session tokens in requests after login
Attach a password-based signature with every API request. This is useful if you can’t set up HTTPS.
1. Encrypt every http request with the consumer’s password as encryption key, get a signature, and send the signature along with requests.
2. The server side will do the same encryption on receiving requests and see if the result matches the signature.
Privacy of Sensitive Information in Request and Response
1. Always prefer POST to GET
2. Use HTTPS if possible
Data Integrity
If HTTPS has been used, data integrity won’t be breached. An attacker cannot modify encrypted text.
If HTTPS has not been used, then you must use the password-based-signature authentication mentioned above. It is also safe in terms of data integrity, since the modified request won’t match the original signature.
Replay Attack
If HTTPS has been used, a man-in-the-middle reply attack won’t work. The HTTPS protocol has some handshake and MAC trick to prevent this.
However, you still need to choose POST over GET, to reduce the chance that a user mistakenly send the whole request URL to the attacker.
If no HTTPS is used and you have the password-based-signature authentication mentioned above, a repay attack can be easily performed. In this case, you need to insert a timestamp in the request and use it to construct the signature, the server side should check if the timestamp is close to current time. However, it won’t work very well if the replay happens very soon. You will also need to provide a clock synchronization API.
The other choice is to introduce a "One-Time Submission Token", just like the token used in websites to prevent duplicate form submission. You request the token first by calling a special API and then use this token to call your biz api.