I'm looking into implementing an ownership check on JSON objects and want to avoid going back to the database to ensure ownership of said object/record (i.e., to prevent a user from updating an object/record they do not own - mostly CRUD operations). This would occur in the context of a web-application/service api.
My thought is to have a private server-side system assigned "ownership" v4 UUID tied to every user record, so that when passing any user owned JSON object to the view, the system encrypts the owner's private "ownership" UUID using bcrypt with a random salt and assigns it to the object/record (where it could be persisted along with the record for caching purposes so it does not have to be re-encrypted). Also, I should note it's possible that owned objects may be encrypted separately each with their it's own random generated salt, even though they are in fact the same user's ownership UUID (this is needed to help prevent tracking of user's object ownership in certain application use cases).
Later, if a user tries to update said object, the server would have to validate their private UUID against the bcrypt hash to ensure if they have the ownership rights to update the record.
This is assuming that I would encrypt using an appropriate number of rounds for the encryption. Another assumption I'm making is the encryption and checking time would outweighs any database check times. The last assumption to point out is this strictly an app security check and would do nothing if someone actually got a hold of the database.
My current thinking is that with the UUID being random and it's large string size (along with an appropriate number of rounds) would make having these bcrypt hashes exposed publicly not be so much of a problem. Or is this approach just too much risk/oversight?