if you only do md5, you usually add something like appkey when you md5, or salt, is not passed through parameters (both front and back know the value), so as to prevent others from tampering and constructing the request.

if you do md5 and encryption at the same time, it's OK, just don't pass the key.

add the answer upstairs, focusing on the replay attack.

it is possible to request to be caught by someone else and use it to repeat the request.
so the design idea is as follows:

first of all, all schemes should have an agreed secret key when encrypting. Ensure that attackers cannot calculate sign by themselves

scenario A: verify whether md5 has been requested

so that each request has a unique md5, server that writes the md5 to the cache after the request is completed for the first time.
check whether there is a md5, before processing the request next time. If so, it means that the request is repeated.

but did you think that there is a disadvantage here:
every request has to write a md5 into the cache. If the number of requests is relatively large, it takes up a lot of cache

scenario B: add a timestamp to the parameter

if the time difference is more than 60s, it means that the request was grabbed by someone else and used as a repeat request attack.

this scheme also has its drawbacks:
client-side and server-side time consistency requirements are relatively high.

Ultimate solution: combine the two.

timestamp + md5
1. Time difference of more than 120s represents repeat request
2 and md5 write cache. Cache duration is 120s (greater than or equal to the above value). Judge if md5 represents repeat request

this solves the problem of repeated requests relatively well.

actually I am concerned about the effect of the non-sorting of parameters. It is not more convenient to use the submitted data directly. After all, security is reflected on appkey