Security best practices for your Silverstripe CMS project

Silverstripe prioritises security with a robust process for triaging and patching security vulnerabilities in the core and supported modules. Sometimes attack vectors can’t be resolved in the Silverstripe CMS codebase directly because they rely on project-specific code, configuration, or hosting details.

This post details some of the ways you can protect your website, your users, and your data - and prevent vulnerabilities before they happen.

Note that while this is all about securing your project directly, we’re serious about securing Silverstripe CMS itself as well! If you think you’ve found a vulnerability in Silverstripe CMS, please report it to us so that we can resolve it.

Write secure code

Protecting user accounts

Hosting and configuration

Write secure code

It’s no surprise that most security vulnerabilities in a software project come from the code itself. Sometimes these are in dependencies, but sometimes it’s in project-specific code. This section outlines some best practices for avoiding vulnerabilities in your own code.

Avoid raw SQL

Silverstripe CMS has a powerful ORM which lets you perform database queries at a high level without having to worry too much about the exact SQL syntax being used. Using the ORM allows you to focus on the functionality you’re trying to implement without having to constantly double-check you’re not accidentally introducing SQL injection vulnerabilities. So your first layer of protection against SQL injection attacks is to just use the ORM instead of writing your own custom SQL queries.

There are occasions when using the ORM isn’t suitable, either because you need to do something very specific and need more control, or you’re dealing with a massive amount of data and need more performance than the ORM is giving you.

In those cases, you should use parameterised queries whenever possible, and make sure you’re escaping values in the right way at the right time. There’s a whole section about this in our secure coding documentation.

If you absolutely can’t use the ORM or parameterised queries, you can always manually sanitise values before including them in your SQL—see manual escaping in PHP for details.

Secure your cookies

By default, all cookies in Silverstripe CMS use the “Lax” value for the samesite attribute. This is the value most browsers will use by default if that attribute hasn’t been defined, and provides you with the most flexibility for things like authentication with OAuth.

You might want to set that value to “Strict” instead, depending on your use case and threat model.

Web.dev has a great article on samesite cookies which might help you decide the best configuration for your site.

For more information about cookie configuration settings in Silverstripe CMS see the cookies documentation and the session cookies documentation.

Protect your forms

Forms can be susceptible to Cross-Site Request Forgery (CSRF) attacks. Silverstripe CMS forms have built-in protection against this type of vulnerability, but you should make sure your code takes advantage of it. For example, if you’re submitting a form to a custom action, you may need to manually check if the CSRF token is valid for that form submission. You can learn how to do that in our secure coding documentation.

It can also be a good idea to use rate limiting, especially on forms that perform sensitive functions. The login form has rate limiting enabled by default in Silverstripe CMS. Rate limiting prevents attackers from submitting a form many times very quickly, which is a common way attackers use to try to ‘brute-force’ their way past validation or other protections you might have in place that depend on user input.

See the rate limiting documentation for details.

Protect against XSS attacks

Cross-site scripting (XSS) attacks are a type of vulnerability where an attacker injects malicious code (usually JavaScript) into your website, which will be executed when another user visits the site. For context, this is the most common type of vulnerability that gets reported to us.

The most common way to protect against this type of attack is to never trust any data that comes from a user. Silverstripe CMS allows you to “cast” data before including it in templates, so that any HTML content is escaped (made safe for use) and scripts won’t be executed. See data type and casting and casting in templates for specific details.

You can also escape content when using it directly in your PHP code - see manual escaping in PHP for details.

We also have a whole section about preventing XSS attacks in our secure coding documentation.

While you should do everything you can to prevent XSS attacks from happening, there’s always a chance you miss something. You can mitigate the impact of XSS vulnerabilities by protecting sensitive actions with sudo mode.

Caching

Every website should have some level of caching, but not everything needs to be cached. In fact, caching can reduce security if you’re not careful about what you cache and when.

The easiest way to prevent leaking sensitive data through overly aggressive data is to avoid caching user-specific data. That means if something changes depending on who’s viewing it, don’t cache it.

This includes forms (you don’t want to accidentally cache a partially filled in form!), user profile pages, and similar dynamic content.

