4 ms·

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 li

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.

deleted 5y ago
[deleted]
bni 5y ago
In my experience very few have storage layer separation for customers data. It all logic in the application layer to control access. Do you mean stuff like row-level security in the database tables?
corroclaro 5y ago
Cached data in middle layers can get even the safest of row-level secured databases. I agree in general that you need to enforce things at the storage layer.
- diveanon 5y ago
  You're right, and cache policy issues can be really hard to debug. As a rule I don't cache personal information for this reason. Out of curiosity do you have any knowledge on GDPR's stance on caching PI?
jablan 5y ago
How would any measures at storage layer prevent, for example, issues in caching?
- mewpmewp2 5y ago
  And how can one enforce it on a storage layer? There must be something in the application that determines user identity, which either threading, flawed logic, bug or caching (most likely) can mess up. In which case storage layer gets this identity information from application layer.
mewpmewp2 5y ago
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.
- diveanon 5y ago
  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.

deleted 5y ago

[deleted]

bni 5y ago

In my experience very few have storage layer separation for customers data. It all logic in the application layer to control access. Do you mean stuff like row-level security in the database tables?

corroclaro 5y ago

Cached data in middle layers can get even the safest of row-level secured databases. I agree in general that you need to enforce things at the storage layer.

diveanon 5y ago
You're right, and cache policy issues can be really hard to debug. As a rule I don't cache personal information for this reason. Out of curiosity do you have any knowledge on GDPR's stance on caching PI?

jablan 5y ago

How would any measures at storage layer prevent, for example, issues in caching?

mewpmewp2 5y ago
And how can one enforce it on a storage layer? There must be something in the application that determines user identity, which either threading, flawed logic, bug or caching (most likely) can mess up. In which case storage layer gets this identity information from application layer.

mewpmewp2 5y ago

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.

diveanon 5y ago
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.