Document the correct way to manage collections to avoid security problems

[ZeroAurora]

Storing all related documents inside a shared collection like in a traditional database could lead to serious security problems.

Take the first steps docs as an example, when storing all tasks inside /buckets/todo/collections/tasks, one could easily broadcast their tasks (or worse, spam and fraud messages) to all users in this application without prior user consent. All they need to do is setting the permission to read: system.Everyone.

Properly create collections for shared tasks could resolve this problem. For example, one could create a collection with a generated name for each share group, and add proper r/w permissions on it.

This should be documented in order to pervent misusage. And it should be noted that even if this method is adopted, server managers should also be care of possible CC attacks (by bulk-creating collections).

I discovered this when submitting a security report to an other similar project. It has a basically same permission system while not allowing users to create seperate collections, resulting in a broken system on which you can't build literally any application. I may write a full writeup later on this.

[leplatrem]

Thanks for taking the time to report this issue.

If I understand correctly, what you highlight here is that if an application uses on a single collection for all its users (relying on user permissions isolation for records), then someone could intentially make their records public and they would show up on everyone screens.

This definitely deserves to be clarified in the docs 👌

[ZeroAurora]

Exactly! This security measure must be taken on all collaboration-focused applications, like wikis, shared todos and more.

And for applications that store data per user, the use of the default bucket should be encouraged.