←back to thread

475 points danielstocks | 2 comments | | HN request time: 0s | source
Show context
diveanon ◴[] No.27301440[source]
If you rely on your application layer to enforce data privacy instead of enforcing it in your storage layer its just a matter of time until you have an issue like this.

It says a lot about the security of their api and development culture that they are even struggling with something like this. This should be caught in the first architecture review session.

replies(5): >>27301492 #>>27301550 #>>27301568 #>>27301587 #>>27301735 #
1. mewpmewp2 ◴[] No.27301735[source]
Out of curiosity, how is that enforcement usually done? I have usually just used some SQL database like MySQL/Postgres, and having application determine how to fetch data, so application has access to everything. I can see how this could be insecure due to some bug in application code fetching with wrong WHERE etc, how would one go about enforcing it on sql/database layer?

Would you have separate SQL credentials for each user, and configure SQL for each credential to have access to certain WHERE queries, or?

To simplify a use-case let's say I have "users" table and "tasks" table, where there's user_id in "tasks". Would I have separate sql credentials where they are configured in sql layer to have access to only rows where user_id corresponds to this certain credential? But even then how are credentials mapped to userId, as bug in application could easily cause retrieving false credentials?

Other way I can think of is to just have completely separate databases for each user, but let's in this case assume we must often do work with a mix of different users data.

replies(1): >>27302811 #
2. diveanon ◴[] No.27302811[source]
So I think the best place to start is looking into row-level security in Postgres. Its a familiar place to start and gives a high return. Row level security can be used to implement the user / tasks use case you described.