1. Introduction
The vulnerability ‘Missing ‘Cache-Control’ Header’ means a web server isn’t telling browsers how to store pages, especially those with sensitive data like passwords or credit card details. This could allow that information to be saved on a user’s computer and accessed by others. It affects any website or web application where users enter personal information. A successful exploit can lead to the compromise of confidential data, impacting confidentiality.
2. Technical Explanation
The HTTP ‘Cache-Control’ header controls how browsers cache content. If this header is missing or incorrectly configured, a browser might store sensitive pages locally without restriction. An attacker gaining access to the client machine could then retrieve that cached data. The vulnerability exists when a server responds to requests for sensitive information without specifying appropriate caching directives.
- Root cause: Absence of ‘Cache-Control’ header or incorrect values allowing browser caching of sensitive content.
- Exploit mechanism: An attacker accesses the vulnerable web page, which is cached by their browser. They then gain access to the client machine and retrieve the cached data. For example, accessing a password reset page without proper cache control could allow the entire page (including any session tokens) to be stored locally.
- Scope: All web servers and applications that serve sensitive content are potentially affected, regardless of platform or version if not configured correctly.
3. Detection and Assessment
You can check for this vulnerability by inspecting the HTTP headers returned by your web server. A thorough method involves using a web proxy to examine all responses.
- Quick checks: Use browser developer tools (Network tab) to inspect the response headers for sensitive pages and look for the ‘Cache-Control’ header.
- Scanning: Burp Suite or OWASP ZAP can be used with a pre-built scanner rule to identify missing or incorrect Cache-Control headers. These are examples only, as accuracy depends on configuration.
- Logs and evidence: Web server access logs may show requests for sensitive pages. Correlation with browser history could indicate caching behaviour.
curl -I https://example.com/sensitive_page4. Solution / Remediation Steps
Configure your web server to include a ‘Cache-Control’ header with appropriate directives for sensitive pages. This ensures browsers do not store them locally.
4.1 Preparation
- Ensure you have access to modify the web server’s configuration files. A roll back plan is to restore the original configuration file.
- Change windows may be required for production systems and should be approved by the security team.
4.2 Implementation
- Step 1: Edit your web server’s configuration file (e.g., Apache httpd.conf, Nginx nginx.conf).
- Step 2: Add or modify the ‘Cache-Control’ header for sensitive pages.
- Step 3: Restart the web server to apply the changes.
4.3 Config or Code Example
Before
# No Cache-Control header defined for sensitive pagesAfter
<Location /sensitive_page>
Header set Cache-Control "no-store, no-cache, private, must-revalidate"
Header set Pragma "no-cache"
</Location>4.4 Security Practices Relevant to This Vulnerability
Several security practices help prevent this issue. Secure header configuration is essential for protecting sensitive data. Least privilege limits the impact of a successful exploit.
- Practice 1: Implement secure headers on all web servers, including ‘Cache-Control’, ‘X-Frame-Options’, and ‘Content-Security-Policy’.
- Practice 2: Apply least privilege principles to server access, limiting who can modify configurations.
4.5 Automation (Optional)
Ansible or similar tools can automate header configuration across multiple servers. Be careful when modifying web server configurations remotely.
# Example Ansible playbook snippet
- name: Set Cache-Control headers for sensitive pages
apache2_module:
name: headers
state: present
become: true
- name: Add Cache-Control header to virtual host configuration
lineinfile:
path: /etc/apache2/sites-available/your_site.conf
regexp: '^<Location /sensitive_page>'
insertafter: '^<Location /sensitive_page>'
line: 'Header set Cache-Control "no-store, no-cache, private, must-revalidate"'
become: true5. Verification / Validation
- Post-fix check: Use `curl -I https://example.com/sensitive_page` and verify that the ‘Cache-Control’ header is present with the value “no-store, no-cache, private, must-revalidate”.
- Re-test: Repeat the quick check from Section 3 to confirm the header is now correctly set for all sensitive pages.
- Monitoring: Monitor web server logs for any errors related to header configuration or unexpected caching behaviour.
curl -I https://example.com/sensitive_page
HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, private, must-revalidate6. Preventive Measures and Monitoring
Regular security baselines and automated checks can prevent this issue. A robust patch management process ensures timely updates to web server software. For example, implement a CIS benchmark for your web server configuration.
- Baselines: Update your web server security baseline to include the required ‘Cache-Control’ header settings.
- Pipelines: Integrate SAST or DAST tools into your CI/CD pipeline to automatically scan for missing or incorrect headers during deployment.
- Asset and patch process: Review web server configurations regularly (e.g., quarterly) as part of a vulnerability management program.
7. Risks, Side Effects, and Roll Back
- Risk or side effect 1: Incorrect header values may cause unexpected browser behaviour or prevent pages from loading correctly.
- Risk or side effect 2: Changes could impact existing caching mechanisms used by CDNs or reverse proxies.
- Roll back: Restore the original web server configuration file and restart the service.
8. References and Resources
- Vendor advisory or bulletin: Check your web server vendor’s website for specific guidance on Cache-Control header configuration.
- NVD or CVE entry: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
- Product or platform documentation