How to Stop Malicious API Calls: 8 Practical Defense Strategies

Introduction

During interviews candidates are often asked how to prevent malicious API calls. This guide presents eight practical defenses, explains the reasoning behind each, and shows concrete implementation details.

1. Firewall

A firewall is a fundamental network security device that blocks unauthorized traffic. It can filter: Invalid packets: drop malformed IPs, forged packets, unknown protocols. DOS and DDOS attacks: limit massive TCP/UDP connections, apply IP filtering and traffic throttling. Virus and worm attacks: use signature, behavior, and pattern detection. Phishing and spoofing attacks: block fake login pages and deceptive sites. Malicious traffic: drop packets carrying malicious payloads or exploit‑prone ports. Network reconnaissance: prevent scans, port probing, and vulnerability exploitation.

The firewall’s role is to filter and control network flow, protecting the system from external threats.

2. Captcha

For critical interfaces (e.g., user registration) a captcha is added to stop automated abuse. Early implementations used simple image captchas, which can be cracked by brute‑force tools. Increasing distortion improves security but harms user experience, raising registration friction.

Modern sliding‑puzzle captchas offer higher security. Captchas are also common for SMS‑based verification, where each SMS costs (e.g., 0.1 CNY). Unrestricted SMS endpoints can lead to expensive abuse.

3. Authentication

Protected APIs require the user to be logged in. The system extracts the user context; if the user object is non‑null, the request proceeds, otherwise it is rejected. For privileged actions (e.g., order approval) a custom permission annotation is added, and a gateway interceptor matches the request’s required permission against the user’s roles before allowing access.

4. IP Whitelist

Critical services such as a membership‑activation API often restrict callers to an IP whitelist. The whitelist can be stored in a dynamic configuration system (e.g., Apollo) or a database for scalability. Only requests from whitelisted IPs succeed; leaked endpoints are useless without a permitted IP. Internal services using Feign and internal DNS can bypass the whitelist because they are not reachable from the public internet.

5. Data Encryption

Traditional HTTP transmits data in clear text, exposing it to eavesdropping, spoofing, and tampering. HTTPS adds SSL/TLS (SSL = Secure Socket Layer, TLS = Transport Layer Security) to provide confidentiality, authentication, and integrity. The recommendation is to use HTTPS for all APIs, following the practice of major tech companies.

6. Rate Limiting

Beyond captchas, the SMS sending endpoint must enforce rate limits. A simple algorithm:

When a request arrives, query the most recent SMS record for the phone number.

If no record exists, send the SMS.

If a record exists and the last send time is more than 60 seconds ago, send a new SMS.

If the interval is less than 60 seconds, reject with “operation too frequent”.

This prevents rapid repeats but still allows a user to send one SMS every minute, yielding up to 1,440 messages per day per number. An attacker with 100 numbers could thus send 144,000 messages daily.

To curb daily abuse, a Redis counter is introduced:

Key = phone number, value = send count, TTL = 24 hours.

Before sending, check if the count exceeds a daily limit (e.g., 10). If exceeded, reject; otherwise, send and increment the counter.

The complete validation flow is illustrated in the accompanying diagram.

7. Monitoring

Logging every request and aggregating the data enables detection of traffic spikes. An automated monitor can send alerts (SMS or email) when abnormal patterns appear, allowing rapid manual intervention.

8. API Gateway

A unified API gateway provides a single entry point that performs filtering, authentication, and rate limiting before forwarding requests to downstream services. The request flow diagram shows how the gateway protects the internal APIs.