A curated set of progressively harder API security challenges: endpoint discovery, BOLA, broken auth, excessive data exposure, mass assignment, rate limit bypass. The API Security course final.
This capstone brings together everything you have learned about API security. Four progressive challenges simulate real-world attack paths from endpoint discovery through to privilege escalation, testing your ability to find and exploit common API vulnerabilities.
The OWASP API Security Top 10 is the industry standard checklist for API security. Unlike web application vulnerabilities that often require complex chaining, API flaws are frequently business-logic bugs — the endpoint works exactly as coded, but the developer forgot to check ownership, filter the response, or protect a hidden endpoint. This review walks through the four most common API vulnerabilities from the OWASP Top 10.
Challenge 1 combines endpoint discovery with BOLA. You will find a hidden /admin/api/users endpoint and exploit a missing ownership check to access another user's data. Challenge 2 covers broken authentication: a token leaked in a URL parameter that you can intercept and replay. Challenge 3 demonstrates excessive data exposure: a verbose API endpoint that returns PII fields that the client does not need. Challenge 4 is mass assignment: sending an extra field in a PATCH request that escalates your role to admin.
Click each challenge to read the scenario, then use the request builder to craft your exploit. Try to capture all four flags.
No requests yet.
Unlike buffer overflows or SQL injection, most API vulnerabilities are simple oversights in business logic. The developer adds a new endpoint, copies a pattern from another endpoint, but forgets to add the ownership check. Or they return the entire database row to save time writing a DTO. Or they bind request body fields directly to the model without an allowlist. These are not exotic bugs — they happen every day in every organisation that builds APIs.
The OWASP API Security Top 10 exists because traditional web scanners miss these flaws. A scanner can find SQL injection, but it cannot tell whether /api/orders/123 returns order 123 because the authenticated user owns it or because the developer forgot to check. These vulnerabilities require human understanding of the application's authorisation model. That is why API security must be a continuous practice — every new endpoint is a new attack surface that must be manually reviewed.
For BOLA, the fix is always the same: compare the owner of the requested resource against the authenticated user. Use a parameterised user ID from the session, not from the URL or request body. For broken authentication, never pass tokens in URL parameters — use the Authorisation header or a secure httpOnly cookie, and enforce a short token expiry. For excessive data exposure, never return the full database entity from an API endpoint. Write a projection (a DTO or a GraphQL resolver) that returns only the fields the client needs.
// FIX BOLA — check ownership against session
app.get('/api/users/:id', (req, res) => {
const sessionUser = req.session.userId; // from session, not from URL
const requestedId = parseInt(req.params.id);
if (sessionUser !== requestedId) {
return res.status(403).json({ error: 'forbidden' });
}
// ...
});
// FIX Excessive Data — projection / DTO
function toUserDTO(user: User): UserDTO {
return {
id: user.id,
name: user.name,
email: user.email,
// deliberate: no SSN, no credit score
};
}
// FIX Mass Assignment — allowlist fields
const ALLOWED_PATCH = new Set(['name', 'email', 'avatar']);
app.patch('/api/profile', (req, res) => {
const update: Record<string, unknown> = {};
for (const key of Object.keys(req.body)) {
if (ALLOWED_PATCH.has(key)) update[key] = req.body[key];
}
// update only allowed fields
});For mass assignment, never use a library function that binds the entire request body to a model (e.g. User.update(req.body)). Instead, explicitly define an allowlist of fields that can be updated. This applies to both JSON and form-encoded bodies. The OWASP API Security Top 10 is not a one-time checklist — it is a living document that should be reviewed with every new feature release.
1.Which vulnerability occurs when an API endpoint binds the entire request body to a database model without filtering fields?
2.What is the root cause of Broken Object Level Authorisation (BOLA)?
3.Why are traditional web vulnerability scanners ineffective at finding most API security flaws?