IDOR lets any user delete others' photos and albums

A photo and album deletion endpoint on Pornhub acted on whatever object ID was supplied in the request without checking who owned it - one parameter swap was all it took to permanently delete anyone else's media.

The Target

Pornhub's user content platform - specifically the functionality that allows authenticated users to manage their uploaded photo albums and individual photos. Users can create albums, upload images, and delete their own media through API endpoints that accept a content identifier.

The Vulnerability

The bug was an Insecure Direct Object Reference (IDOR) on a destructive operation - a delete endpoint. When a user requested deletion of an album or photo, the endpoint accepted the object's identifier from the request and performed the deletion. The server did not verify that the authenticated user owned the object identified.

In permission model terms: imagine a Linux rm command that ignores file ownership and lets any user delete any file by name. The access control check - "does the requesting user own this object?" - was missing entirely from the delete code path.

This class of IDOR is particularly severe because the operation is irreversible. Read IDORs expose data; delete IDORs destroy it permanently.

How It Was Found

The researcher created two separate Pornhub accounts - a standard approach for testing authorization: Account A (the attacker) and Account B (the victim). They uploaded photos and created albums under Account B, noted the object IDs, and then while authenticated as Account A, sent delete requests substituting Account B's object IDs.

An illustrative pair of requests demonstrating the IDOR:

# Legitimate delete - Account A deletes its own album
DELETE /api/album/delete HTTP/1.1
Host: www.pornhub.com
Cookie: session=ACCOUNT_A_SESSION
Content-Type: application/json
 
{"album_id": "12345"}

# IDOR exploit - Account A deletes Account B's album
DELETE /api/album/delete HTTP/1.1
Host: www.pornhub.com
Cookie: session=ACCOUNT_A_SESSION
Content-Type: application/json
 
{"album_id": "67890"}

The second request succeeded: Account B's album was deleted even though Account A had no ownership over it. The same pattern applied to individual photo deletions.

Impact

• Any authenticated user could permanently delete the albums and photos of any other user by enumerating or guessing object IDs.
• For content creators on the platform, this represents the irreversible destruction of their work - uploaded media, album organization, and associated metadata.
• Object IDs in web applications are frequently sequential integers or short identifiers, making bulk enumeration and mass deletion a realistic threat.
• Pornhub awarded $1,500 for the report, appropriate for a medium-severity IDOR with destructive but not data-exfiltration consequences.

The Fix

Preventing IDOR on delete (and all mutation) operations requires server-side ownership verification:

1. Always look up who owns the object before acting on it. Before processing a deletion, the server must query the database to confirm object.owner_id == authenticated_user_id.
2. Derive the owner context from the server-side session, not from request parameters. The user ID must come from the validated session token, never from a client-supplied field.
3. Apply the same authorization check on every verb - GET, POST, PUT, PATCH, DELETE. Developers sometimes add ownership checks on reads but forget them on writes and deletes.
4. Return a consistent error for unauthorized access. The server should return 403 Forbidden (or 404 Not Found to avoid leaking object existence) rather than processing the request, regardless of whether the object exists.
5. Use unpredictable identifiers. UUIDs (version 4) instead of sequential integers make enumeration attacks significantly harder, though they are not a substitute for proper authorization checks.

What You Can Learn

• Authorization must be checked on every operation, not just reads. Many IDOR fixes focus on protecting data from being read, but delete and update operations need exactly the same ownership verification.
• Destructive IDORs cause irreversible harm. A read IDOR leaks data that already existed; a delete IDOR destroys data that cannot be recovered. The impact asymmetry is significant.
• Two-account testing is the standard methodology. Create two test accounts, perform an action on object A with session A, then replay with session B substituting A's object ID. If it succeeds, you have an IDOR.
• Object IDs should not be trusted. The presence of an object ID in a request is not authorization - it is merely knowledge of an identifier. Knowledge is not ownership.
• This mirrors Linux file permissions. A correctly configured Linux system uses st_uid (owner UID) to prevent users from deleting each other's files. The application-layer equivalent is checking the owner_id column before every destructive database operation.