<p><strong>Updated Answer for Craft 3</strong></p>

<p>I've updated and consolidated the technical parts of this for Craft 3 and placed them in a security FAQ for easier referencing: <a href="https://craftcms.com/guides/security-faq" rel="noreferrer">https://craftcms.com/guides/security-faq</a></p>

<hr>

<p><strong>Original Answer for Craft 2)</strong></p>

<p>Let me get this out of the way, first... <a href="http://pragmatictips.com/30" rel="noreferrer">there is no perfect software</a>.  Bugs exist and some of those will be security related.</p>

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

<blockquote>
  <p>What measures have been put in place in regards to securing Craft at the core level.</p>
</blockquote>

<p>Off the top of my head here's some of what we currently do:</p>

<ul>
<li><p>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.</p></li>
<li><p>Craft/Yii uses <a href="http://php.net/manual/en/book.pdo.php" rel="noreferrer">PDO</a> 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 <a href="https://www.drupal.org/PSA-2014-003" rel="noreferrer">popular</a> apps.</p></li>
<li><p>Craft validate sensitive cookie data to ensure no cookie tampering has taken place between requests.</p></li>
<li><p>Craft has <a href="https://craftcms.com/help/csrf-protection" rel="noreferrer">CSRF token validation</a> support to help prevent <a href="https://en.wikipedia.org/wiki/Cross-site_request_forgery" rel="noreferrer">CSRF</a> attacks.</p></li>
<li><p><a href="http://twig.sensiolabs.org/" rel="noreferrer">Twig</a> auto-encodes all HTML by default, helping avoid <a href="https://en.wikipedia.org/wiki/Cross-site_scripting" rel="noreferrer">XSS</a> attack vectors.</p></li>
<li><p>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 <a href="http://htmlpurifier.org/" rel="noreferrer">HTML Purifier</a>.</p></li>
<li><p>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.</p></li>
<li><p>Craft uses email verification for creating new accounts. You can <a href="https://craftcms.com/docs/config-settings#verificationCodeDuration" rel="noreferrer">configure</a> how long the token in that email is valid.</p></li>
<li><p>Craft makes the control panel trigger <a href="https://craftcms.com/docs/config-settings#cpTrigger" rel="noreferrer">configurable</a> for better security by making it harder for people guess the entry point to your control panel.</p></li>
<li><p>Craft exposes the <a href="https://craftcms.com/docs/config-settings#blowfishHashCost" rel="noreferrer">blowFishHashCost</a> config setting which helps control how long a breached password hash will survive a brute-force attack.</p></li>
<li><p>If a user has an <a href="https://craftcms.com/docs/config-settings#maxInvalidLogins" rel="noreferrer">invalid login attempt X times</a> within a <a href="https://craftcms.com/docs/config-settings#maxInvalidLogins" rel="noreferrer">Y window duration</a>, you can force them to wait for <a href="https://craftcms.com/docs/config-settings#cooldownDuration" rel="noreferrer">Z minutes before they try again <em>or</em> permanently lock their account</a> until an admin unlocks it. All configurable.</p></li>
<li><p>The user session duration is <a href="https://craftcms.com/docs/config-settings#userSessionDuration" rel="noreferrer">configurable</a>.</p></li>
<li><p>The default <a href="https://craftcms.com/docs/config-settings#defaultFilePermissions" rel="noreferrer">file</a> and <a href="https://craftcms.com/docs/config-settings#defaultFolderPermissions" rel="noreferrer">folder</a> permissions are configurable.</p></li>
<li><p>Craft jumps through some <a href="https://craftcms.com/help/secure-in-app-purchasing" rel="noreferrer">pretty significant hoops</a> to ensure in-app purchasing is secure <em>even on installs without SSL enabled</em>.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>Craft uses <a href="https://craftcms.com/news/new-security-features" rel="noreferrer">elevated sessions</a> 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 <a href="https://craftcms.com/docs/config-settings#elevatedSessionDuration" rel="noreferrer">configurable</a>.</p></li>
<li><p>No one, not even admins, can directly change another user's password.</p></li>
<li><p>Craft's codebase has been frequently audited by third party security firms and with tools like <a href="https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project" rel="noreferrer">OWASP's Zed Attack Proxy Project</a>.</p></li>
<li><p>Craft has permission enforcement at the controller level for all actions that make changes to the site.</p></li>
<li><p>Craft requires PHP 5.3. <a href="https://wordpress.org/" rel="noreferrer">Some applications</a> are still supporting back to PHP 5.2.4, which is over <em>14 years</em> old (approximately 980 internet years).  Craft 3 will require 5.6.</p></li>
<li><p>Craft requires <a href="http://php.net/manual/en/book.mcrypt.php" rel="noreferrer">mcrypt</a> with <a href="http://php.net/manual/en/mcrypt.ciphers.php" rel="noreferrer">blowfish</a> for password hashing, arguably the currently most secure and reliable method of password encryption.</p></li>
<li><p>There is a <a href="https://craftcms.com/help/force-ssl" rel="noreferrer">help article</a> explaining how to force SSL for all CP requests. (<a href="http://craftcms.com/help/force-ssl" rel="noreferrer">http://craftcms.com/help/force-ssl</a>)</p></li>
<li><p>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.</p></li>
<li><p>Craft can be <a href="https://craftcms.com/docs/config-settings#overridePhpSessionLocation" rel="noreferrer">configured</a> to store PHP session files in a Craft folder (<code>craft/storage/runtime/sessions</code>) so they don't get mingled with other app's session files on shared host.</p></li>
<li><p>Craft provides granular permissions on user accounts and user groups via a intuitive/simple permission system.</p></li>
<li><p>Craft provides a <a href="https://craftcms.com/docs/config-settings#preventUserEnumeration" rel="noreferrer">preventUserEnumeration</a> config setting for people that want to prevent user enumeration attempts on their forgot password pages.</p></li>
<li><p>Craft provides a <a href="https://craftcms.com/docs/config-settings#validateUnsafeRequestParams" rel="noreferrer">validateUnsafeRequestParams</a> 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.</p></li>
<li><p>Craft's session cookies get set to HTTP only.</p></li>
<li><p>By default Craft will set the <code>secure</code> flag on all cookies if the request is over <code>https</code>. You can set the <a href="http://craftcms.com/docs/config-settings#useSecureCookies" rel="noreferrer">useSecureCookies</a> config setting to <code>true</code> to force the <code>secure</code> flag no matter what.</p></li>
<li><p>Because Craft requires <a href="http://php.net/manual/en/book.openssl.php" rel="noreferrer">OpenSSL</a>, we have a cryptographically strong way of generating randomness for things like email verification and password reset tokens.</p></li>
<li><p>Craft keep logs of any error and/or suspicious activity to help track issues down.</p></li>
<li><p>Any uploaded files have their file names cleaned as well as any code embedded in the image stripped.</p></li>
<li><p>Craft's default folder structure encourages people to keep Craft's application files above the web root and the requirements page at <code>yourdomain.com/cpTrigger/utils/serverinfo</code> does a test and warns you if sensitive Craft folders appear to be in the public web root.</p></li>
<li><p>We provide an <a href="https://craftcms.com/updates.rss" rel="noreferrer">RSS feed for updates</a> you can subscribe to that includes all bug fixes.</p></li>
<li><p>Craft sets the <code>X-Frame-Options: SAMEORIGIN</code> header on all control panel requests to prevent the CP from being loaded in an iframe to help prevent <a href="https://www.owasp.org/index.php/Clickjacking" rel="noreferrer">clickjacking</a>.</p></li>
<li><p>Craft sets the <code>X-Content-Type-Options: nosniff</code> header on all control panel requests to help prevent some older IE/Ajax XSS attack vectors.</p></li>
<li><p>Craft uses timing safe methods for sensitive comparisons like checking password the equality of password hashes helping prevent <a href="https://en.wikipedia.org/wiki/Timing_attack" rel="noreferrer">timing attacks</a>.</p></li>
<li><p>There is a “<a href="https://craftcms.com/support/securing-craft" rel="noreferrer">Securing Craft</a>” support article to help guide people through securing their Craft installation.</p></li>
</ul>

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

<blockquote>
  <p>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?</p>
</blockquote>

<p>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.</p>

<blockquote>
  <p>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?</p>
</blockquote>

<p>Someone smarter than me will have to do that.</p>

<blockquote>
  <p>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?</p>
</blockquote>

<p>Lumping these two together because as far as Craft is concerned, <a href="http://www.yiiframework.com/" rel="noreferrer">Yii</a> and <a href="http://twig.sensiolabs.org/" rel="noreferrer">Twig</a> are both third party libraries as well.</p>

<p>Remember... <a href="https://softwareengineering.stackexchange.com/questions/195571/is-it-possible-to-reach-absolute-zero-bug-state-for-large-scale-software">there is no bug-free software</a>.</p>

<p>I'm much more comfortable with using 3rd party libraries for things like a <a href="http://twig.sensiolabs.org/" rel="noreferrer">templating language</a>, an <a href="http://simplepie.org/" rel="noreferrer">RSS feed reader</a>, an <a href="https://github.com/PHPMailer/PHPMailer" rel="noreferrer">email library</a>, an <a href="https://github.com/guzzle/guzzle" rel="noreferrer">HTTP client</a> and even (especially) a <a href="http://www.yiiframework.com/" rel="noreferrer">framework</a> instead of attempting to roll our own for various reasons.</p>

<ol>
<li><p>It's not our core competency.  The people working on these libraries have gained very specific, very valuable <a href="https://en.wikipedia.org/wiki/Domain_knowledge" rel="noreferrer">domain knowledge</a> 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 <a href="https://github.com/simplepie/simplepie/blob/master/library/SimplePie.php" rel="noreferrer">this code</a>, I'd drink myself to death.</p></li>
<li><p>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.</p></li>
<li><p>Worst case scenario. A devastating security bug and exploit is revealed <em>before</em> 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.</p></li>
</ol>

<blockquote>
  <p>Has Craft ever had any security incidents to date?</p>
</blockquote>

<p>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.</p>

<blockquote>
  <p>In the case there is a security incident how does the team at Craft notify people such incident occurred?</p>
</blockquote>

<p>Depends entirely on the severity of the incident.</p>

<p>All fixed bugs get mentioned in the change log and we tweet about every release: <a href="http://craftcms.com/changelog" rel="noreferrer">http://craftcms.com/changelog</a></p>

<p>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 <a href="https://cve.mitre.org/index.html" rel="noreferrer">CVE</a>, blog post, etc.</p>

CC BY-SA 3.0
2014-10-30T05:45:01.253Z
* slow clap * Bravo sir, bravo. Your attention to detail in security is both impressive and appreciated.
Lindsey D
CC BY-SA 3.0
2014-10-30T05:49:06.837Z
Attention to detail/OCD, to*mae*to/to*mah*to.
Brad Bell
CC BY-SA 3.0
2014-10-30T06:54:23.893Z
And this is why we fund your drink habit.
Josh Angell
CC BY-SA 3.0
2014-10-30T10:02:10.180Z
"Craft has an insecure icon on the Login button when logging into the control without an SSL connection" That's a rather dubious feature. If you don't use SSL and there is an attacker, that attacker can simply remove the icon from the markup. So this mainly achieves a false sense of security.
CodesInChaos
CC BY-SA 3.0
2014-10-30T10:10:19.223Z
@CodesInChaos I suppose you’re referring to a [MitM attack](http://en.wikipedia.org/wiki/Man-in-the-middle_attack)? In that case you’d be right, but the hope is that you’d notice the insecure icon before that happened (or more commonly, before someone sniffed your password).
Brandon Kelly
CC BY-SA 3.0
2014-10-30T16:24:37.440Z
upvoted and bookmarked, cheers Brad!
erwinheiser
CC BY-SA 3.0
2014-10-31T22:03:00.300Z
real kudos for that one, Brad. The gophers should show respect, play more fair ;)
narration_sd
CC BY-SA 3.0
2015-11-29T23:05:51.927Z
Seeing as a ton of high profile WordPress plugins recently just got [burned](https://blog.sucuri.net/2015/04/security-advisory-xss-vulnerability-affecting-multiple-wordpress-plugins.html) by not escaping their output URLs because of bad documentation, the fact that Twig does this by default means one less thing to worry about in Craft land...
RitterKnight
CC BY-SA 3.0
2016-03-21T16:17:22.583Z
Thank you Brad! This has helped us get a couple of clients over the line with Craft!
Matt P
CC BY-SA 3.0
2016-09-06T14:42:01.230Z
Is the following still current? `Craft has an insecure icon on the Login button when logging into the control without an SSL connection.` I've not noticed this on any installations.
William Isted
CC BY-SA 3.0
2016-09-06T17:57:44.060Z
@WilliamIsted Yeah, I think that changed Craft 2.5-ish.  I'll update the answer.
Brad Bell
CC BY-SA 3.0
2017-03-21T18:26:48.977Z
And WP continues to be plagued by XSS. Fool me once... you know the rest.  But came across [this](https://paragonie.com/blog/2016/08/cms-airship-simply-secure-content-management-now-available-in-aws-marketplace) table by another CMS maker the other night.  While their product is no Craft—it's terribly ugly—it is written by so-called security experts. And they have a comparison chart. Looking at it, Craft covers a lot of ground here. I do like the fact that they're trying to push PHP 7 too, something Craft 3 will do as well.
RitterKnight
CC BY-SA 4.0
2014-10-30T03:12:02.863Z
2019-02-19T18:07:17.113Z
2019-02-19T18:07:17.113Z
Brad Bell
<ul>
<li><p>What measures have been put in place in regards to securing Craft at the core level.</p></li>
<li><p>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?</p></li>
<li><p>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?</p></li>
<li><p>How does one know third party libraries which are used in Craft are secure?</p></li>
<li><p>Craft is built on <a href="http://www.yiiframework.com/" rel="noreferrer">Yii PHP Framework</a> and <a href="http://twig.sensiolabs.org/" rel="noreferrer">Twig</a>. How secure are these?</p></li>
<li><p>Has Craft ever had any security incidents to date?</p></li>
<li><p>In the case there is a security incident how does the team at Craft notify people such incident occurred?</p></li>
<li><p><a href="https://craftcms.stackexchange.com/q/1111/12">How safe is auto-updating</a> within Craft?</p></li>
</ul>

<security><updating><auto-updates>
How secure is Craft and why is it secure?
# How secure is Craft and why is it secure?

(Asked by: username_0 on 2014-10-29)

* 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](http://www.yiiframework.com/) and [Twig](http://twig.sensiolabs.org/). 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](https://craftcms.stackexchange.com/q/1111/12) within Craft?

**Tags:** security, updating, auto-updates


---

## 1 answers

### Answer by username_1 on 2014-10-30. Score: 121 | Accepted answer

**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](http://pragmatictips.com/30). 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](http://php.net/manual/en/book.pdo.php) 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](https://www.drupal.org/PSA-2014-003) apps.
* Craft validate sensitive cookie data to ensure no cookie tampering has taken place between requests.
* Craft has [CSRF token validation](https://craftcms.com/help/csrf-protection) support to help prevent [CSRF](https://en.wikipedia.org/wiki/Cross-site_request_forgery) attacks.
* [Twig](http://twig.sensiolabs.org/) auto-encodes all HTML by default, helping avoid [XSS](https://en.wikipedia.org/wiki/Cross-site_scripting) 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](http://htmlpurifier.org/).
* 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](https://craftcms.com/docs/config-settings#verificationCodeDuration) how long the token in that email is valid.
* Craft makes the control panel trigger [configurable](https://craftcms.com/docs/config-settings#cpTrigger) for better security by making it harder for people guess the entry point to your control panel.
* Craft exposes the [blowFishHashCost](https://craftcms.com/docs/config-settings#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](https://craftcms.com/docs/config-settings#maxInvalidLogins) within a [Y window duration](https://craftcms.com/docs/config-settings#maxInvalidLogins), you can force them to wait for [Z minutes before they try again *or* permanently lock their account](https://craftcms.com/docs/config-settings#cooldownDuration) until an admin unlocks it. All configurable.
* The user session duration is [configurable](https://craftcms.com/docs/config-settings#userSessionDuration).
* The default [file](https://craftcms.com/docs/config-settings#defaultFilePermissions) and [folder](https://craftcms.com/docs/config-settings#defaultFolderPermissions) permissions are configurable.
* Craft jumps through some [pretty significant hoops](https://craftcms.com/help/secure-in-app-purchasing) 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](https://craftcms.com/news/new-security-features) 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](https://craftcms.com/docs/config-settings#elevatedSessionDuration).
* 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](https://www.owasp.org/index.php/OWASP_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](https://wordpress.org/) 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](http://php.net/manual/en/book.mcrypt.php) with [blowfish](http://php.net/manual/en/mcrypt.ciphers.php) for password hashing, arguably the currently most secure and reliable method of password encryption.
* There is a [help article](https://craftcms.com/help/force-ssl) 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](https://craftcms.com/docs/config-settings#overridePhpSessionLocation) 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](https://craftcms.com/docs/config-settings#preventUserEnumeration) config setting for people that want to prevent user enumeration attempts on their forgot password pages.
* Craft provides a [validateUnsafeRequestParams](https://craftcms.com/docs/config-settings#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](http://craftcms.com/docs/config-settings#useSecureCookies) config setting to `true` to force the `secure` flag no matter what.
* Because Craft requires [OpenSSL](http://php.net/manual/en/book.openssl.php), 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](https://craftcms.com/updates.rss) 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](https://www.owasp.org/index.php/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](https://en.wikipedia.org/wiki/Timing_attack).
* There is a “[Securing Craft](https://craftcms.com/support/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](http://www.yiiframework.com/) and [Twig](http://twig.sensiolabs.org/) are both third party libraries as well.

Remember... [there is no bug-free software](https://softwareengineering.stackexchange.com/questions/195571/is-it-possible-to-reach-absolute-zero-bug-state-for-large-scale-software).

I'm much more comfortable with using 3rd party libraries for things like a [templating language](http://twig.sensiolabs.org/), an [RSS feed reader](http://simplepie.org/), an [email library](https://github.com/PHPMailer/PHPMailer), an [HTTP client](https://github.com/guzzle/guzzle) and even (especially) a [framework](http://www.yiiframework.com/) 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](https://en.wikipedia.org/wiki/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](https://github.com/simplepie/simplepie/blob/master/library/SimplePie.php), 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](https://cve.mitre.org/index.html), blog post, etc.

> **Comments:**
> **username_2**: * slow clap * Bravo sir, bravo. Your attention to detail in security is both impressive and appreciated.  
> **username_1**: Attention to detail/OCD, to*mae*to/to*mah*to.  
> **username_3**: And this is why we fund your drink habit.  
> **username_4**: "Craft has an insecure icon on the Login button when logging into the control without an SSL connection" That's a rather dubious feature. If you don't use SSL and there is an attacker, that attacker can simply remove the icon from the markup. So this mainly achieves a false sense of security.  
> **username_5**: @username_4 I suppose you’re referring to a [MitM attack](http://en.wikipedia.org/wiki/Man-in-the-middle_attack)? In that case you’d be right, but the hope is that you’d notice the insecure icon before that happened (or more commonly, before someone sniffed your password).  
> **username_6**: upvoted and bookmarked, cheers Brad!  
> **username_7**: real kudos for that one, Brad. The gophers should show respect, play more fair ;)  
> **username_8**: Seeing as a ton of high profile WordPress plugins recently just got [burned](https://blog.sucuri.net/2015/04/security-advisory-xss-vulnerability-affecting-multiple-wordpress-plugins.html) by not escaping their output URLs because of bad documentation, the fact that Twig does this by default means one less thing to worry about in Craft land...  
> **username_9**: Thank you Brad! This has helped us get a couple of clients over the line with Craft!  
> **username_10**: Is the following still current? `Craft has an insecure icon on the Login button when logging into the control without an SSL connection.` I've not noticed this on any installations.  
> **username_1**: @WilliamIsted Yeah, I think that changed Craft 2.5-ish.  I'll update the answer.  
> **username_8**: And WP continues to be plagued by XSS. Fool me once... you know the rest.  But came across [this](https://paragonie.com/blog/2016/08/cms-airship-simply-secure-content-management-now-available-in-aws-marketplace) table by another CMS maker the other night.  While their product is no Craft—it's terribly ugly—it is written by so-called security experts. And they have a comparison chart. Looking at it, Craft covers a lot of ground here. I do like the fact that they're trying to push PHP 7 too, something Craft 3 will do as well.  

---

