How secure is Craft and why is it secure?

Question

• What measures have been put in place in regards to securing Craft at the core level.

• What measures have been put in place in regards to Craft's Plugins which make use of (connect to if you will) Craft's core?

• If possible (without an opinion piece being written), is there anyway to make a comparison between other popular CMS and Craft in regards to security?

• How does one know third party libraries which are used in Craft are secure?

• Craft is built on Yii PHP Framework and Twig. How secure are these?

• Has Craft ever had any security incidents to date?

• In the case there is a security incident how does the team at Craft notify people such incident occurred?

• How safe is auto-updating within Craft?

Answer 1

Updated Answer for Craft 3

I've updated and consolidated the technical parts of this for Craft 3 and placed them in a security FAQ for easier referencing: https://craftcms.com/guides/security-faq

---

Original Answer for Craft 2)

Let me get this out of the way, first... there is no perfect software. Bugs exist and some of those will be security related.

Having said that, we're pretty paranoid people (thanks NSA!) so we think about security a lot and take it seriously.

What measures have been put in place in regards to securing Craft at the core level.

Off the top of my head here's some of what we currently do:

• Perhaps the biggest thing Craft has going for it, in the event a security related bug is that we can get the fix deployed quickly to our users with Craft's one-click auto-updating. In addition to that, we can mark a release as "critical", which gets special attention in the control panel UI making it obvious there is an update that needs to occur. Thankfully, we've yet to use that feature.

• Craft/Yii uses PDO for all database queries, so all dynamic values are parameterized helping prevent SQL injection attacks. Don't think SQL injection attacks are still a problem? They are... even with the more popular apps.

• Craft validate sensitive cookie data to ensure no cookie tampering has taken place between requests.

• Craft has CSRF token validation support to help prevent CSRF attacks.

• Twig auto-encodes all HTML by default, helping avoid XSS attack vectors.

• Rich Text Fields have an HTML purification option that is enabled by default, which strips any malicious strings from the input. This is powered by the venerable HTML Purifier.

• Craft ensures that sensitive data (server paths, stack traces, etc.) doesn't get exposed to an end-user in the case where an error occurs and Dev Mode is disabled.

• Craft uses email verification for creating new accounts. You can configure how long the token in that email is valid.

• Craft makes the control panel trigger configurable for better security by making it harder for people guess the entry point to your control panel.

• Craft exposes the blowFishHashCost config setting which helps control how long a breached password hash will survive a brute-force attack.

• If a user has an invalid login attempt X times within a Y window duration, you can force them to wait for Z minutes before they try again or permanently lock their account until an admin unlocks it. All configurable.

• The user session duration is configurable.

• The default file and folder permissions are configurable.

• Craft jumps through some pretty significant hoops to ensure in-app purchasing is secure even on installs without SSL enabled.

• Craft helps prevent session/cookie hijacking, by doing things like storing the browser's user agent string in the identity cookie and validating that it matches on subsequent session requests.

• Craft will deny all requests to start a session that don't present a user agent string or IP address to prevent direct socket connections from trying to connect.

• Craft uses elevated sessions that forces people to re-enter/validate their existing password for critical actions (changing passwords, emails, permissions, etc.). By default these elevated sessions are valid for 5 minutes, but that is configurable.

• No one, not even admins, can directly change another user's password.

• Craft's codebase has been frequently audited by third party security firms and with tools like OWASP's Zed Attack Proxy Project.

• Craft has permission enforcement at the controller level for all actions that make changes to the site.

• Craft requires PHP 5.3. Some applications are still supporting back to PHP 5.2.4, which is over 14 years old (approximately 980 internet years). Craft 3 will require 5.6.

• Craft requires mcrypt with blowfish for password hashing, arguably the currently most secure and reliable method of password encryption.

