Klarna users are being signed in to random accounts

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.

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?

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.

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

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.

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.

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.

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?