If you’re careful, and use good caching keys for partial template caching, you can cache some things that are specific to a given user by including that user’s ID in the cache key.

Have a good permissions model

In a fresh Silverstripe CMS installation, you have two groups of users—administrators and content authors—and the default permissions for a content author might be suitable for your project, but you might also end up giving some users too much control while giving others too little.

A good rule of thumb is to follow the principle of least privilege—that is, each user should only have the permissions required to do what they need to do. A blog author probably shouldn’t be able to configure the access controls for the whole site, for example.

A lot of this comes down to setting good roles and groups in the CMS (see the managing roles and permissions user guide for details)—but this is in the secure code section because you can also define custom permissions and check if a user has specific permissions in your own code. See the permissions documentation for more information.

It's worth pointing out that the file security documentation which goes into detail about how the permissions model interacts with the assets system. There’s a bunch of configuration in there that you should get familiar with and make sure you’ve got things set correctly for your project’s needs.

Protecting user accounts

We can’t force people to stop writing their passwords down on post-it notes and leaving their computers unlocked—but there are some steps we can take to mitigate the fallout when they do.

Multi-Factor Authentication (MFA)

MFA is a way to verify that the person logging into an account is who they say they are—not just someone who found the password on a post-it note. If MFA is enabled, when users log into their account they are prompted to provide a second ‘factor’ of authentication—for example they may be prompted to enter in a code which can be accessed from their mobile device.

silverstripe/mfa is an optional module for Silverstripe CMS that provides MFA functionality.

You can read all about how it works and how to install it in your project in the MFA developer documentation and make sure your users are up to speed with the MFA user help guide.

Manage user sessions

If someone loses their device or if someone gains access to their account somehow, you’ll want to be able to log out their account from that device.

The optional silverstripe/session-manager module lets you see and revoke active sessions for your own account, and gives administrators access to revoke sessions for all users. It’s installed by default when using the installer recipe.

You can learn all about how to set up and configure the session manager in the session manager developer documentation.

After installing this module, you should make sure your users read through the user help guide and understand how to check sessions in their own account.

Strong passwords and protecting logins

A user’s password is the most important piece of information used to access their account, so it’s important that you help your users create strong passwords.

This might mean having specific rules about what a ‘strong’ password is such as being more than some minimum number of characters long.

Some of the configuration Silverstripe CMS offers includes:

Password validation rules (changing slightly in CMS 6!)
Control over the hashing algorithm (blowfish by default but you should determine if this is right for your project)
Option to enforce password expiration after a set time.

Silverstripe CMS also gives you control over a bunch of configuration to help protect your user’s logins:

Options for locking users out after multiple incorrect login attempts
Configure session duration to control how long users can stay logged in for
Only allow users to be logged into a single device at a time
Optionally log users out of all devices whenever they manually log out.

See the passwords documentation and user logins documentation for more about those configuration options.

Also, it hopefully goes without saying, but don’t set the SS_DEFAULT_ADMIN_USERNAME and SS_DEFAULT_ADMIN_PASSWORD environment variables in your production environment. Set up actual accounts in the CMS for each individual user instead.

Hosting and configuration

Some vulnerabilities can be introduced—and mitigated—before any of your project’s code is even run. Here are some settings and best practices you can follow to protect your projects at a hosting and configuration level.

HTTPS—the ‘S’ is for ‘Secure’

When you view a website using the HTTP protocol, anyone who has access to your network (legitimately or otherwise) can see everything you’re doing. That includes any sensitive information you might be submitting to forms. Imagine someone sitting in a cafe and submitting their personal information to your website—you don’t want any random person sharing that cafe’s wifi to be able to see that data.

Using the HTTPS protocol encrypts all information being sent between you and the website, so nobody can see your sensitive information.

You can ensure all connections to your website use the HTTPS protocol either through configuration in your hosting, or with the CanonicalURLMiddleware built into Silverstripe CMS. You can read how to do that in the secure coding documentation.

If your database is networked rather than being on the same physical server as your web host, we also recommend ensuring your database connection is protected with TLS (aka SSL). There are details for how to configure that in the using SSL in database connections documentation.