• There is a help article explaining how to force SSL for all CP requests. (http://craftcms.com/help/force-ssl)

• Craft inserts caution tape across the top of all control panel pages when running in Dev Mode, reminding you not to use it on production.

• Craft can be configured to store PHP session files in a Craft folder (craft/storage/runtime/sessions) so they don't get mingled with other app's session files on shared host.

• Craft provides granular permissions on user accounts and user groups via a intuitive/simple permission system.

• Craft provides a preventUserEnumeration config setting for people that want to prevent user enumeration attempts on their forgot password pages.

• Craft provides a validateUnsafeRequestParams config setting that will ensure certain request parameters, such as redirect, are not tampered with on a POST request preventing a Denial of Service (DoS) attack vector. This config setting will be removed in the upcoming Craft 3 and the behavior will be enabled by default in Craft itself.

• Craft's session cookies get set to HTTP only.

• By default Craft will set the secure flag on all cookies if the request is over https. You can set the useSecureCookies config setting to true to force the secure flag no matter what.

• Because Craft requires OpenSSL, we have a cryptographically strong way of generating randomness for things like email verification and password reset tokens.

• Craft keep logs of any error and/or suspicious activity to help track issues down.

• Any uploaded files have their file names cleaned as well as any code embedded in the image stripped.

• Craft's default folder structure encourages people to keep Craft's application files above the web root and the requirements page at yourdomain.com/cpTrigger/utils/serverinfo does a test and warns you if sensitive Craft folders appear to be in the public web root.

• We provide an RSS feed for updates you can subscribe to that includes all bug fixes.

• Craft sets the X-Frame-Options: SAMEORIGIN header on all control panel requests to prevent the CP from being loaded in an iframe to help prevent clickjacking.

• Craft sets the X-Content-Type-Options: nosniff header on all control panel requests to help prevent some older IE/Ajax XSS attack vectors.

• Craft uses timing safe methods for sensitive comparisons like checking password the equality of password hashes helping prevent timing attacks.

• There is a “Securing Craft” support article to help guide people through securing their Craft installation.

And keep in mind that there are still plenty of additional security related things on "The List" that we plan on implementing.

What measures have been put in place in regards to Craft's Plugins which make use of (connect to if you will) Craft's core?

Permissions are enforced at the user/user group level, so if a user is using a plugin as an admin, then they'll be able to use any of Craft's services that require an admin.

If possible (without an opinion piece being written), is there anyway to make a comparison between other popular CMS and Craft in regards to security?

Someone smarter than me will have to do that.

How does one know third party libraries which are used in Craft are secure? Craft is built on Yii PHP Framework and Twig. How secure are these?

Lumping these two together because as far as Craft is concerned, Yii and Twig are both third party libraries as well.

Remember... there is no bug-free software.

I'm much more comfortable with using 3rd party libraries for things like a templating language, an RSS feed reader, an email library, an HTTP client and even (especially) a framework instead of attempting to roll our own for various reasons.

1. It's not our core competency. The people working on these libraries have gained very specific, very valuable domain knowledge about the problems their libraries are trying to solve. We can't (and shouldn't) try to be the experts in all of those areas and we should be focusing on what we do best. For example... if I had to write this code, I'd drink myself to death.

2. The libraries we use have been around a long time, are very popular and have been tried and tested across countless installs, configurations and use-cases. On an order of magnitude greater than the Craft install base is. The more installs and eyeballs on the code, the more it's been exposed and audited.

3. Worst case scenario. A devastating security bug and exploit is revealed before the library has had a chance to release an update (which is kind of a jerk move). If we think the library authors are taking too long for a fix, we can fork the library, fix it with a patch of our own and merge in the official patch when it's been released.

Has Craft ever had any security incidents to date?

Nothing that's been exploited that we're aware of. Nearly everything that we've found or that people have reported to us has been pretty minor. i.e. XSS vulnerabilities that could occur in the control panel under very specific conditions.

In the case there is a security incident how does the team at Craft notify people such incident occurred?

Depends entirely on the severity of the incident.

All fixed bugs get mentioned in the change log and we tweet about every release: http://craftcms.com/changelog

If it is severe, then we have the ability to mark an update as "critical", bringing special attention to it as well as filing an official CVE, blog post, etc.