[pointytrees]

In my experience, many tables don't have a userid on the table that would be associated with the user. It would be a table join or two or three away.

So the developer may think it is safe to say select value from stock positions left join account on account.id = stock position.id left join user_accounts on user_accounts.accountid == account.id left join users on user_accounts.userid == user.id where user.id == session.userid.

Safe right? We checked userid. But then clicking on the position to drill in on the position data, they just select * from stock_position where stock_position.id = params.stock_id... there's no "and stock_position.userid" on that table, and the developer might be too lazy to spin up the entire join again especially if you don't need account data for this view. Whoops, suddenly a vulnerable page query.

I imagine there are other ways to screw up. Like insecure cookies, and just checking cookie.userid, ah yes, you're the right user. Whoops, didn't realize cookies could be spoofed.

[scarface74]

If the cookie is spoofed and someone got another clients authorization token, then they would get any documents that user was authorized to see anyway.

But you don’t do cookie.userid.

You send the username and password to an authentication service which generates a token with a checksum. The token along with the username and permission is cached in something like Redis.

On each request, middleware gets the user information back using the token.

[pointytrees]

I'm familiar with that process. I was trying to illustrate a picture of how a poor developer might stumble their way into this situation. It's technically possible to store the userid in the cookie rather than using JWTs, but obviously it's not secure in the slightest.