Every software product on the planet seems to have security vulnerabilities. Barebones CMS is no exception. In fact, several security vulnerabilities were specifically programmed into Barebones CMS. This is probably the only product in existence with intentional, known security vulnerabilities built into it from version 1.0 with no plans to ever fix them.
Obviously, this document is absolutely essential to fully locking down a Barebones CMS installation to keep out the bad guys. Reading this carefully will likely save your website from getting hacked. Vulnerabilities are ordered from most severe to least severe.
Barebones CMS assumes that the people working together are trustworthy. It also assumes that HTML is security-clean. This security vulnerability is caused by HTML itself!
As incredulous as it sounds, HTML itself is the security vulnerability, not Barebones CMS! If you want to see this security vulnerability fixed, yell really loud at the W3C Standards body.
Until this security vulnerability is fixed at the Standards-level, there is no way to deal with it other than to be really, super-careful (vetting programmers writing Widgets and Shortcodes that get uploaded) and only use Barebones CMS in environments where you trust the people working with you.
When Barebones CMS is installed, it recommends both installing and running the main CMS through SSL only. Failure to do so opens up the CMS to packet sniffing and replay attacks. This issue is true of any CMS run over HTTP instead of HTTPS.
It is highly recommended that all interactions with the editor be done over SSL. This is especially true when planning to use the editor on public networks (e.g. Wi-Fi).
Also, you can now easily get a free, valid 1-year SSL certificate that has a root certificate that is baked into every major web browser and OS.
The login system is the weakest entry point of the Barebones CMS. A script kiddie that finds the login system will generally have a lower barrier to entry than through other means (packet sniffing requires sitting on the same network and usually close proximity and all links use security tokens making both generally harder routes). As such, you are encouraged through various means to move it into a more secure location. This procedure is well-documented:
Once logged in, a user can edit any portion of the site under the control of the CMS. Developer accounts are incredibly powerful and can do anything in the system including author PHP code that is executed on the server. Be sure that all Developer accounts use hard to guess usernames and completely random passwords.
If you already have a login system you wish to use for the purpose of logging in and editing content in Barebones CMS, you can integrate your login system into the Barebones CMS login system by creating a 'login_hook.php' file in the same directory as 'login.php'.
Three widgets accompany the baseline Barebones CMS installation. The Code widget is perhaps the most blatant security vulnerability - it lets you enter executable PHP code right inside the browser.
If you never plan on using the Code widget, deleting it is the recommended course of action to significantly reduce the potential attack surface of Barebones CMS.
The Easy Edit feature of the Barebones CMS system can be considered a security vulnerability. Easy Edit is the functionality that puts the "Edit" link in the upper-right corner of the page on the public side of things. The link itself isn't vulnerable but it reveals that every page in the CMS is a potential entry point into the editing interface.
There are several built-in mitigation techniques to minimize the possibility of severe vulnerabilities. Security tokens (aka "nonces") are used extensively - every clickable action requires a unique token. The critical login token 'bbl' is kept as a "HTTP Only" cookie. Some browsers do not keep 'bbl' secret and Barebones will warn the user that their browser is insecure. Even with these measures, it is still theoretically possible to generate a working access token.
To mitigate this issue, it is recommended that a plugin be written that checks for valid IP address ranges. That way, even if a correct login token is guessed, the hacker will still be outside of the valid IP address range to actually get into the system. Of course, this is useless if the editor isn't being run over SSL.
Barebones CMS assumes that the people you work with are trustworthy. If you can't trust the people who will be working within this system, then do not use Barebones CMS. The best way to mitigate this issue is to train users to use the CMS in a responsible fashion.
Part of the Content widget's responsibilities is to display placeholder icons wherever a Shortcode's content would appear. This is to prevent Shortcodes from being a privilege escalation vector from within the editor.
It is highly recommended that Shortcodes always show placeholders for Developer accounts. This significantly reduces the attack surface from within the Preview Frame with Shortcodes. The strictest environments should show placeholders for all account types. Showing placeholders allows for faster Preview Frame reloads as it tends to reload quite frequently. However, placeholders make it more difficult to see what the final content will look like.
Many Shortcodes offer "local" vs. "remote" security options. You may opt to show content hosted locally but not remotely. Content on remote (usually untrusted) servers will get a HTTP "referer" containing the URL of the Preview Frame, which includes a security token. It may be possible to reverse-engineer a Preview Frame security token to create tokens for other commands, but highly unlikely. The remote server would be missing several critical pieces of information. Nonetheless, keep this issue in mind for remotely hosted content in Shortcodes.