This document is very much a work-in-progress. Most of our internal practices and requirements are not yet written down publicly, but are employed during the development of Review Board and are checked during review.
We have the following built-in mechanisms used for access control checks in Review Board:
Most types of data in Review Board connects to a repository, review group, or Local Site, directly or indirectly. It’s crucial that access is always carefully checked. If a user is not, for example, a member of a private Local Site, they must not be allowed to access any content on it.
Most models contain utility methods for checking a user’s access (is_accessible_by() and is_mutable_by()), and many model managers have functions for performing access-aware queries (though they may expect some checks to be performed first — check the relevant documentation).
If you are writing any new code (such as API code) that in any way is sensitive to access control, you must write unit tests that thoroughly cover the different combinations of access control checks, to ensure code is not written that may result in a data leak. Be paranoid about this.