Security issues with authorization extensions/ja

MediaWiki is not designed to be a Content Management System (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, 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. Starting a new web browsing session via incognito mode allows for site navigation as an unprivileged user as the software is tested and configured.

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.