5 ms·

This is how I’ve been making sure multitenancy in my app doesn’t leak data. It shouldn’t leak but how can I be sure? Run tests that try to access data on one te

by dqv 5y ago

This is how I’ve been making sure multitenancy in my app doesn’t leak data. It shouldn’t leak but how can I be sure? Run tests that try to access data on one tenant from another tenant and fail if the data is accessible.

eb0la 5y ago
Most of the time we make tests when something is in our radar. I guess you have use case in your spec that tells you that's the expected behaviour, or at least some clever developer figured out it should be done that way. But it is not always so "easy": Sometimes you don't have the domain knowledge, or the spec doesn't say a word about negative cases...
onion2k 5y ago
Run tests that try to access data on one tenant from another tenant and fail if the data is accessible. That tells you that the method your tests use to try to access data don't work, not that it's impossible to access data across tenants. If there's a leak you haven't tested for then your app is still insecure. It'd be better to think of a design that actually makes it impossible (assuming that's even possible for your scenario).
- brabel 5y ago
  Exactly. Sometimes, good design is still the only real way of making sure something works or is secure. It's a bit like using a type system (though that's by all means not the only way) to ensure invariants.
  - necovek 5y ago
    Agreed: tests only test for discrete "points" of the input space (even with things like hypothesis testing and randomized input testing), and in general, in pure TDD, it is sufficient to test for one each of the class of points (eg. only one negative case to ensure negative part of the code is triggered). But we should not forget we are all working against legacy code bases and libraries outside our control, and sometimes, tests might be the best available tool for achieving something other than their primary purpose, which I'd happily accept as a fun hack.
- dqv 5y ago
  I think it's well-designed, but I would definitely want someone to go over it and look for any obvious issues if I made it public. I wanted it to be annoying as possible to do something outside of the tenant context and it is definitely annoying. Absent an explicit flag to disable tenancy for a specific operation, the operation will fail, raising an exception that the tenant id was not set. This is mostly enforced at the database interface right now i.e. the interface ensures that a tenant id is present in the query. Then in the database itself, null values for the tenant id aren't allowed. I also have a test that runs over every table and ensures there is a tenant id column except for those that are explicitly listed in the test as not needing a tenant id. I also have it set up to not expose the tenant id to the user at all, instead opting for a "public id" with limited utility and only used where needed.

by dqv 5y ago

eb0la 5y ago

Most of the time we make tests when something is in our radar. I guess you have use case in your spec that tells you that's the expected behaviour, or at least some clever developer figured out it should be done that way. But it is not always so "easy": Sometimes you don't have the domain knowledge, or the spec doesn't say a word about negative cases...

onion2k 5y ago

Run tests that try to access data on one tenant from another tenant and fail if the data is accessible. That tells you that the method your tests use to try to access data don't work, not that it's impossible to access data across tenants. If there's a leak you haven't tested for then your app is still insecure. It'd be better to think of a design that actually makes it impossible (assuming that's even possible for your scenario).

brabel 5y ago
Exactly. Sometimes, good design is still the only real way of making sure something works or is secure. It's a bit like using a type system (though that's by all means not the only way) to ensure invariants.
- necovek 5y ago
  Agreed: tests only test for discrete "points" of the input space (even with things like hypothesis testing and randomized input testing), and in general, in pure TDD, it is sufficient to test for one each of the class of points (eg. only one negative case to ensure negative part of the code is triggered). But we should not forget we are all working against legacy code bases and libraries outside our control, and sometimes, tests might be the best available tool for achieving something other than their primary purpose, which I'd happily accept as a fun hack.
dqv 5y ago
I think it's well-designed, but I would definitely want someone to go over it and look for any obvious issues if I made it public. I wanted it to be annoying as possible to do something outside of the tenant context and it is definitely annoying. Absent an explicit flag to disable tenancy for a specific operation, the operation will fail, raising an exception that the tenant id was not set. This is mostly enforced at the database interface right now i.e. the interface ensures that a tenant id is present in the query. Then in the database itself, null values for the tenant id aren't allowed. I also have a test that runs over every table and ensures there is a tenant id column except for those that are explicitly listed in the test as not needing a tenant id. I also have it set up to not expose the tenant id to the user at all, instead opting for a "public id" with limited utility and only used where needed.