So, how secure is Tuskfish CMS?

I honestly can't say. Web development is a blood sport¹. You can reduce risk and mitigate impact through various practices and through testing, but there is no magical way to eliminate all bugs. What I can do is tell you about the measures that I have taken to reduce security risks. These may suggest aspects of Tuskfish that you may wish to personally review.

But your ultimate safety net is to have a time series of backups, that you have tested.

Single admin system

There’s only one super admin in Tuskfish and that’s you². Recently, support was (reluctantly) added for trusted content editors/creators, ie. staff. There is no public user rights management system to worry about; they don’t have any.

Explicitly minimised attack surface

The Tuskfish code base is deliberately as small as possible. Most of the Tuskfish code lives outside the web root (ie. outside of public_html) where it cannot be directly accessed by browser.

Tuskfish explicitly avoids use of third party libraries as far as is practical, as they will inevitably contain their own collection of bugs and vulnerabilities³. The libraries that Tuskfish does use on the front end are listed in the project Bill of Materials.

On the backend Tuskfish also uses a few libraries and plugins to enhance the data entry form:

• TinyMCE, to provide a WYSIWYG editor in the HTML teaser and description fields. 
• Bootstrap-datepicker plugin, which provides the calendar widget for the date field.
• Bootstrap-fileinput plugin, which provides the file upload widget for the image and media fields.

Individual themes may come bundled with additional Javascript used by its designer for front end presentation, but I try to avoid these. Having looked at a few it seems that front end designers are not concerned at all about the security of scripts they ship in demo themes.

Rigorous multi-level validation

Tuskfish components do not trust one another. Every public-facing script and public or protected method independently validates its own parameters (with respect to the context it operates in), so a validation error in one component is unlikely to provide leverage against others. This results in a fair bit of redundant validation, but this is a design choice.

Validation is conducted against standardised methods provided as traits that you can incorporate into any class.

Prepared statements and bound parameters

Database queries are exclusively made using prepared statements with bound parameters (PDO) to guard against SQL injection. Parameters are never directly used in a query, they are always inserted via a placeholder. Identifiers are validated as well.

Strict type definition

Strict type definition (available as of PHP 7.2) is used in method parameters as far as is practicable. Strict return types are not yet in use, but will probably be added at some point.

Slow password hash

Passwords are hashed with PHP's native password_hash() function and the default algorithm (currently Bcrypt). The password_hash() function salts and recursively iterates the hash calculation according to a configurable 'cost' parameter, which is cranked up a bit higher than standard, to resist cracking attempts.

Optional two-factor authentication

Two-factor authentication is available via a Yubikey-generated one time password in Tuskfish 2 (see setup guide). In the event that someone compromises your password (or if they steal your Yubikey) they will not be able to hijack your site, because they need both to login. If you have a Yubikey I encourage you to use this option. I am looking into moving towards webauthn, but it is a very complex beast.

No online password recovery

If someone breaks into your email they can typically discover your online accounts and take control of them by resetting the passwords. But they won’t be able to gain access to your Tuskfish website, because it doesn’t have an automated online password reset system. You can reset the password offline.

Single origin code

With a couple of small exceptions (which I have reviewed) all of the native Tuskfish code has been hand crafted by me. All of it has been through the same careful review and testing procedures. By contrast, most other CMS have dozens or even hundreds of people contributing code and plugins over many years. Consequently, the security of their code tends to be highly variable (especially when it comes to third-party plugins, which are the main issue), whereas mine is just uniformly terrible :-)

What I have not done

• I have not reviewed the external libraries used by Tuskfish (see list above) and have no plans to do so. However, they are mainstream libraries and actively maintained by their respective communities. I do track these projects and will update the libraries that ship with Tuskfish when vulnerabilities are found.
• I do not review the Javascript that comes bundled with Bootstrap themes, although I do point their jQuery and similar dependencies to versions of these libraries that are bundled with Tuskfish. If you adapt a third party Bootstrap theme yourself, be aware that they are often bundled with out of date Javascript libraries and truly awful homebrew mailers, which often contain blatent vulnerabilities, so it's best to point links to versions that you serve and actively maintain yourself (it's very easy to forget about these, especially if they are loaded via CDN).

If you do find a problem

If you do find a security problem please contact me with the details so that I can fix it.

Endnotes

1. Yes, I stole this line. The full quote is Web development is a blood sport. Don't wander onto the field without a helmet. It's from Securing PHP Web Applications by Tricia and William Ballad, although it's well out of date now.

2. If you're wondering why, I spent many years trying to get professional colleagues involved in website management as section editors or contributors. What I discovered was that I had to edit nearly everything they wrote, fix images and reapply consistent styling. They would also fight like pre-schoolers about whose story got to be on top and for how long. Learn from my experience: There is no escaping the need for an editorial process, and editing is best handled in word processors. So, let your contributors write in Word and send you the files for web publishing; you'll have less work to do and get a better result.

3. More code means more errors. More errors means more vulnerabilities. This relationship holds true whether you are the best programmer in the world, or the worst. Realistically I don't have the time or domain expertise to forensically examine other project's code. I also don't want to get caught up in a spiderweb of dependencies or trapped on a security update treadmill, trying to keep tens of libraries patched.