Securing Craft

There are a number of things that should be done to ensure your Craft install is as secure as possible.

Place your craft/ folder above your webroot #

The safest way to ensure that Craft’s PHP files and other sensitive information is not directly accessible over HTTP traffic is to put your entire craft/ folder above your webroot.

If, for whatever reason, you have to put your craft/ folder in webroot, you should ensure that users cannot directly access the contents of any files/folders in the craft/ folder. Craft ships with an .htaccess and a web.config file that denies access, but if you’re using nginx or Apache/IIS isn’t configured to parse .htaccess/web.config files, you’ll need to take extra steps to secure the files.

Install an SSL certificate and enforce it #

If you don’t already have an SSL certificate, talk to your host about how to get one installed. Once you have one in place, you should, at a minimum, enforce that all Control Panel traffic gets sent over SSL. Ideally, front-end traffic should use SSL as well, especially whenever private/sensitive information is being transmitted to/from the server.

Enable all “Purify HTML?” Redactor field settings #

When the “Purify HTML?” Rich Text field setting is enabled, its values will always be run through HTML Purifier on save. That will ensure there is no JavaScript code in the field’s value, preventing potential XSS vulnerabilities that could be used for permission escalation and various other exploits.

Enable CSRF protection #

Craft comes with Cross-Site Request Forgery (CSRF) features baked in. See the Enabling CSRF Protection on how to secure your public-facing forms.

Make sure you’re running a recent version of PHP #

Craft 3 requires PHP 7+. Craft 2 supports PHP 5.3.0 - 7.1.x but recommend 5.6+. PHP 5.5 is officially no longer supported. If at all possible, you should be running PHP 7+.

Keep Craft and all of your installed plugins updated #

All software has bugs. Older software has more bugs. Some bugs are security vulnerabilities. Keep your software updated to have fewer security vulnerabilities.

Check your permissions #

Craft has recommended permissions for its files in the documentation, but you can certainly lock them down more depending on how your server is configured. Here is a handy shell script you can use to configure and set permissions on a per-project basis on *nix based systems.

Review config settings on a per-site basis #

Each of these config settings have security implications and should be reviewed on a per-site basis. Craft ships with reasonable defaults for them, but depending on the site requirements, they can be adjusted to be more secure.

Set security headers for the front-end site #

Your server should be configured to send these security headers:

You can run your domain through a site like to check for recommended header settings.

Other Things to Consider #

While less about actual security and more security-through-obscurity, the following are things you might want to consider if you’re particularly paranoid:

Change your cpTrigger #

The cpTrigger config setting defines the name of the URI segment that points to the Control Panel. Changing it to a custom word will make it a little harder for visitors to find your Control Panel’s login page.

Remove the X-Powered-By header #

If you don’t want tools like BuiltWith and Wappalyzer to know your site is powered by Craft, you can set your sendPoweredByHeader config setting to false, which will prevent Craft from sending an X-Powered-By: Craft CMS header in its HTTP responses.

More Resources #

Here’s some other resources on the topic of security you might want to check out: