API Security Lab

Vulnerable Mode

A simulated REST console. Fire requests at intentionally-broken endpoints, then flip to Secure mode to see authentication, object-level authorization, role checks and rate limiting enforced. All accounts and data are fictional and local.

Request console

Method Endpoint

Request headers (JSON) Request body (JSON)

No token stored. In secure mode most endpoints need an Authorization header.

Response

response.json

Send a request to see the response…

Request history

No requests yet.

Guided scenarios

One-click demos for each issue

1 · Broken Authentication

An endpoint that issues a token without checking the password.

2 · BOLA / IDOR

Read another user's private record with no ownership check.

3 · Excessive Permissions (RBAC)

A normal user reaching admin-only data.

4 · Missing Rate Limiting

Fire 13 rapid requests and watch for 429s.

5 · API Key Exposure

Why keys belong on the server, validated server-side.

Sample endpoints

GET /api/users · GET /api/users/{id}
POST /api/login · GET /api/profile
GET /api/admin/metrics · GET /api/ping

Learn

What are these vulnerabilities?

They're the most common API flaws: trusting the client's claimed identity (broken auth), missing per-object checks (BOLA/IDOR), missing role checks (excessive permissions), no throttling (missing rate limiting), and secrets shipped to the browser (API-key exposure).

How do they work?

Each vulnerable endpoint simply omits a check: it returns any record, skips the role test, never counts requests, or trusts an X-User-Id header. Attackers enumerate IDs, replay requests, and read secrets from page source.

Secure implementation

Verify credentials and issue signed tokens; derive identity from the token, not client input; check that the caller owns (or may access) each object; enforce roles; rate-limit per client; and keep keys server-side, exposing only a validation result.

How to prevent them

Centralize auth middleware, default-deny authorization, validate object ownership on every request, add rate limiting at the gateway, and store secrets in server-side environment variables — never in frontend JavaScript.

Key takeaway

The server must decide who you are and what you may touch — on every request. Never trust the client.