First: Invisible UI buttons give no security. Users might inspect the local MiniMongo content or trigger methods directly.

The following security aspects exists in a meteor app

1. Things are published to a client that should not have been published
2. Meteor methods are not hardened against vandalism (illegal inserts / updates / removes, etc.)

So, we want to introduce new E2E tests and simulate usual attack scenarios- and expect them to fail, of course ;-)

I would suggest for every collection and for the workflows E2E tests named:

• Minutes_security.js
• MeetingSeries_security.js
• Workflows_security.js

In these security E2E tests we would check:

• That non-invited/ non-logged in users have no unexpected items published
• That non-invited/ non-logged in users can not insert/update/remove items in non-accessable collections by triggering method calls directly
• Especially the user roles aspect has to be considered: (e.g., it should not be possible to give oneself a user role upgrade for an existing meeting series).