Common API Security Measures and Their Implementation

Introduction

Recently I needed to expose an API with a public domain that handles transaction orders, so security is critical. This article summarizes common security measures and how to implement them.

Security Measures

Security can be divided into protecting data in transit and protecting the server side from attacks.

Ensuring data confidentiality during transmission.

Ensuring the server can identify and protect incoming data.

1. Data Encryption

Plain HTTP is vulnerable; use HTTPS (SSL/TLS) to encrypt data. Critical fields such as passwords can also be hashed (e.g., MD5).

2. Data Signing

Generate an unforgeable string (signature) on the client side, usually via MD5, to detect tampering, especially for internal service calls.

3. Timestamp Mechanism

Include a timestamp in each request; the server checks that the difference between its current time and the client timestamp is within an allowed window (e.g., 5 minutes) to reject replay attacks.

4. AppId Mechanism

Require callers to obtain an AppId and secret key; each request includes both for authentication.

5. Rate Limiting

Limit the number of requests per AppId using algorithms such as token bucket or leaky bucket.

6. Blacklist

Block AppIds that have performed illegal operations.

7. Data Validation

Validate input data for format, length, type, and business rules before processing.

Implementation Details

Encryption can use symmetric (DES, AES) and asymmetric (RSA) algorithms. Java provides utility classes for both.

Data Signing Example

str: param1={param1}&param2={param2}&...&paramN={paramN}$key={userSecret};
MD5.encrypt(str);

Timestamp Verification Pseudocode

long interval = 5*60*1000; // 5 minutes
long clientTime = request.getParameter("clientTime");
long serverTime = System.currentTimeMillis();
if (serverTime - clientTime > interval) {
    return new Response("Request timed out");
}

AppId Generation Guidelines

Generate a unique AppId with random characters; ensure it is monotonic for indexing and non‑sequential for security. Snowflake‑style IDs are common.

Rate Limiting Algorithms

Fixed Window Counter

Count requests within a fixed time window (e.g., 10 requests per minute) and reject when the limit is exceeded.

Sliding Window Counter

Divide the window into smaller slots (e.g., 10‑second intervals) and slide the window to achieve smoother limiting.

Leaky Bucket

Model request processing as water leaking from a bucket; excess requests are dropped when the bucket overflows.

Token Bucket

Tokens are added to a bucket at a fixed rate; a request proceeds only when a token is available.

Guava’s RateLimiter implements a token‑bucket limiter:

RateLimiter rateLimiter = RateLimiter.create(5); // permits 5 requests per second

For distributed rate limiting, combine Redis with Lua scripts.

Conclusion

The article lists common API security mechanisms: encryption, signing, timestamp, AppId, rate limiting, blacklist, and data validation, and provides brief implementation guidance.