1. Home
  2. Web App Vulnerabilities
  3. How to remediate – Sensitive File Disclosure

How to remediate – Sensitive File Disclosure

1. Introduction

Sensitive File Disclosure occurs when a web application makes files available that should be kept private. This can happen if documents, configuration files, or other sensitive data are stored in publicly accessible directories. It matters to businesses because it could lead to loss of confidential information, damage to reputation, and potential legal issues. Web applications across many platforms are affected, particularly those handling user-uploaded content or internal documentation. A successful exploit typically results in confidentiality compromise.

2. Technical Explanation

The root cause is usually insufficient access controls on static files within the web application’s file system. Attackers can directly request these files via a URL if they are not protected by authentication or proper authorisation checks. There isn’t a specific CVE associated with this general issue, but it falls under CWE-201 (Information Leakage). For example, an attacker might guess the location of a backup configuration file and access it through their web browser. Affected systems include any web server hosting static content without adequate security measures.

  • Root cause: Missing or inadequate access controls on files in the web root directory.
  • Exploit mechanism: An attacker directly requests sensitive files via HTTP/HTTPS, bypassing intended application logic. Example payload: https://example.com/internal_document.txt.
  • Scope: Web servers (Apache, Nginx, IIS) and applications built with frameworks like PHP, Python (Django, Flask), Ruby on Rails, and Node.js are potentially affected.

3. Detection and Assessment

  • Quick checks: Use your browser to access URLs like https://example.com/config.php, https://example.com/.git/config or https://example.com/backup.zip.
  • Scanning: Burp Suite Professional and OWASP ZAP can identify exposed files through crawling and active scanning. Example signature ID (Burp): ‘File Disclosure’.
  • Logs and evidence: Check web server access logs for requests to unusual file extensions or paths. Look for 403 errors followed by successful accesses to sensitive files. Log locations vary, but are typically in /var/log/apache2/access.log or similar.
curl -I https://example.com/sensitive_file.txt

4. Solution / Remediation Steps

Remove unnecessary static files from the web root and require authentication for sensitive documents. These steps should be performed carefully to avoid disrupting application functionality.

4.1 Preparation

  • Ensure you have a rollback plan in case of unexpected issues: restore from backup.
  • Changes should be approved by the application owner or security team.

4.2 Implementation

  1. Step 1: Identify and remove any static files that are not required for the web application to function correctly.
  2. Step 3: Verify that only authorised users can access the protected files.

4.3 Config or Code Example

Before

# Apache configuration - allowing direct access to /var/www/html
<Directory /var/www/html>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

After

# Apache configuration - restricting access to sensitive files
<Directory /var/www/html>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all denied
</Directory>
<Location /sensitive_files>
  AuthType Basic
  AuthName "Restricted Files"
  AuthUserFile /path/to/.htpasswd
  Require valid-user
</Location>

4.4 Security Practices Relevant to This Vulnerability

Practices that directly address this vulnerability include least privilege, input validation and secure defaults. These help reduce the risk of exposure.

  • Practice 1: Least privilege – limit access to sensitive files only to those who need it.
  • Practice 2: Input validation – prevent attackers from crafting malicious requests that bypass access controls.

4.5 Automation (Optional)

# Example Bash script to remove files ending in .bak from web root
#!/bin/bash
find /var/www/html -name "*.bak" -delete
echo "Removed *.bak files from /var/www/html"

5. Verification / Validation

Confirm the fix by checking that sensitive files are no longer directly accessible and authentication is required for protected resources. Test both positive and negative scenarios.

  • Post-fix check: Attempt to access a previously exposed file via your browser. Expected output: 403 Forbidden or Authentication Required.
  • Re-test: Run the quick checks from Section 3 again. The sensitive files should no longer be accessible without authentication.
  • Monitoring: Check web server logs for failed attempts to access restricted files. Example query: “403 Forbidden” AND “/sensitive_files”.
curl -I https://example.com/sensitive_file.txt

6. Preventive Measures and Monitoring

Update security baselines, implement checks in CI pipelines, and establish a regular patch review cycle to prevent similar issues. For example, use CIS benchmarks or GPOs to enforce secure file permissions.

  • Baselines: Update your web server security baseline to include restrictions on access to sensitive files.
  • Pipelines: Add static analysis tools (SAST) to your CI pipeline to identify exposed files during development.
  • Asset and patch process: Review configuration changes regularly to ensure that new files are not inadvertently exposed.

7. Risks, Side Effects, and Roll Back

Removing necessary files can break application functionality. Incorrect authentication setup may lock out legitimate users. Restore from backup if issues occur.

  • Risk or side effect 2: Incorrectly configured authentication might prevent access for all users. Mitigation: Test authentication with multiple user accounts.
  • Roll back: Restore the web root directory from the backup created in Step 4.1.

8. References and Resources

  • Vendor advisory or bulletin: [If available, link to the vendor’s specific guidance on file access controls]
  • NVD or CVE entry: [Link to a relevant CWE entry like CWE-201 – Information Leakage]
  • Product or platform documentation relevant to the fix: [Link to Apache/Nginx/IIS documentation on access control configuration]
Updated on December 27, 2025

Was this article helpful?

Related Articles