Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
To stop PHP files from running when requested in a particular WordPress directory, add a narrowly scoped rule to the web server: use .htaccess on Apache if the host permits the required overrides, or server configuration on Nginx. First identify which server your site uses. Then test the rule with a temporary PHP file in the protected directory and remove the file after verification.
Choose the rule for your web server
Apache and Nginx use different configuration systems. An Apache .htaccess file has no effect on Nginx; Nginx rules must be added to server configuration by someone with administrator access. WordPress provides separate guidance for Apache and Nginx.
Apache 2.4: deny web requests in the target directory
Place this in an .htaccess file in the directory you want to protect, such as the actual uploads directory:
Free tools Windows power users keep installed
One-click scans. No signup required.
<FilesMatch "\.php$">
Require all denied
</FilesMatch>The rule denies HTTP access to files whose names end in .php in that directory. Apache documents FilesMatch as usable in .htaccess, and Require all denied as an authorization directive. The server must allow these directives in distributed configuration files; a common setting is AllowOverride AuthConfig. See Apache’s configuration sections, authorization guide, authorization directive reference and core directive reference.
#1 Best Overall
If the site returns an internal server error or the rule has no effect, check the Apache error log and ask the host or administrator to confirm that distributed configuration files and the necessary AllowOverride or AllowOverrideList permissions are enabled. If you edit the WordPress root .htaccess instead, keep your custom rule outside WordPress-managed rewrite blocks; WordPress manages its rewrite rules there. A server administrator can also apply an equivalent restriction in the main configuration, scoped to a filesystem <Directory> block.
Nginx: add a server-level restriction
Nginx does not read per-directory .htaccess files. Add this WordPress example, or a carefully adapted equivalent, to the applicable server configuration:
location ~* /(?:uploads|files)/.*.php$ {
deny all;
}WordPress says this restriction covers PHP requests beneath uploads or files, including subdirectory installations and multisite. Account for the site’s existing PHP and location rules when placing it. A typo or conflicting rule can leave a gap, so have the host or server administrator make the change if you do not manage Nginx configuration. See the WordPress Nginx guidance.
Recommended Free Tools
Apply and verify the restriction
- Find the right directory. Confirm the filesystem path and URL path for uploads, and identify any other writable directories that should not serve PHP. Installations do not all use the same paths.
- Identify the active server and handler. Confirm whether requests are served by Apache or Nginx before choosing a configuration method. An Apache local-file rule will not configure Nginx.
- Back up and add the narrow rule. Save the existing configuration before editing it. Apply the Apache rule only where overrides are allowed, or have an administrator add the Nginx rule to the relevant server configuration. On managed hosting, ask the provider to apply it if you do not have access.
- Test the live behavior. Put a temporary PHP file in the protected directory and another nested directory, then request each through a browser. A blocked request must not return the file’s PHP output. WordPress specifically recommends testing the Nginx uploads restriction this way. Remove every test file immediately after checking.
- Check normal site behavior. Confirm that expected images, documents and other static uploads still load and that relevant site features work.
What this protection does—and does not do
This is a web-server restriction on direct HTTP requests for matching PHP files. It should not be treated as proof that every possible indirect PHP include or server-side invocation is prevented; the result depends on how Apache and PHP are configured. Avoid relying on a generic Options -ExecCGI snippet as a universal way to disable PHP handlers, particularly across different PHP-handler arrangements.
Blocking PHP requests in writable directories is one hardening measure, not a complete security strategy. WordPress also recommends limiting writable files and directories, keeping software updated and asking the hosting provider about precautions on shared servers. Continue to use least-privilege access, backups and an incident-response plan; see WordPress’s hardening guidance.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
