1

I am writing a web service for research and learning purposes and try to find an approach to separate user data from other users to ensure a request can never deliver or reveal data from another user.

I give you an example in a slightly different field. Imagine an HTML form whose inputs will be written into a database. There is the browser logic which can ensure the data is valid. Then the script accepting the connection can revalidate the data as well, and often databases have their own constraints. So there are 3 levels to ensure no spoiled or incorrect data makes it into the database.

Back to my initial problem. Imagine a database with user text messages. In a naive/plain database model, there would be a user and messages table where each message has a user_id. A SQL JOIN would be the naive solution, but that is way to error-prone in my opinion.

Would it be OK to create an entire database for each user to separate the data even more? Would that be enough? How do modern web services separate data?

FYI: The text message example is just an example. Of course I know about end-to-end encryption. But for my web service this is not necessary to go that far.

tripleee
  • 159
  • 1
  • 10
Daniel Stephens
  • 121
  • 10
  • 1
    Why do you consider a join error prone? – JacquesB Jun 01 '20 at 21:05
  • I should have clarified it. Because it is easy during year-long development cycles to make an error or mistake here. It doesn't add a seperate abstraction/seperation layer – Daniel Stephens Jun 01 '20 at 21:35
  • 1
    Separate databases does provide a layer of isolation, but is also going to be lot more complex when creating new users, schema changes etc. And you probably also have some data that is shared across all users, so you need to perform queries against multiple databases. In general I don't think it would be worth the added complexity. – JacquesB Jun 02 '20 at 06:50

0 Answers0