Implementing API Signature for Secure Backend Communication

In a front‑end/back‑end separated architecture, all client applications (web, app, PC) must call backend APIs, which can be intercepted or forged; therefore an API signature mechanism is required.

The signature scheme adds five mandatory fields to the request header: appId , appSecret , timestamp (valid for 5 minutes), nonce (at least 10 characters to prevent duplicate submissions), and signature .

Signature generation steps:

Collect all dynamic parameters: request header, request URL, request query parameters, and request body.

Store them as key‑value pairs and sort the keys in ascending order.

Concatenate the sorted values into a single string and append the appSecret.

Apply MD5 hashing to the final string to obtain the signature value.

The resulting header looks like appId=xxxx&nonce=xxxx×tamp=xxxx&sign=xxx; all four parameters are required, otherwise the request is rejected.

Implementation uses a custom filter that processes each incoming request:

Validate the presence of required header parameters.

Extract header, URL, query parameters and body, then place them into a sorted map.

Concatenate the map values and compute the MD5 hash to generate the server‑side signature.

Compare the generated signature with the client‑provided one; if they differ, return an error.

Additional security measures include:

Timestamp validation to reject requests older than 10 minutes, preventing hotlinking.

Nonce checking (often stored in Redis) to detect and block duplicate submissions.

In summary, the API signature protects external interfaces from tampering and replay attacks, but it does not encrypt the payload itself; request parameters and responses remain in plain text and can still be intercepted.