Automatically block access to some sensitive files

[nylen]

Some ClassicPress installs use composer to install other dependencies, or git to manage the site's files, or a .env file for configuration. These files should never be accessible via the web server, but by default they are.

ClassicPress could handle this, at least for Apache-based servers, by adding the following rules to its managed section of .htaccess:

RewriteCond %{REQUEST_FILENAME} /\.env(\.example)?$ [OR]
RewriteCond %{REQUEST_URI} ^/composer\. [OR]
RewriteCond %{REQUEST_URI} ^/vendor(/|\?|$) [OR]
RewriteCond %{REQUEST_URI} ^/\.git
RewriteRule . /index.php [L]

Thoughts?

[joyously]

Seems out of scope to me. If you use the 80/20 rule, it wouldn't be considered.

[nylen]

We have not inherited the 80/20 rule from WP. This would need more discussion but I would prefer something more like "first, do no harm".

I could argue this specific issue either way. It is out of scope for a "typical" ClassicPress configuration, but the impact should be minimal, and it could prevent some fairly rare, but potentially catastrophic problems:

• You use a .env file for configuration, and you don't block access to this file on the server. Depending on your site's settings (DB server connectivity etc) you are probably getting hacked immediately.
• You use composer and you don't block access to related files on the server. This will expose information about all of your dependencies (basically whatever you installed using composer is now semi-public knowledge).
• You use git to manage a site's files and you don't block access to related files on the server. This means any code stored in the git repository is semi-public knowledge with a bit of work. Could be catastrophic if any configuration details were stored in there.

For now, if you are managing a site in any of these ways then it is up to you to make sure your web server blocks access to the relevant URLs.

[joyously]

There are a lot of things you could put in there, like expiry headers and gzip for files. It's all out of scope for the CMS.

[nylen]

A blanket statement like "out of scope for the CMS" is not really helpful, we need to take a closer look at the costs and benefits of this change. If .htaccess rewriting did not exist today then a similar argument could be made that any server configuration is out of scope, but we do already have that.

I agree that expiry headers and gzip are out of scope, but that is because implementing them at the CMS level takes away options to implement them in other ways and can even cause breakage depending on the server configuration.

This change is a bit different, it is a question of whether we should make this change that provides some additional protection for a small percentage of users. I cannot think of anything this would possibly break, but maybe it's still not worth it. At the very least this issue can serve as documentation of one way for people to configure this if they need it.

[pattonwebz]

We should not be in the habbit of covering up bad Dev practices by patching them up in software.

[viktorix]

Just wanted to add, if you want to do this, probably should also consider Nginx and IIS servers.

[viktorix]

Going through everything, I think we don't need to complicate htaccess. If a developer knows how to use Composer, we should assume they know how to protect sensitive files. This is probably a good issue to close.