A checklist update
The security checklist is revised and extended

A few years ago I wrote about a security checklist I made to help developers and administrators secure their Ibexa DXP installations. The list has received a major update now.
If you are responsible for the security of an Ibexa DXP installation, I recommend you have a look at the new security checklist. I have reorganised it to make it easier to find what you're looking for, and extended it to include more security enhancements you might want to consider implementing. You'll find new sections on web server, domain and database.
You can read new entries on TLS, HSTS, DNSSEC, domain update protection, and certificate authority authorization, which can all prevent various kinds of attacks. Note also the new password rule since v4.5 which rejects passwords that have been exposed in a public breach. It's a good way to ensure really bad passwords are not used. It won't block existing passwords. It runs only when users create new passwords, so you have nothing to lose by enabling it.
Many pieces of advice remain the same, though:
- Use secure roles and policies. Review them to make sure they do what you want them to. Don't use the Hide convenience feature for access control, it doesn't work like that.
- Secure your secrets. Make sure APP_SECRET and other secrets are not set to default values, and that they are never stored in your version control system, especially not if it's open source. If in doubt, regenerate the secrets.
- Stay up to date. Install software updates. When someone leaves your organisation, revoke their access and regenerate secrets they had access to.
- Don't allow bad passwords. First and foremost, use password rules to ensure passwords are long enough. At least 10 characters, and more is better.
- Guard all entrypoints. It's not just your server that needs securing. Employee computers and phones are potential entrypoints too, especially those of developers and administrators. Make sure updates are installed and passwords are protected. When a device is lost or stolen, assume everything on it is leaked, and change passwords and secrets.
- Educate your users. Everyone from CEOs to admins, developers and end users need at least a basic understanding of the dangers and the solutions. For example, you can add brief information and links to further reading on the user creation form of your site, to explain why your password rules are as they are.
Security is always an ongoing process and a team effort. It's good to assign responsibility, but everyone must be in on it. The proverbial chain is never stronger than its weakest link.