Security Implications of App Files in Web Root?

[zschuessler]

Hi everyone,

Cool product - excited to give Bedrock and Sage a try.

One concern I have is, in following the getting started guide, my theme has the structure indicated here:

roots/sage

As you can see, quite a few files there could be considered dangerous in the web root. Do we have options in putting application-related code outside the document root? Things like:

1. app/*
2. /package.json
3. Cache files
4. Etc

I’ve poured over the docs but wasn’t able to find anything. The most concerning to me is the app/ folder. Thanks in advance!

[strarsis]

But WordPress plugins and themes also usually hold extra files in their own plugin directories and in the uploads directory. It then has to be ensured that nobody can access the files from the outside and that calling individual PHP scripts doesn’t allow access or unintended execution.

[ben]

@zschuessler

As you can see, quite a few files there could be considered dangerous in the web root

There’s nothing dangerous about this. Can you elaborate?

The only thing that might be considered ‘dangerous’ would be the source asset files, which you could remove when deploying

[zschuessler]

Hey Ben thanks for your quick response!

Anything that can be served publicly should be assumed will be served publicly given the right circumstances. That’s why Laravel has made the architecture decision of not putting anything in the public folder that could be a security concern (even going as far as serving storage assets as a symlink)

I don’t want to befuddle the conversation with examples of how things could go wrong, but I could easily think of a handful I’ve seen in the past, ranging from PHP failing to load as a module (rendering the PHP publicly in plain text) or generated cache files giving out critical information about the running app (which I’ve seen Sage do by default).

What are your thoughts on following a Laravel way of doing things for some future major release? It’d make me feel better. I realize the rest of the WP frameworks don’t do this either, but setting the bar higher would really set Bedrock/Sage apart.

[knowler]

I think your critique is more for WordPress than Bedrock/Sage. Serving “App files” in the web root is the reality you have to live with when using WordPress — and that’s probably why many people steer clear of WordPress in the first place. The security advantage that Bedrock provides is that your environment variables & secrets are outside of the web root.

@zschuessler

What are your thoughts on following a Laravel way of doing things for some future major release? It’d make me feel better. I realize the rest of the WP frameworks don’t do this either, but setting the bar higher would really set Bedrock/Sage apart.

Hypothetically, if we were to follow a more “Laravel Way of doing things,” we’d need to chuck out the entire WordPress admin dashboard since it needs to be in the web root, which would break compatibility with almost the entire WordPress ecosystem. IMO it wouldn’t be worth it, instead, it would be a much better endeavour to build a Laravel-based CMS.

For the sake of reference…

Default WordPress install

/var/www/public_html         ← web root
├── wp-admin
├── wp-content
├── wp-includes
├── index.php
├── license.txt
├── readme.html
├── wp-activate.php
├── wp-blog-header.php
├── wp-comments-post.php
├── wp-config-sample.php
├── wp-cron.php
├── wp-links-opml.php
├── wp-load.php
├── wp-login.php
├── wp-mail.php
├── wp-settings.php
├── wp-signup.php
├── wp-trackback.php
└── xmlrpc.php

Bedrock

Bedrock improves upon this, in the sense that it treats WordPress as a dependency, but since wp-admin must still be accessible, it still needs to site in the web root.

/var/www/example.com/current
├── config
│  ├── environments
│  └── application.php
├── web                     ← web root
│  ├── app                  ← themes, plugins, etc.
│  ├── wp                   ← WordPress
│  ├── index.php
│  └── wp-config.php
├── .env                    ← environment variables
├── composer.json
├── composer.lock
└── wp-cli.yml

WordPlate

Even WordPlate, which takes a more Laravel-y approach in terms of naming, still installs WordPress, themes, and plugins within the web root.

[zschuessler]

Great response @knowler I really appreciate the effort that went into it.

Especially on the topic of plugins, it makes sense why it wouldn’t be feasible

Thanks again for the cool product, looking forward to using it more.