Lesson 8 of 15

API Security Testing

Modern web applications rely heavily on APIs, which introduce their own unique set of security challenges distinct from traditional web vulnerabilities. You will learn how to discover, map, and test REST and GraphQL APIs for authentication flaws, excessive data exposure, and injection vulnerabilities. API security testing is one of the fastest-growing areas of web application penetration testing.

Learning Objectives — Deep Dive

Each objective below is broken down into plain English so you know exactly what you are learning, why it matters, and what you will be able to do when you are done. Mark each one complete as you work through the lesson.

0/4

In plain English

This is asking you to build a clear mental model of the concept — not just memorize a definition, but genuinely understand what it means, why it exists, and how it connects to everything else you are learning. When you can explain "REST API security testing methodology" in your own words to someone who has never heard of it, you have truly learned it.

Why this matters

This objective builds a foundational skill that every security professional uses regularly. Mastering it gives you the vocabulary, mental models, and practical ability to tackle more advanced topics with confidence — and to communicate clearly with both technical and non-technical colleagues.

Real-world analogy

Think of it like learning to drive. You do not need to understand how the engine works to drive safely, but knowing the basics helps you diagnose problems and avoid mistakes that could cause accidents. The same principle applies here — foundational knowledge prevents costly errors.

What you will be able to do

Apply this skill in a real lab environment, explain it clearly to a colleague or client, and use it as a building block for the more advanced techniques that come later in this course.

Beginner tip

Do not try to memorize everything at once. Read through the material once to get the big picture, then go back and work through the lab. The hands-on practice is what makes the concepts stick — passive reading alone will not get you there.

API Security Testing · Objective 1 of 4

VIDEO

Loading video…

Find API documentation

Navigate to common API documentation paths on the target: /api/docs, /swagger, /swagger-ui.html, /openapi.json, /api/v1/docs, and /redoc. Swagger UI and OpenAPI specifications are frequently left exposed on production servers, providing a complete map of all API endpoints, parameters, authentication requirements, and expected responses. If no documentation is found at common paths, check the application's JavaScript source files for API endpoint strings using browser developer tools or 'grep -r api src/'. Undocumented APIs are not necessarily secure — they are just harder to find.

Map all API endpoints

Use the discovered documentation or Burp Suite's Spider/Crawler to build a complete inventory of all API endpoints. For each endpoint, record the HTTP method, path, required parameters, authentication requirement, and the type of data it returns or accepts. Pay particular attention to endpoints that accept object IDs as parameters (IDOR candidates), endpoints that return lists of resources (potential data exposure), and endpoints that perform privileged actions (authorization testing targets). A thorough endpoint map is the foundation of a systematic API security assessment.

Test for BOLA

Broken Object Level Authorization (BOLA) is the API equivalent of IDOR and is the most common API vulnerability. For each endpoint that accepts an object ID, test whether you can access objects belonging to other users by substituting their IDs. Use Burp Suite's Intruder to iterate through a range of IDs (1 through 1000) and compare response lengths — a consistent response length for a range of IDs indicates the server is returning data for all of them regardless of ownership. Document any endpoint where you can access another user's data as a Critical or High severity finding.

Test rate limiting

Send rapid repeated requests to authentication endpoints (login, password reset, OTP verification) and check whether the server enforces any rate limiting or account lockout. Use Burp Suite's Intruder with a null payload set and 100 iterations to send 100 login attempts in quick succession. If all 100 requests return the same response without any throttling, 429 Too Many Requests responses, or CAPTCHA challenges, the endpoint lacks rate limiting and is vulnerable to brute force. Also test rate limiting on resource-intensive endpoints such as search and report generation, which can be abused for denial-of-service attacks.

Previous: Security Misconfigurations Next Lesson