<blockquote>
  <p>Doesn't this present a security concern</p>
</blockquote>

<p>Not in-and-of itself, but if a malicious user finds an exploit through another means, it does make it easier for them to drop their payload on the file system.</p>

<p>You can, of course, not make the <code>craft/app</code> folder writeable by Apache/PHP and just do <a href="https://craftcms.com/docs/updating#manually-updating" rel="nofollow">manual updates</a>.  Or better yet, do the auto-updates on development or staging boxes (so you can properly test) and deploy to production where <a href="https://craftcms.com/docs/config-settings#allowAutoUpdates" rel="nofollow">auto-updates are disabled</a>.</p>

CC BY-SA 3.0
2016-07-12T19:41:53.503Z
+1 for disallowing auto-updates in production. Update locally, deploy to production, run any "finish up" tasks on production.
Lindsey D
CC BY-SA 3.0
2016-07-12T20:19:41.507Z
Thank you. I plan to do manual updates, but still wondered about this approach.
userAW
CC BY-SA 3.0
2016-07-12T19:15:06.197Z
2016-07-12T19:15:06.197Z
Brad Bell
<p>Security is not off or on, it's layers of an onion.  Anything you do has to factor into the bigger picture.</p>

<p>My layers include:</p>

<ul>
<li><strong>What user does the web server run as? What user is your content?</strong>
Your web server should never be the same as the user who owns the files, typically www-data, www, apache, etc. Also, don't run apache as the user nobody.</li>
<li><strong>Are you using PHP-FPM, su-PHP, fastcgi, or Apache w/ mod_PHP baked in?</strong> I prefer fpm since you can run every website as a separate pool and separate PHP ini / open_basedir configs, increasing security. If a site gets hacked, only that pool is affected.</li>
<li><strong>What are the permissions of the folders/files?</strong> Shouldn't ever be 777, ideally 750 for directories and 640 for files. The web server should be added to the user's group and given read permissions (so it can only access static files).</li>
<li><strong>Who else has access to the server?</strong> Deploy users via SSH, (s)FTP, MySQL replication users, etc. Limit access to need-to-know.</li>
</ul>

<p>Just to play devil's advocate, if you do disable the one-click updates in production, that also makes it harder to simply <em>update</em>, which could be worse than not updating at all. I've seen well-meaning WP Devs tend to fall into this trap, keeping their client's sites in a sort-of cryogenic state. While Craft is not as widely used, the same security precautions apply. </p>

<p>I'm reminded of <a href="https://craftcms.stackexchange.com/a/4449/1016">Brad's post about security here</a>:</p>

<blockquote>
  <p>Perhaps the biggest thing Craft has going for it, in the event a security related bug is that <strong>we can get the fix deployed quickly to our users with Craft's one-click auto-updating.</strong> In addition to that, we can mark a release as "critical", which gets special attention in the control panel.</p>
</blockquote>

<p>Craft probably needs to eventually write files to the server anyway, including cache files, and assets, so unless you're shutting off access there as well, I'd wager it's the same risk—maybe even more so—because asset files/uploads tend to be in the web root unless you do some file aliasing.</p>

<p>And without question, if you're not backing up your database and filesystem regularly, you're asking for trouble. Let's assume you are hacked. If you don't have good back-ups, whether auto-update is on or off is not going to help you. </p>

CC BY-SA 3.0
2016-07-12T20:22:31.490Z
As always, a way better answer than mine from @RitterKnight.
Brad Bell
CC BY-SA 3.0
2016-07-12T20:30:44.737Z
I think there's always room for brevity too ;)
RitterKnight
CC BY-SA 3.0
2016-07-12T20:06:37.627Z
2016-07-12T20:18:37.770Z
2017-04-13T12:51:00.200Z
RitterKnight
<p>To allow one-click updates on my site, I need to make the Craft 'app' folder writeable by the web server.
Doesn't this present a security concern...to allow the actual php files of the application to be writeable by the web server? </p>

<auto-updates><updates>
Is it safe to make the 'app' folder writeable by the web server?
# Is it safe to make the 'app' folder writeable by the web server?

(Asked by: username_0 on 2016-07-12)

To allow one-click updates on my site, I need to make the Craft 'app' folder writeable by the web server.
Doesn't this present a security concern...to allow the actual php files of the application to be writeable by the web server?

**Tags:** auto-updates, updates


---

## 2 answers

### Answer by username_1 on 2016-07-12. Score: 2 | Accepted answer

> Doesn't this present a security concern

Not in-and-of itself, but if a malicious user finds an exploit through another means, it does make it easier for them to drop their payload on the file system.

You can, of course, not make the `craft/app` folder writeable by Apache/PHP and just do [manual updates](https://craftcms.com/docs/updating#manually-updating). Or better yet, do the auto-updates on development or staging boxes (so you can properly test) and deploy to production where [auto-updates are disabled](https://craftcms.com/docs/config-settings#allowAutoUpdates).

> **Comments:**
> **username_2**: +1 for disallowing auto-updates in production. Update locally, deploy to production, run any "finish up" tasks on production.  
> **username_0**: Thank you. I plan to do manual updates, but still wondered about this approach.  

---

### Answer by username_3 on 2016-07-12. Score: 4

Security is not off or on, it's layers of an onion. Anything you do has to factor into the bigger picture.

My layers include:

* **What user does the web server run as? What user is your content?**
  Your web server should never be the same as the user who owns the files, typically www-data, www, apache, etc. Also, don't run apache as the user nobody.
* **Are you using PHP-FPM, su-PHP, fastcgi, or Apache w/ mod\_PHP baked in?** I prefer fpm since you can run every website as a separate pool and separate PHP ini / open\_basedir configs, increasing security. If a site gets hacked, only that pool is affected.
* **What are the permissions of the folders/files?** Shouldn't ever be 777, ideally 750 for directories and 640 for files. The web server should be added to the user's group and given read permissions (so it can only access static files).
* **Who else has access to the server?** Deploy users via SSH, (s)FTP, MySQL replication users, etc. Limit access to need-to-know.

Just to play devil's advocate, if you do disable the one-click updates in production, that also makes it harder to simply *update*, which could be worse than not updating at all. I've seen well-meaning WP Devs tend to fall into this trap, keeping their client's sites in a sort-of cryogenic state. While Craft is not as widely used, the same security precautions apply.

I'm reminded of [Brad's post about security here](https://craftcms.stackexchange.com/a/4449/1016):

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

Craft probably needs to eventually write files to the server anyway, including cache files, and assets, so unless you're shutting off access there as well, I'd wager it's the same risk—maybe even more so—because asset files/uploads tend to be in the web root unless you do some file aliasing.

And without question, if you're not backing up your database and filesystem regularly, you're asking for trouble. Let's assume you are hacked. If you don't have good back-ups, whether auto-update is on or off is not going to help you.

> **Comments:**
> **username_1**: As always, a way better answer than mine from @username_3.  
> **username_3**: I think there's always room for brevity too ;)  

---

