Security issues with authorization extensions

MediaWiki is not designed to be a CMS, or to protect sensitive data. To the contrary, it was designed to be as open as possible. Thus it does not inherently support full featured, air-tight protection of private content. But with the massive increase of MediaWiki use in corporate intranets and the many CMS-like features emerging, demand for tighter security is emerging.

To help authors of security extensions, this list of the security flaws found in the field is being maintained, so that they can test their extension against each. There are several extensions that claim to give selective read/write access to pages in Category:Page specific user rights extensions, and currently most of these do exhibit several of the listed flaws.

Testing security extensions
If you are going to implement read or write access, check the extension for the flaws listed in the table below by logging in as a user without read/write permissions. It can be very annoying logging in and out between a sysop to change the code, and then as a user without any access rights to test it, so a good idea is to run two different browsers like Firefox and Internet Explorer which each store their own set of cookies. Alternatively, you can use a normal browsing window in Firefox or Chrome and then start a new "private window" or "incognito" session to play the role of an anonymous user for testing. This way you can be logged in as sysop in your usual browser, and be logged in as a "nobody" on your second browser/window at the same time.

Table of common security extension limitations
There are probably more "holes" in the read protection system. So, denying read access should be seen as a "nothing to see here, move along," sort of thing rather than a guarantee of secrecy.