Bug Report: Inconsistent access rules and bugs in public vs. private production API endpoints (api vs. apiz) for private profiles of mutual friends

[bcansiz74]

Describe the Bug

Currently, there are critical inconsistencies and bugs when interacting with private user profiles via the public production API (api.trakt.tv) versus the official/private production API (apiz.trakt.tv).

When User A and User B are mutual friends (meaning they follow each other, and the relationship is verified under User A's /following list and /friends endpoint), but User B's profile is set to Private:

1. Several endpoints on the private/official API (apiz.trakt.tv) return empty [] arrays or 403 Forbidden responses despite the established friendship.
2. Conversely, there is a privacy leak on both APIs where some endpoints (like favorites and watchlist) return full datasets even if the requesting user is not following the private profile owner.

---

Identified Discrepancies

1. Mutual Friend's Data returning empty [] or 403 (Bugs)

Despite the confirmed friendship, several authenticated requests using User A's OAuth token on User B's (userb) private profile fail to return data depending on the target API:

• Watched History (/history):
  • GET https://api.trakt.tv/users/userb/history (Public API) works correctly and returns history data.
  • GET https://apiz.trakt.tv/users/userb/history (Private/Official API) incorrectly returns an empty array [].
• Followers / Following (/followers, /following):
  • GET https://api.trakt.tv/users/userb/following (Public API) returns [].
  • GET https://apiz.trakt.tv/users/userb/following (Private/Official API) returns [].
  • Note: GET /users/userb/friends works properly on both.
• Compatibility Score (/match):
  • GET https://apiz.trakt.tv/v3/users/userb/match (Private/Official API) returns a 403 Forbidden error with the body User profile is private.

2. Private Data fully exposed to non-followers (Privacy Leak)

• Favorites & Watchlist (/favorites, /watchlist):
  • GET https://apiz.trakt.tv/users/userb/favorites/media and GET https://apiz.trakt.tv/users/userb/watchlist return the full lists, even when the profile is private and the requesting user is not an approved follower or friend. This leak happens on both api.trakt.tv and apiz.trakt.tv endpoints.

3. List Privacy Setting Inconsistencies

When testing the privacy configuration of custom lists via /lists on both APIs:

• GET https://api.trakt.tv/users/userb/lists
• GET https://apiz.trakt.tv/users/userb/lists

The following behavior is observed:

• Private (private): Correctly hidden from everyone, returning [] on both APIs (Working as expected).
• Friends (friends): Incorrectly hidden from everyone, returning [] even for mutual friends. Even if User A and User B are verified friends, User A still receives [] instead of the list contents (Broken behavior).
• Public (public): Correctly visible to everyone (Working as expected).

4. Working as Expected (No Issues)

• Comments & Ratings (/comments, /ratings):
  • These endpoints correctly protect User B's privacy. They return data if User A is an approved follower/friend, and return 401 otherwise.

---

Expected Behavior

1. Since User A is a mutual friend (approved follower) of User B, User A's authenticated OAuth token should be able to fetch User B's watched history, following/followers lists, and calculate the compatibility score (/match) across both public (api.trakt.tv) and private/official (apiz.trakt.tv) production endpoints.
2. For privacy consistency, favorites and watchlist endpoints should return 403 Forbidden / User profile is private to any user who is not a friend or approved follower of the private profile owner.
3. Setting a list's privacy to friends should allow mutual friends to fetch the list contents while blocking non-followers.

[vladjerca]

Thanks for the detailed report @bcansiz74 , this was really useful 🙏🏼

I've confirmed the root cause. The inconsistencies come down to private-profile access rules being applied unevenly, in two opposite directions: some data was too restrictive (approved followers/friends were blocked as if they were the public), while a couple of endpoints were too permissive.

I pushed a fix a few minutes ago, will close this issue once I have confirmation of things working on your end as well 👌🏼

[bcansiz74]

Hi @vladjerca,

Thanks for the response and for working on a fix! 🙏🏼

I ran another comprehensive test matrix across both domains (api.trakt.tv and apiz.trakt.tv) covering various edge cases (Public/Private profiles, No Relation, Follower Only, Mutual Friends).

While some of the previous issues appear fixed, a few critical inconsistencies and privacy leaks still persist (mainly around list privacy enforcement, stats aggregations, and how private accounts are handled inside social graphs).

Here is what I found during the re-test:

---

1. Critical Privacy Leak: Friends-Only Lists (privacy: friends) exposed to Non-Friends

This is the most critical issue remaining.

When User B has a custom list configured with privacy: friends:

• Scenario (Only Follower): User A follows User B, but User B does NOT follow User A (No mutual friendship established).

• Observed Behavior:

• GET /users/userb/lists incorrectly exposes the friends-only list in the response array.

• GET /users/userb/lists/{list_slug}/items returns all items instead of blocking access or returning an empty array.

• Impact: Non-friends can still read friends-only list contents. It seems the access control logic checks if User A follows User B, instead of verifying a mutual friendship (User A follows User B AND User B follows User A).

---

2. Stats API Mismatch (/stats vs. Actual Endpoints)

The GET /users/userb/stats endpoint returns incorrect counts whenever private profiles are involved in User B's network:

• Scenario (No Relation / Public Profile):

• GET /users/userb/followers returns 2 items (correct).

• GET /users/userb/following returns 3 items (correct).

• GET /users/userb/stats returns: followers: 1, following: 2, friends: 1 (INCORRECT).

• Root Cause Hypothesis: The /stats aggregation/query seems to be applying a strict WHERE is_private = false filter on the target users in the network graph. This causes private accounts to be subtracted from the stats counts, creating a direct discrepancy between what /stats reports and what /followers or /following endpoints actually return.

---

3. Private Accounts Disappearing from /friends

• Scenario: User A and User B are mutual friends. User B also has a mutual friendship with User C, whose account is set to Private.

• Observed Behavior:

• User C correctly appears under User B's /followers and /following endpoints (tagged as private).

• However, User C is completely omitted from GET /users/userb/friends (it returns 1 friend instead of 2).

• Impact: Profile privacy setting (is_private) shouldn't erase an existing friendship edge from the social graph endpoints. If two users are mutual friends, they should both appear in /friends, regardless of whether one of their profiles is private.

---

Summary Table

Endpoint / Feature	Condition	Expected	Observed	Status
Friends List Privacy	Non-mutual follower requests privacy: friends list	[] or 403	Returns full list & items	❌ Leak
Network Stats	Private profiles present in user's network	Exact count matching /followers & /following	Stats count is lower than actual returned items	❌ Mismatch
/friends Endpoint	Friend's account is Private	Include friend in response	Omitted completely from /friends	❌ Bug

---

Could you please double-check these specific access control conditions and SQL/query filters?

[vladjerca]

@bcansiz74 I believe I found the root cause for the last 3 issues you mentioned and should be all fixed (keep in mind stats might take up to 24 hours to propagate).

I will close this issue as I believe the bulk of the initial report has been addressed. If there are any more issues please feel free to open a new issue 😀

Thanks again for the great report!