How to Prevent Malicious API Abuse: Firewalls, Captchas, Authentication, IP Whitelists, Encryption, Rate Limiting, Monitoring, and Gateways

Preface : During interviews, candidates are often asked how to prevent malicious API calls. This article explores a variety of defensive measures to help protect your interfaces.

1. Firewall

A firewall is a fundamental network security device used to block unauthorized access and attacks.

Firewalls can prevent the following types of attacks:

Invalid packets : Filters out malformed IP addresses, forged packets, and unrecognizable protocols.

DOS and DDOS attacks : Detects and blocks large numbers of TCP/UDP connections, applies IP filtering and traffic limits.

Virus and worm attacks : Uses signature, behavior, and pattern detection to stop malware propagation.

Phishing and spoofing attacks : Prevents fake login pages and deceptive websites.

Malicious traffic attacks : Filters packets with malicious payloads and blocks exploited ports.

Network reconnaissance attacks : Stops scanning, port probing, and vulnerability exploitation.

Overall, firewalls filter and control network traffic to protect network security.

2. Captcha

For critical interfaces, consider the risk of malicious users repeatedly calling the API.

Early user‑registration interfaces used graphic captchas, where users entered a username, password, and the captcha image. Simple captchas can be cracked by brute‑force tools, so additional distortion is added to increase difficulty.

However, overly complex captchas inconvenience legitimate users and raise registration costs, so relying solely on graphic captchas is insufficient.

Modern solutions include sliding‑puzzle captchas, which provide higher security. Captchas are also widely used for SMS‑sending features, which are typically billed per message (e.g., ¥0.1 per SMS). Unrestricted SMS APIs can lead to costly abuse.

3. Authentication

Some public APIs require users to be logged in before they can be accessed.

The system checks the current user context: if the user is logged in, user information is present; otherwise it is null.

For sensitive operations such as order approval, only accounts with the appropriate permission can access the endpoint.

Implement custom permission annotations and use a gateway interceptor to match the requester's permissions with the required permission point before allowing access.

4. IP Whitelist

Critical foundational APIs (e.g., a membership‑system "open membership" endpoint) may be protected by an IP whitelist.

The whitelist can be stored in a dynamic configuration service like Apollo, and later persisted to a database if the list grows.

Only requests originating from whitelisted IPs are allowed; others are rejected, even if the endpoint URL and parameters are leaked.

Internal service‑to‑service calls using Feign and internal domain names can bypass the need for an IP whitelist.

5. Data Encryption

Many legacy APIs use plain HTTP, which suffers from three fatal issues: clear‑text transmission, lack of identity verification, and no integrity protection.

HTTPS adds encryption, authentication, and integrity checks on top of HTTP, using SSL/TLS. For security, prefer HTTPS over HTTP wherever possible.

6. Rate Limiting

Beyond captcha verification, SMS‑sending APIs need server‑side rate limiting.

A typical approach is to create a SMS‑log table (id, type, content, phone number, send time, etc.). When a request arrives, the system checks the most recent send time for that phone number.

If no prior record exists, send the SMS. If the last send was more than 60 seconds ago, send a new SMS; otherwise, reject the request with a "too frequent" message.

This still leaves a loophole: a user can send one SMS every 60 seconds, resulting in up to 1,440 messages per day per phone number, or far more if multiple numbers are used.

Therefore, also limit the total number of SMS messages per phone number per day (e.g., max 10). Redis can be used to store a daily counter with a 24‑hour TTL, checking the count before sending.

The complete validation flow for the SMS‑sending API is illustrated in the accompanying diagram.

7. Monitoring

Monitoring API call patterns is essential to detect malicious usage.

Log each request, aggregate statistics, and trigger alerts (SMS or email) when traffic spikes are detected. Alerts enable timely investigation and possible manual intervention.

8. Gateway

Deploy a unified API gateway to enforce filtering, authentication, and rate limiting centrally.

All client requests pass through the gateway before reaching the actual service.

Having an API‑gateway layer protects the underlying services.

Backend‑Exclusive Tech Group
We welcome developers, technical recruiters, and anyone willing to share job referrals to join our high‑quality technical community.
Maintain civility and focus on
technical exchange
,
job referrals
, and
industry discussion
.
Advertisements are prohibited; avoid private scams.
Contact me to be added to the group.