Slide 16 of 28
Part 3 · Attack ScenariosSlide 16
Slide 16 · Scenario 3
The API accepted DELETE on a read-only endpoint. The attacker deleted all user records.
OWASP Scenario #3 — unnecessary HTTP methods enabled, triggering unintended behavior.
📄 OWASP API Security Top 10 · 2023 · API8 · Scenario 3
SETUP
A user management API where only GET should be permitted on the collection endpoint.

An admin API has an endpoint at /api/v1/users. The intended behavior: GET /api/v1/users returns a list of users (admin-only). No other methods were intentionally implemented on this endpoint.

The web framework automatically maps HTTP methods to controller methods. A developer had defined a deleteAll() method in the controller during development as a testing utility. The method was never exposed in the documentation — but the framework routes DELETE /api/v1/users to it because the method exists.

The exploit: A security researcher (or attacker) runs an OPTIONS request: OPTIONS /api/v1/users. The server responds with Allow: GET, DELETE, OPTIONS — advertising all accepted methods. The attacker sends DELETE /api/v1/users. The framework routes it to deleteAll(). All user records are deleted. The delete method has no authorization check because it was never meant to be in production.
OPTIONS as a reconnaissance tool

The HTTP OPTIONS method is designed to report which methods a server accepts on an endpoint. Attackers routinely send OPTIONS requests to API endpoints as a first reconnaissance step — it’s a free map of what the endpoint can do. Disabling OPTIONS (or not returning the Allow header) is a defense; restricting endpoints to only the methods they need is the fix.

← Back The common pattern →