Hi Support team,
I have done some tests and found that session token has some potential drawbacks that can cause security and data integrity compromises.
In my tests, I found that a session token can actually be re-used in other web browsers or even on another device. This means, if I get a valid session token string(if the app stores session token locally, it can then be retrieved from local storage)I can use it to call services and do what the account of the sessiontoken has access to. This include the standard services for each collection GET, FIND, UPDATE..etc, by default they are all enabled and can be accessed with session token.
This means user actually have the right to directly interact with the database if they know how to call a service.
This creates big difficulties for implementing data integrity and business logic through the interface we designed. because no matter how you design your interface, if they users get a session token(even if they get their own session token) they can by-pass the interface and directly interact with the db.
e.g. we wouldn't want users to change their 'username' in the 'Users' collection, so we don't create any interface to do that in the app. How ever , with a session token, users can forge the update service of 'Users' collection and do it, suppose they have access rights to their own user record.
To prevent senario like the above, the solution is to Not giving access right to user to the 'Users' collection at all, and built new update service with service code allowing them only update certain fields. This will result in many service code scripts using 'masterKey', if we are serious about data integrity and security.
The improvement suggestion I have is:
a session token should only be used in the HTTPs session or the device and browser for which the it is generated.
This way we make sure that a 'stolen' session token can not be re-used.allow disabling the standard GET, FIND UPDATE etc.. for each collection.
This will allow us to still give users access rights to collections and we will not have to use 'master keys' every time in server code. Because, before using master key to generate a master session token, we still need to verify if the session token provided in the request is valid or not (by sending a mock database request).
It will save jobs if we can use session token directly.Please let me know your feedbacks, and I am also happy a go deeper into the discussion .
Thanks & Regards
Dongzhi