Protect against host header injection attacks

A host header injection attack is where an attacker sends a request to your website with the ‘Host’ request header set to a website they control, which then gets used in a link on your website or sent from your website e.g. in an email. This can trick users into clicking links that they think go to your website, but actually lead to a malicious website.

Ideally, your hosting will reject invalid host headers. For example Apache allows you to define valid hosts as part of the virtual host configuration, and a Web Application Firewall (WAF) can also be configured to validate the host header.

Silverstripe CMS provides optional configuration of an allow list of valid hosts—and will reject requests if the ‘Host’ header doesn’t match. While you should have appropriate validation at a hosting level, it’s best practice to also configure this in your project.

You can learn how to configure the host name allow list in our secure coding documentation.

Response headers that protect your users

Response headers tell the browser how to treat the information it’s receiving, and range from information about the formatting of the data to instructions that improve your security.

Owasp.org has a useful cheatsheet about various security headers, what they do, and recommendations on how to use them. I strongly recommend reading through that article and deciding which headers to set, and to what values, for each project you’re responsible for.

A couple of things to note specifically for Silverstripe CMS:

The X-Frame-Options header should usually be set to SAMEORIGIN, because the CMS uses iframes to display a preview of your content.
For the same reason, the frame-ancestors directive in your Content-Security-Policy (CSP) should usually be set to 'self'
The CMS currently needs inline JavaScript and CSS to work correctly, so you’ll need to include 'unsafe-inline' in both the script-src and style-src directives for any CSP applied to CMS controllers.
You don’t need to do that for the front-end unless your project (or modules you’ve included) specifically use inline scripts or styles.

While you can set headers in your webserver configuration, I recommend setting them in a middleware in your project’s code or configuration instead. That gives you a lot more flexibility, for example tailoring your CSP rules for front-end vs backend responses.

See the middleware documentation for details about adding headers through middleware, or check out one of these community modules which handle some of the boilerplate logic for you:

You should also get familiar with the built-in middleware for cache headers, and with headers applied to protected files to avoid clashing with or reinventing that functionality.

Web server configuration

Silverstripe CMS generates .htaccess files to provide some configuration for Apache web servers. Some alternatives such as LiteSpeed can use the same configuration, but most can’t.

If you don’t use Apache as your webserver, make sure you’re aware of additional configuration you need to set:

Avoid exposing protected assets
Ensure allowed file types configuration is respected
Handle error messages by serving error pages
Make sure you don’t allow files outside of the public/ directory to be served directly.
Be aware of arbitrary code execution.

Keep up to date!

This is fairly obvious, but it’s important enough to include here: make sure your software is up to date! Security vulnerabilities are a fact of life, and different software will have different schedules for patching them. Make sure you have a good strategy and schedule for managing your updates, both at a project dependency level as well as a hosting level, if you manage your own hosting.

For hosting that means things like your operating system, PHP, your database server (e.g. MySQL), your webserver (e.g. Apache), etc.

For your project dependencies, that means being aware of the Silverstripe CMS release schedule and planning to update your dependencies as soon as you can after a release is made. Particularly relevant for this blog post, the security patch release window is every 3 months in January, April, July, and October; so if we have security patches to release that’s when to expect them.

The one exception to this is if we think a high or critical severity vulnerability has been exploited in the wild, in which case we'll aim to release a patch as soon as practical.

For more details about release schedules for Silverstripe CMS check out the Minor Release Policy, Major Release Policy, and the release roadmap.

Note that your project probably includes community modules which aren’t covered by those policies - have a strategy for checking for security advisories such as running composer audit periodically. And don’t forget about your JavaScript dependencies!

Conclusion

There are a lot of ways that you can protect your users and your information from malicious actors, from code changes to hosting configuration - and I didn’t even get into business policies you can require employees to follow (no passwords on post-its!).

If you don’t have a digital agency right now and want help making sure your website is secure, you can reach out to Silverstripe directly if you’re based in New Zealand. Alternatively, browse the Silverstripe CMS Developer Network and filter by location to find a Silverstripe CMS developer near you.

Categories
Developers

Tags
Best practice

Make a comment