To block direct access to sensitive files like logs, configuration backups, or temporary data in a CodeIgniter 3 application running on Nginx, you must configure the web server to deny requests for specific file extensions before they reach the PHP handler. This is achieved by adding location blocks with
deny all directives that target patterns such as
.log,
.bak, or
.sql. By placing these rules in your Nginx server configuration file, you ensure that any attempt to download these resources directly returns a 403 Forbidden error, effectively hiding them from public view while allowing your application code to read them internally when necessary.
Understanding the Security Risk
CodeIgniter applications often generate log files, backup archives, or cache files that contain sensitive information such as database credentials, session tokens, or internal application logic. If your web server is not configured correctly, users can potentially request these files directly via their browser. For example, navigating to
/application/logs/log-2023-10-27.php might expose detailed error traces that help attackers understand your system's vulnerabilities. Unlike Apache, which might use
.htaccess files, Nginx relies entirely on its main configuration files for this type of access control. Therefore, securing these paths requires explicit instructions within the Nginx configuration structure rather than relying on per-directory overrides.
Configuring Nginx Location Blocks
The most effective way to restrict access is to define specific
location blocks that match the file extensions you want to protect. You should add these rules inside the
server block of your site’s configuration file, typically located at
/etc/nginx/sites-available/your_site. The order of these blocks matters because Nginx processes location matches based on specificity and precedence. Here is a standard configuration snippet that blocks common sensitive file types:
server {
listen 80;
server_name example.com;
root /var/www/html;
index index.php index.html;
# Block access to log files
location ~* \.(log|ini|sql|bak|old)$ {
deny all;
return 403;
}
# Block access to hidden directories like .git or .env
location ~ /\. {
deny all;
return 403;
}
# Standard PHP processing
location ~ \.php$ {
try_files $uri =404;
fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
}
}
In this example, the regular expression
\.(log|ini|sql|bak|old)$ matches any file ending with those extensions. The
deny all; directive explicitly refuses any connection, and
return 403; ensures the server responds with a clear forbidden status code. Additionally, blocking hidden files starting with a dot (
/\.) prevents access to critical files like
.env or version control directories like
.git, which are common targets for reconnaissance.
Applying Changes and Verifying
After editing the configuration file, you must test the syntax to ensure there are no typos that could take your site offline. Run the following command in your terminal:
sudo nginx -t
If the test reports
syntax is ok and
test is successful, reload the Nginx service to apply the new rules without dropping existing connections:
sudo systemctl reload nginx
To verify that the protection is working, attempt to access a protected file using a browser or a tool like
curl. For instance, trying to access
http://example.com/application/logs/log-2023-10-27.log should result in a 403 Forbidden response. If you receive a 200 OK or see the file content, double-check that the location block is placed correctly within the server context and that the file permissions on the server itself do not inadvertently allow reading by the web server user in a way that bypasses Nginx checks (though Nginx denies at the HTTP level regardless of OS permissions).
Integrating with CodeIgniter Configuration
While Nginx handles the external blocking, it is also good practice to ensure your CodeIgniter application does not write sensitive data to publicly accessible directories if possible. In your
application/config/config.php, you can adjust the
$config['log_path'] setting. It is recommended to store logs outside the web root directory entirely. If your web root is
/var/www/html, you might set the log path to
/var/log/myapp. This adds an additional layer of security because even if Nginx misconfiguration occurs, the files are not served from the document root at all.
For more insights on securing your infrastructure against unauthorized access attempts, you might find
Firewall Detects Strange IPs in the Network useful for understanding broader network-level protections. Combining Nginx file restrictions with firewall rules creates a defense-in-depth strategy that significantly reduces the attack surface of your application.
Frequently Asked Questions
Can I still read these blocked files in my PHP code?
Yes, Nginx only controls HTTP requests from the browser. Your PHP scripts running under the same user context can still use functions like
file_get_contents() to read these files, provided the operating system file permissions allow the PHP-FPM process to access them.
What happens if I don't specify 'return 403'?
Without
return 403;, Nginx will still deny access due to the
deny all directive, but the default response might vary slightly depending on your global Nginx settings. Explicitly returning 403 ensures consistent behavior and clearly signals to clients that the resource is forbidden.
Do I need to restart Nginx after every change?
No, you do not need to fully restart the service. After testing your configuration with
nginx -t, use
systemctl reload nginx to apply changes gracefully without interrupting active user sessions.
How do I handle multiple sensitive file extensions?
You can group them in a single regular expression within one location block using the pipe character
| as an OR operator, such as
\.(log|bak|sql|key)$. This keeps your configuration clean and easier to maintain compared to creating separate blocks for each extension.
Is this method compatible with HTTPS?
Absolutely. These location blocks operate at the HTTP protocol level regardless of whether the traffic is encrypted via SSL/TLS. As long as your Nginx server block handles both port 80 and port 443 correctly, the restrictions will apply to secure connections as well.