Developing user groups securely

The following page is about the secure development of user groups.

1. Turn on “Class permission is not modified by field permission”
   If this improvement step is not enabled a user that has no class-permission for a given class, may be given permission to records of the class anyway if they have field-permission to it. Even though only the permitted field is visible, it still allows this user to see more than the developer may have intended. If this property is enabled, the class-permission will remain 'No', even if a field permission is granted. The property 'Permitted fields only' can then be used to determine if all fields, or only permitted fields should be visible.
2. Always configure class permissions properly
   Imagine a user without search permission for a given class, but the read permissions haven't been explicitely configured to 'No'. If the user is somehow able to access records of the class (for instance a public velocity script), they can bypass their search permission to read every record of the class, if the read permission wasn't configured properly.
3. User groups and permissions
   Keep permissions inspectable. Inspect them regularly. Don't make super groups because it is easy. Work from the principle: a user is not allowed to do anything, unless specifically permitted to, not the other way around.
4. Property ‘Two factor frequency for login’
   Make usergroups with wide permissions use two factors to log in (for instance super groups). Determine explicitely if they can use e-mail as second factor. The risk of using e-mail as a second factor is that some users use the same password for their e-mail account and the application. If this password falls in the wrong hands, they immediately gain access to both the e-mail account and the application account. If you expect your users to use the same password for both accounts, consider a different second factor.
5. Session life time and keep alive
   User sessions are automatically extended whenever the client contacts the server with a request. A session is cleaned up when no more contact is being established. The 'Session life time' property determines how long it takes before a session is cleaned up. A short life time is safer, but it runs the risk of logging out users during activities on the application. A long life time may mean the session stays active for too long, introducing security risks. As an alternative the property 'Use keep alive' can be enabled. This makes its so a session is kept alive, even during inactivity, as long as the browser remains active. Consider this when there are users writing long texts in the application.
6. IP restrictions
   It's possible to only allow users of certain usergroups access to the application if they are using one of a number of pre-determined IP-addresses. Consider using this option for users who have access to confidential information. IP-addresses can be faked however, so this restriction is not airtight!
7. Query persistency (Coming soon)
   This property determines what user groups are allowed to do concerning queries. Use this in combination with the permissions of the query to control what queries are open and editable.