How to disable php execution in wordpress directories?

I fail to see how WP is going to work if you disable access / execution of wp-includes.

This should work fine…if you're using php-fpm and the include files are readable by it (php-fpm does not run as part of the web server but as an adjunct to it). If you're using mod_php, then you are quite right (because mod_php makes php part of the web server)…

I don't know enough about how WP works internally to comment on the wisdom of denying web server access to wp-uploads. I can understand why you would want to do it but I just don't know…

-- sw

There are lots of ways to do this… pick the one you like best.

https://www.google.com/search?q=How+to+disable+php+execution+in+wordpress+directories&oq=How+to+disable+php+execution+in+wordpress+directories&aqs=chrome..69i57j69i60.302j0j4&sourceid=chrome&ie=UTF-8

@acanton77 Actually i have read most of them carefully and i have written in this "community" as i need someone's advice.

i need someone's advice

I've never done this and I don't quite understand why anyone would WANT to do this but I suppose you have your reasons… perhaps a security issue?

Since there has been no reply other than mine I can only guess that no one else has ever done this here

I fail to see how WP is going to work if you disable access / execution of wp-includes.

Let us know what method you decide to do and how it worked.

"Knowledge is power"

Personally, I'd lean towards putting the code in your virtual host conf file (depending on file permissions, .htaccess can be updated by WordPress, which gives a hacker a way of disabling your PHP block). Have you actually tried adding it and it doesn't work? I'm afraid I use Nginx rather than Apache, but the examples you've posted look like they should work, although whether you use mod_PHP or php-fpm might be a factor.

Blocking php execution under /wp-content (n.b. that's everything under /wp-content, not just the uploads folder) and /wp-includes is part of the standard process of hardening WordPress and shouldn't cause any issues.

As the name suggests, PHP files under /wp-includes should only ever be included by PHP outside of that directory (rather than called directly by a browser). Similarly, plugins & themes shouldn't be generating URLs that end with .php, so it's safe to deny access to requests that include them. For example, this is a dodgy request that hit one of my servers in the last couple of minutes:

GET /wp-content/themes/distance-lite/languages/namespaces.php

Personally, I'd also consider using ModSecurity and/or fail2ban to further harden your WordPress installation. For example, I use the following ModSec rules to help block vulnerability scans and probing:

SecRule REQUEST_URI "@rx ^.*(cache|wp-content|wp-includes)/.*\.php$" "phase:1,log,deny,status:429,id:1960301,msg:'Blocking access to .php files under protected wp-* folders.'"

SecRule REQUEST_URI "@rx ^.*(wp-admin|wp-content|wp-includes)/.*readme\.txt$" "phase:1,log,deny,status:429,id:1960302,msg:'Blocking access to readme.txt files under protected wp-* folders.'"

fail2ban can monitor your server logs and automatically add blocks at the firewall level. For example, the above ModSec rules return a 429 HTTP status which fail2ban detects and initiates an IP block. So, the person who made that namespaces.php request will have received a 429 HTTP response and then found that any further requests failed (due to the fail2ban block).

Blocking php execution under /wp-content (n.b. that's everything under /wp-content, not just the uploads folder) and /wp-includes is part of the standard process of hardening WordPress and shouldn't cause any issues.

To amplify on this a bit N0 php file (that's part of WP or otherwise) needs execute permission. php files are interpreted so the interpreter needs execute permission (that's php-fpm or apache2 if you use mod_php). The interpreter only needs read permission to execute a php file.

The only exception to this rule is that if you have a standalone php program that requires the cli version of the php interpreter to be run by the shell using the shebang notation (#!/usr/bin/php or #!/usr/bin/env php). In these cases, the php file needs execute permission. These should always live outside any directory containing files served by a web server.

-- sw

Sorry -- my comment was badly phrased and should really have been "Blocking requests to PHP files under /wp-content…"

If you use php-fpm, you can just block all requests from any web client to any file in the WP directory tree…except for /the/path/to/index.php. php-fpm (the php interpreter) should be able to read them just fine (provided ownership/permissions are correct).

— sw