You may need to be a little more specific (in the context of information in the article you’ve linked to). Taken at face value, and generally speaking, no “public” access would mean that your site wouldn’t be accessible to visitors.
“the php process runs as the owner of the php files themselves”
Doesn’t that mean NO files need public access?
No.
all the .php files I mean, none of them are part of the site front end.
eg wp-activate.php
or the wp folders
And stuff like
softver.txt
isn’t that just a security risk showing WP version like that?
Moderator
Yui
(@fierevere)
永子
.php still needs to be readable by web server (PHP interpreter, if web server is running under different account – it does NOT need access to .php)
as for world – they have stub, so on direct request they are not executed.
hiding version does not seem to be reasonable too, especially if version is current, ofc if you have ancient version security by obscurity can give somewhat (questionable) protection at least vs automatic scans
I was thinking if wp-config.php could work with 400 and wp-includes seems fine with 711, then some other files can have reduced permissions?
I can open the file http://site/wp-activate.php and it gives a blank page instead of a 404, so I assume someone can attach appropriate query strings to some .php and execute something?
Moderator
Yui
(@fierevere)
永子
wp-config.php could work with 400
yes, if owned by PHP interpreter process (if using FPM or suPHP or mpm-itk = your user account)
wp-includes seems fine with 711
folders only. but they dont really need such security. its just stock wordpress
I assume someone can attach appropriate query strings to some .php and execute something?
wrong, wordpress core needs to be loaded properly before anything can be executed, thus most of the .php files are not executed directly by wordpress, they are included and not accept any query params at all.
ok so generally no need to change any perms
