Apps Artificial Intelligence CSS DevOps Go JavaScript Laravel Linux MongoDB MySQL PHP Python Rust Svelte Vue

.htaccess Rules to Prevent PHP Execution

2 min read .
Published on
.htaccess Rules to Prevent PHP Execution

Public upload directories are a common security-sensitive part of web applications. If an attacker manages to upload a file such as shell.php and the web server executes it, the upload feature can become a route to remote code execution.

On Apache, a directory-specific .htaccess configuration can help prevent script execution in locations that should contain only static files.

Why .htaccess Can Help

Apache supports .htaccess files for directory-level configuration when the server permits the relevant overrides. This makes it possible to apply security rules to a specific directory without changing every virtual-host setting.

Directories such as /uploads, /assets, and /media often need to serve images, PDFs, and other static files, but they generally do not need to execute PHP.

Example .htaccess Rules

php_flag engine off

<FilesMatch "\.(php|php[34578]?|phtml)$">
  RemoveHandler .php .php3 .php4 .php5 .php7 .php8 .phtml
  RemoveType .php .php3 .php4 .php5 .php7 .php8 .phtml
  ForceType text/plain
  Require all denied
</FilesMatch>

Options -ExecCGI
Options -Includes

Here is what each part does.

1. php_flag engine off

Where supported by the PHP/Apache configuration, this disables the PHP engine for the directory so PHP files are not executed there.

2. <FilesMatch "\.(php|php[34578]?|phtml)$">

This rule targets PHP-related file extensions:

  • RemoveHandler and RemoveType → remove configured PHP handlers and MIME type associations for those extensions.
  • ForceType text/plain → asks Apache to serve matching files as plain text if they are otherwise reachable.
  • Require all denied → denies HTTP access to matching files entirely.

The deny rule is the important final barrier: an uploaded shell.php should not be accessible through the web server.

3. Options -ExecCGI

Disables CGI execution in the directory, reducing the risk of uploaded CGI-compatible scripts being executed.

4. Options -Includes

Disables Server Side Includes (SSI), which are unnecessary in a static upload directory and can introduce additional execution behavior.

Put the Rules in the Upload Directory

A common location is:

/var/www/html/uploads/.htaccess

For frameworks with a public upload directory, it may look like:

/public/uploads/.htaccess

Static uploaded files remain available according to your other rules, while executable script types are blocked.

Optional: Allow Only Selected File Extensions

You can make the directory more restrictive by explicitly allowing a set of file extensions:

<FilesMatch "\.(jpg|jpeg|png|gif|pdf|docx|zip)$">
  Require all granted
</FilesMatch>

<FilesMatch ".*">
  Require all denied
</FilesMatch>

Test this carefully because rule ordering and Apache authorization merging can affect the final behavior. Also validate uploaded files by content, not only by filename extension.

Conclusion

Preventing script execution in public upload directories is an important defense-in-depth measure. Use server-level configuration when you control the server, and use .htaccess only when directory overrides are part of your deployment model. Combine these rules with strict upload validation, randomized storage names, safe permissions, and ideally storage outside the executable web root.

DevOps Security Apache Htaccess

Related Posts

How to Block IP Ranges with `.htaccess`
Updated on
How to Block IP Ranges with `.htaccess`
One useful feature of Apache is the flexibility of .htaccess. In addition to URL rewriting and caching rules, .htaccess can also restrict access based on IP addresses. If you are dealing with spam bots, brute-force attempts, or unwanted traffic from a particular network, one quick option is to block an individual IP address or an entire range. Block a Single IP Address To block one IP address, use: Copy <RequireAll> Require all granted Require not ip 192.168.1.100 </RequireAll> This blocks 192.168.1.100 while allowing other clients to access the site.
DevOps Apache htaccess Security
How to Whitelist IP Address Ranges with .htaccess
Updated on
How to Whitelist IP Address Ranges with .htaccess
.htaccess is useful for more than URL rewriting and caching. It can also provide an additional access-control layer, including restricting an application to specific IP addresses or IP ranges. This technique can be useful when: An application is still in development and should only be available to an internal team. You want to protect sensitive paths such as /admin or /api. A server should only be reachable from an office network or VPN. Whitelist One IP Address To allow only one IP address:
DevOps Security Apache htaccess
Automatically Encrypting Eloquent Model Attributes
Published on
Automatically Encrypting Eloquent Model Attributes
Applications often store fields that deserve additional protection at rest. Laravel can encrypt selected Eloquent attributes before they are written to the database and decrypt them automatically when they are read. For modern Laravel applications, the built-in encrypted cast is preferable to overriding Eloquent’s magic __get() and __set() methods. It integrates with the model casting system and avoids interfering with Eloquent internals. Basic Implementation Define encrypted attributes in the model’s casts:
Laravel Security Encryption
Creating a CA Bundle and Converting an SSL Certificate to .PFX
Published on
Creating a CA Bundle and Converting an SSL Certificate to .PFX
Managing SSL/TLS certificates is a routine task for many developers and system administrators. One common requirement is to combine intermediate certificates into a CA bundle and then convert the certificate and private key into a .pfx file. The .pfx format, also known as PKCS#12, is commonly used when importing certificates into Windows Server and IIS, Microsoft Exchange, and other applications that expect a PKCS#12 bundle. This guide walks through the process.
DevOps SSL
Using Nginx as a Reverse Proxy for a Go Application
Updated on
Using Nginx as a Reverse Proxy for a Go Application
A Go web application often listens directly on an application port such as :8080. If you want users to access it through a normal domain on port 80 or 443, you can place Nginx in front of it as a reverse proxy. Using Nginx in front of a Go service provides several benefits: Client requests reach Nginx before being forwarded to the Go application. TLS termination can be handled at the proxy layer. Multiple application instances can be load balanced. Static assets can be served separately when that architecture makes sense. This guide shows a basic setup.
DevOps Golang Linux Nginx Reverse Proxy
chevron-up