Bug: game_id in URL does not impact access to game state so long as player_id is valid

[khushal-winner]

Describe the bug
Broken Access Control (IDOR - Insecure Direct Object Reference) in Phoenix LiveView route /games/:game_id/players/:id.

The :game_id parameter from the URL is completely ignored in the socket handle_params/3. The code fetches the player by :id only, then loads the game using player.game_id instead of verifying the URL-provided game_id. This allows any user to view any player's full game state (cards, hand, status, etc.) by forging the game_id part of the URL while keeping a valid player_id.

Steps to Reproduce

1. Open a player view page, for example:
   /games/01KJQJAR0B57E96P7YJBDCEVYG/players/01KJQJBZGWBQBEKFYE7AMZ01S0
2. Copy the full URL and change only the game_id segment to any random/invalid string, e.g.:
   /games/999999999999999999/players/01KJQJBZGWBQBEKFYE7AMZ01S0
3. Load the modified URL in the same browser/session.
4. Observe that the page loads successfully and displays the correct player data, including:
   • Full hand/cards
   • Player status
   • Game-specific state
     (despite the game_id in the URL being completely wrong/forged)

Video Demo

2026-03-05.03-34-40.mp4

Expected behavior
When a user visits /games/:game_id/players/:id, the application must verify that the provided :game_id exactly matches the game_id associated with that player_id in the database. If they do not match, the socket should return a 404 Not Found, redirect to a safe page, or show an access denied message.

Desktop (please complete the following information):

• OS: any (Windows / macOS / Linux / iPadOS etc.)
• Browser: any modern browser (Chrome, Firefox, Safari, Edge)
• Version: any recent version

Additional context

• Reproducible by changing only the game_id segment in the URL → same player data/cards still load correctly
• Only basic rate limiting appears to be present

[khushal-winner]

@sydseter , found another very interesting bug, would love to work on this ASAP :))

[rewtd]

Hey @khushal-winner you don't actually need a player ID at all to view the game state.

Also: the player ID uniquely identifies the hand you can play. So although it's linked to the game ID it doesn't matter that this isn't enforced. To be clear:

• you can't take on a player's hand without knowing their unique Player ID, and
• you can't view the game state of any game without knowing: either that game's ID or being a player in that game by knowing the player ID

[khushal-winner]

u're right @rewtd , but this should still be fixed even if player_id acts as a secret. The current setup is a classic IDOR vulnerability because the user-controlled game_id in the URL is completely ignored, violating defense-in-depth and least-privilege principles.
fixing this won't creates any mess in the future as the game features develop, can i fix it anyway this as a good security practise if u assign me?

[rewtd]

It's not classic IDOR because the user-controlled game_id is irrelevant to the game actually referenced, the only secret required is the player_id. The URI as https://copi.owasp.org/games/<game_id>/players/<player_id> is by convention and so that it makes more sense for humans (I am player X in game Y) but the game_id does nothing from an IAM perspective.

But, given that the URI https://copi.owasp.org/games/players/<player_id> isn't considered valid, it makes sense to ensure that the player_id passed is actually a valid player for the given game_id. Thus correcting the issue you've found.

[sydseter]

@khushal-winner Thank you so much for your contributions and the time you use on the project.
Also thank to you @rewtd for taking the time and looking through the issues reported while I am oncthe OWASP Summit. I really appreciate it.

I am not sure we should fix this. I understand the motivation, but being able to enter based on player id is actually a handy feature that can make the url shorter and not a vulnerability. I will review the work, but I can not promise that I will merge it. @khushal-winner I am very sorry about this as I know it is crucial for you to deliver work in order to be considered for gsoc. Still, I don’t want to add complexity by fixing something that isn’t broken.

[khushal-winner]

@sydester , don't worry when someone takes multiple shots, some will hit the target and some will miss. I won't take this PR rejection to my heart. instead, I'll keep delivering work, making more shots, and growing from every PR (merged or not). I know how crucial consistent contributions are for gsoc, and I'm committed to improving as a coder and as a person.

Thanks again for the thoughtful review and for explaining your reasoning :)) & thanks to @rewtd too.