APIs serve as the backbone of modern applications, but without proper security testing, they can expose vulnerabilities that hackers exploit.

This article covers the essential security checks for APIs, providing real-world examples, expected responses, and red flags that indicate security flaws. These tests aren’t exhaustive, but they form a strong baseline for protecting your API.

1. Authentication & Authorization Testing

Authentication verifies who the user is, while authorization determines what they’re allowed to do. If either is weak, attackers can impersonate users or gain access to sensitive data.

✅ Test Case 1: Accessing an API Without Authentication

💡 Scenario: A protected API should require authentication. Test by making an unauthenticated request.

🔹 Request (Without Token)

GET /api/user-groups/44 
Host: example.com

✅ Expected Response (401 Unauthorized)

{
  "error": "Unauthorized",
  "message": "Authentication token required."
}

❌ Wrong Response (Security Risk)

{
  "id": 44,
  "name": "Admin Group",
  "users": []
}

🔴 Issue: The API is returning data without authentication. Fix: Enforce authentication.

✅ Test Case 2: Bypassing Authorization

💡 Scenario: Ensure users cannot access resources they don’t own.

🔹 Request (User A Trying to Access User B’s Data)

GET /api/user/1 
Host: example.com
Authorization: Bearer valid-token-for-user-2

✅ Expected Response (403 Forbidden)

{
  "error": "Forbidden",
  "message": "You do not have permission to access this resource."
}

❌ Wrong Response (Security Risk)

{
  "id": 1024,
  "name": "Admin User",
  "email": "admin@example.com"
}

🔴 Issue: User A should not be able to view User B’s data. Fix: Implement role-based access control (RBAC).

2. Input Validation & Injection Testing

APIs that don’t validate input properly are vulnerable to injection attacks, where malicious code is passed as input. SQL and NoSQL injections remain among the most common and damaging API exploits.

✅ Test Case 3: SQL Injection

💡 Scenario: Test if the API is vulnerable to SQL injection attacks.

🔹 Malicious Request

GET /api/users?id=1' UNION SELECT username, password FROM users--
Host: example.com

✅ Expected Response (400 Bad Request)

{
  "error": "Invalid input",
  "message": "User ID must be a numeric value."
}

❌ Wrong Response (Security Risk)

[
  {
    "id": 1,
    "username": "admin",
    "password": "password123"
  },
  {
    "id": 2,
    "username": "testuser",
    "password": "qwerty"
  }
]

🔴 Issue: The API executed the SQL injection attack and leaked user credentials. This means unsanitized inputs are directly concatenated into SQL queries. A hacker could steal all usernames and passwords using this method.

✅ Test Case 4: NoSQL Injection

💡 Scenario: Test if a NoSQL database (e.g. MongoDB) is vulnerable.

🔹 Malicious Request

{
  "email": { "$ne": null }
}

✅ Expected Response (400 Bad Request)

{
  "error": "Invalid input",
  "message": "Email must be a string."
}

❌ Wrong Response (Security Risk)

[
  {
    "id": 1,
    "email": "user1@example.com"
  },
  {
    "id": 2,
    "email": "admin@example.com"
  }
]

🔴 Issue: API executed the NoSQL query, bypassing authentication. Fix: Use schema validation.

3. Cross-Site Scripting (XSS) & Data Sanitization

Even APIs that don’t render web pages can still enable XSS attacks if they accept untrusted input and return it without sanitization. Attackers may inject malicious scripts that execute when data is displayed in client applications.

✅ Test Case 5: XSS Attack via API Input

💡 Scenario: Ensure the API does not allow storing executable JavaScript.

🔹 Malicious Request

{
  "name": "<script>alert('XSS')</script>"
}

✅ Expected Response (400 Bad Request) OR encoded response

{
  "error": "Invalid input",
  "message": "Name contains prohibited characters."
}
OR

{
  "id": 68,
  "name": "<script>alert('XSS')</script>",
  "users": []
}

❌ Wrong Response (Security Risk)

{
  "id": 68,
  "name": "<script>alert('XSS')</script>"
}

🔴 Issue: API stored and returned malicious JavaScript. Fix: Sanitize input and escape output or encode response

4. Rate Limiting & Throttling

Without request throttling, attackers can brute force login endpoints, scrape data, or overwhelm servers with denial-of-service attempts. Rate limiting ensures fair usage and protects critical endpoints.

✅ Test Case 6: Brute Force Login Attack

💡 Scenario: Test if API limits repeated login attempts.

🔹 Request (Multiple Attempts)

POST /api/login
{
  "email": "user@example.com",
  "password": "wrongpassword"
}

(Repeated 50 times)

✅ Expected Response (429 Too Many Requests)

{
  "error": "Too many requests",
  "message": "Try again later."
}

❌ Wrong Response (Security Risk)

{
  "error": "Invalid credentials"
}

🔴 Issue: API does not block excessive login attempts. Fix: Implement rate limiting.

5. CORS (Cross-Origin Resource Sharing) Security

CORS controls which websites can interact with your API. Misconfigured CORS can let malicious websites make requests on behalf of users, leading to account takeover or data theft.

✅ Test Case 7: Ensuring Proper CORS Policy

💡 Scenario: Check if API allows requests from untrusted origins.

🔹 Request (From Malicious Domain)

GET /api/user-info
Origin: http://malicious-site.com

✅ Expected Response (CORS Blocked)

Access to fetch at 'https://example.com/api/user-info' from origin 'http://malicious-site.com' has been blocked by CORS policy.

❌ Wrong Response (Security Risk)

200 OK
Access-Control-Allow-Origin: *

🔴 Issue: API allows all origins (*), making it vulnerable. Fix: Restrict CORS to trusted domains.

Conclusion

Security testing for APIs is critical in preventing data breaches and ensuring safe access to services. The tests above cover some of the most common and high-risk vulnerabilities.

💡 Best Practices for API Security

• Use JWT or OAuth2 for secure authentication.
• Validate & sanitize all user inputs.
• Implement role-based access control (RBAC).
• Use parameterized queries to prevent SQL injection.
• Limit API request rates to prevent brute force attacks.
• Enable logging & monitoring for security incidents.

🔐 Securing APIs is a continuous process. It’s not enough to test once—you need to build security into every stage of your development lifecycle.

At Trailhead Technology Partners, we’ve helped organizations across industries secure and modernize their applications. Whether you need a security audit, penetration testing, or guidance integrating best practices into your CI/CD pipeline, our team can help you identify vulnerabilities before attackers do.

👉 If you’d like expert help ensuring your APIs are secure and future-ready, get in touch with us at Trailhead Technology Partners.