Pros & Cons of Craft CMS Security

Craft Core:

• 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.
• 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.

Brad Bell - Lead Developer of CraftCMS - on StackOverflow