Inventory API endpoint discloses whether users own assets

The https://inventory.roblox.com/v1/users/{userId}/items/{itemType}/{itemId} endpoint discloses whether users own particular assets. Includes game assets, bundles, gamepasses, catalog items, etc.

I was able to use the endpoint to find game assets which are meant to remain secret until released.

You could also use the endpoint to create a list of who owns what items, since Roblox has now restricted the endpoint designed to do that: https://inventory.roblox.com/v2/assets/{assetId}/owners?sortOrder=Asc&limit=10.

7 Likes

How could this be used to find secret assets when you need the asset ID for this?

2 Likes

I wrote a python script to go over tens of thousands of recent assetIds on a specific userId to find what assets they owned and then checked them all individually (with their permission). It can be scaled up pretty easily this was from my mediocre pc.

2 Likes

I’m very sure MarketplaceService:PlayerOwnsAsset uses this endpoint so removing it would result in broken functionality in numerous games. This would also break certain external integrations like ClanLabs which allow you to automate actions based on asset ownership.
Perhaps you have a more reasonable change in mind?

2 Likes

That marketplace API uses https://api.roblox.com/ownership/hasasset?userId={userId}&assetId={assetId} which should also be restricted.

Both APIs should respect my inventory privacy settings when set to something restricted. They should return false unless my privacy settings are set to everyone, or the asset is owned by the game owner (group or user).

If this is not backwards compatible then a new API should be implemented which can only be used from the game server on users in the place.

The idea is to decrease the ROI (time and effort invested to get the desired outcome). It is currently possible to use both endpoints unauthenticated with no rate limits in place. If you had to force someone to join your game first then the ROI dramatically decreases, especially if rate limits are implemented.

I’m fairly certain this is unintended behaviour. Unfortunately changing this may break third party integrations, but I don’t want people being able to see the assets I own if my privacy settings are explicitly set to NoOne.

4 Likes

You can easily loop through all catalog items and send requests to this endpoint to uncover all of a user’s items, It’s a vulnerability because it discloses data the user has chosen not to make public.

1 Like

Thanks for the report! We’ve filed a ticket to our internal database and we’ll follow up here when we have an update for you.

1 Like

I am in the process of checking over bug reports and following up on some bugs that haven’t received any activity in a while.
Is this issue still occurring or can you confirm that this bug has been resolved? I am having a hard time reproducing this issue.

1 Like

This is still occurring.
Both “/v1/users/{userId}/items/{itemType}/{itemTargetId}” and “/v1/users/{userId}/items/{itemType}/{itemTargetId}/is-owned” ignore the inventory privacy settings of the user and returns whether the user owns the item or not.

While api.roblox.com will eventually be removed, I think it is worth mentioning that “api.roblox.com/ownership/hasasset?userId={userId}&assetId={assetId}” also ignores the privacy settings.

1 Like

I think the endpoints should be restricted by Trust Levels, or expand the inventory capabilities of AvatarEditorService, allowing the request AssetTypes such as images, meshes, audio, etc

There’s some practical uses for the is-owned endpoint such as:

  1. Checking if the player owns a gear.
  1. Checking if the player owns a badge
  • You may want to reward a loyal player by giving them a special item for playing your previous games.
  • You may want to reward a player for achieving badges in other games.
  1. Checking if the player owns game-merch on the website
  • Awarding the player for buying your shirts, pants, UGC pertaining to the game

Hopefully an InventoryService or some other solution comes in to play when these are restricted.

1 Like