Slide 16 of 28
Part 3 · Attack ScenariosSlide 16
Slide 16 · Scenario 3
Blocked. Then unblocked. By the person who was blocked.
OWASP Scenario #3 — a user resets their own content moderation status.
📄 OWASP API Security Top 10 · 2023 · API3 · Scenario 3
SETUP
A social media platform's video moderation.

A social media platform flags videos for content moderation review. Flagged videos get a property set in the database: "blocked": true. They don't appear publicly until a moderator reviews and approves them.

Users can edit their videos — title, description, tags — via the same PUT endpoint. The developer didn't restrict which fields users can update.

The exploit: A user whose video was blocked sends a PUT request to update their video's description. They add "blocked": false to the request body. The API accepts the field and writes it. The video is now unblocked and publicly visible — without any moderator action. The content that was flagged for removal is live again.
Why moderation is a write-side risk

Content moderation flags (blocked, suspended, under_review, removed) are administrative properties. They must only be settable by the platform — not by the users whose content is being moderated. Without a strict allowlist on the video update endpoint, every moderation action can be reversed by the person being moderated.

← Back What do all these have in common? →