Skip to content

Conversation

SpoddyCoder
Copy link

Add 403 response for hidden files/dirs and common backup/source file types.

Primary motivation is to avoid .git directories being accessible. Obviously I can extend the wordpress image to include my requirements here, or even just add to .htaccess - but felt like this would be a good addition to the base image.

Persistent file storage tends to "build up badness" over time... and it'd be a highly unusual case to want these types of files/dirs served even on a development environment... so worth adding to help protect people from themselves :)

…hidden files/dirs and common backup/source file types
@tianon
Copy link
Member

tianon commented Aug 31, 2020

I understand the motivation here, but I'd feel more comfortable doing so by default if we had some official recommendation from the WordPress project -- I'd hate to break some plugin (or even core functionality) just because we've enabled what seemed like reasonable configuration.

@SpoddyCoder
Copy link
Author

That's a reasonable response @tianon. However I'm not sure we'll ever get an official recommendation on server security configuration from the WordPress project - their position would be (again reasonably) that this is the hosts responsibility...

https://wordpress.org/support/article/hardening-wordpress/#what-is-security

The advent and ease of CaaS changes the paradigm somewhat - the container becomes the de-facto "hosting service" to those without the deeper knowledge to extend and configure it tightly. So I think it'll be up to this project to decide if it wants to put in place some sensible security defaults.

The blocks were taken from here...

https://github.com/phanan/htaccess#deny-access-to-hidden-files-and-directories

@ishitaojha
Copy link

Hey if it's still open, can I give it a try?

@conradkirschner
Copy link

Might worthable to find a compromise between these arguements and instead of adding it directly to the docker file, better place it in the readme section to create a copy&paste solution and also point out the risk and pros.

With that user can still decide if they wanna use it or not

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants