The Complete Guide to API Security|5 Threats and Unbreakable Design After Authentication

 

"It's safe because I'm authenticating with an API key or token."
"Because it is an internal API, it cannot be attacked from the outside."
"I've implemented authentication, and I'll take care of you on the app side."

1. Authentication is only the starting point of security.
   After passing authentication, knowing how many threats there are will change your perception.

1. 5 Threats Coming After Authentication

Threat (1): Authorization Defect (BOLA/IDOR)

This is an issue where authenticated user A can access user B's data.

Examples of breaking
GET /api/invoices/12345
User A can get User B's invoice just by changing his ID.
GET /api/invoices/12346

Countermeasures: For each request, verify on the server side whether this user can really access this resource.

Threat (2): Lack of Rate Limiting

If you keep sending 10,000 requests per second to an authenticated API:

• Service down (DoS)
• Brute force data exploration is possible
• Cost explosion (for cloud APIs)

Threat (3): Lack of Input Validation

If you trust the API input parameters and pass them directly to the DB, it becomes a breeding ground for SQL injection and command injection.

Threat (4): Sensitive Information Response Leakage

json

Example of breaking: returning more information than necessary
{
  "user_id": "123",
  "email": "user@example.com",
  "password_hash": "...", // Don't
  "internal_role": "admin", // Don't
  "api_key": "sk-..." // Absolutely not required
}

Threat (5): Lack of Audit Logs

If you don't record who, when, which API, and with what parameters, it will be impossible to investigate after an incident occurs.

2. Authorization Design: Always Validate Every Request

At the top of OWASP's Top 10 API Security is Broken Object Level Authorization (BOLA).

Safe design points:

• Use UUID instead of DB serial number for resource IDs (making it difficult to guess)
• Be sure to check whether this resource belongs to this user on the server side before accessing
• Framework-agnostic and explicitly implemented at the application layer

3. Implementing Rate Limiting

It is basically implemented in the API Gateway or middleware layer.

Design Points:

• Restrict both per user and per IP
• If you get stuck on the limit, return '429 Too Many Requests' and specify the reason
• Limits are set according to the nature of the API (especially for authentication APIs)

4. Audit Logs: What to Record

Minimum items to include in the API audit log:

• Request time, endpoint, HTTP method
• Authentication User ID
• Client IP address
• Response Code
• Size of the request body (often excluding the main body)
• Processing time

By integrating this with Sentinel and Splunk, it is possible to detect anomalies at the API layer.

5. Anomaly Detection: How to Use APIs Differently

It learns normal API usage patterns and detects deviations.

Examples of anomalous patterns:

• A specific user continuously sends a large number of GET requests in the middle of the night
• Sudden increase in access to endpoints you don't normally use
• API access from geographically unnatural locations

6. Colorkrew Security's Approach

Colorkrew Security provides design review and implementation assistance for API security.

**API security starts with authentication. **
Let's create an "unbreakable design" together, from authorization, rate limiting, audit logs, and anomaly detection.