How to remediate – Missing ‘X-XSS-Protection’ Header

1. Introduction

The ‘X-XSS-Protection’ header is a browser security feature designed to help protect against Cross-Site Scripting (XSS) attacks. Its absence means websites rely solely on the browser’s built-in XSS filters, which may be insufficient or disabled by users. This affects web servers and applications serving HTTP content. A successful XSS attack could compromise user accounts, steal sensitive data, or deface a website. Confidentiality, integrity, and availability are all potentially impacted.

2. Technical Explanation

The vulnerability occurs because the server does not send the ‘X-XSS-Protection’ header in its HTTP responses. This means browsers won’t activate their XSS protection mechanisms. An attacker can inject malicious scripts into a vulnerable webpage, which will then execute within a user’s browser, appearing to come from the trusted website. The preconditions are that the server must be serving content without this header and the user’s browser must not have disabled its built-in XSS filter.

• Root cause: Missing ‘X-XSS-Protection’ HTTP response header.
• Exploit mechanism: An attacker injects a malicious script into a vulnerable webpage, typically through input fields or URL parameters. When the page is loaded, the browser executes the injected script. For example, an attacker could craft a URL containing a payload like `` and trick a user into visiting it.
• Scope: Web servers (Apache, Nginx, IIS) and applications serving HTTP content are affected.

3. Detection and Assessment

You can confirm the vulnerability by checking for the header’s presence in your server responses. A thorough assessment involves scanning all web pages for missing headers.

• Quick checks: Use a browser’s developer tools (Network tab) to inspect HTTP response headers for any given page on the website.
• Scanning: Nessus, OpenVAS, and Burp Suite can identify missing ‘X-XSS-Protection’ headers using plugins or custom scans. Example signature ID in Nessus is 35869.
• Logs and evidence: Web server access logs won’t directly show this issue but may indicate suspicious requests if an attack attempt occurred.

curl -I https://example.com

4. Solution / Remediation Steps

Configure your web server to include the ‘X-XSS-Protection’ header with a value of ‘1; mode=block’ on all pages.

4.1 Preparation

• Ensure you have appropriate permissions to modify the web server configuration file. Roll back plan: revert the configuration file to its previous version.
• A change window may be needed depending on service criticality and approval processes.

4.2 Implementation

1. Step 1: Edit your web server’s main configuration file (e.g., Apache’s httpd.conf, Nginx’s nginx.conf).
2. Step 2: Add the following line within the appropriate `` or `server` block: Header always set X-XSS-Protection "1; mode=block"
3. Step 3: Save the configuration file.
4. Step 4: Restart your web server to apply the changes.

4.3 Config or Code Example

Before

# Apache httpd.conf example
<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/html
</VirtualHost>

After

# Apache httpd.conf example
<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/html
    Header always set X-XSS-Protection "1; mode=block"
</VirtualHost>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue.

• Practice 1: Secure headers provide an extra layer of protection against common web attacks, including XSS.

4.5 Automation (Optional)

If suitable, provide a small script or infrastructure code that applies the fix at scale. Only include if safe and directly relevant.

# Example Ansible task to set X-XSS-Protection header
- name: Set X-XSS-Protection header in Apache configuration
  lineinfile:
    path: /etc/httpd/conf/httpd.conf
    regexp: '^Header always set X-XSS-Protection'
    line: 'Header always set X-XSS-Protection "1; mode=block"'
    state: present
  notify: Restart Apache

5. Verification / Validation

Confirm the fix by checking for the header in your server responses and retesting with a scanner.

• Post-fix check: Use curl -I https://example.com and verify that the output includes the line X-XSS-Protection: 1; mode=block
• Re-test: Run your vulnerability scanner again to confirm it no longer reports missing ‘X-XSS-Protection’ headers.
• Monitoring: Check web server logs for any errors related to header configuration changes. Example query: search for “Header” or “X-XSS-Protection”.

curl -I https://example.com

6. Preventive Measures and Monitoring

Update security baselines and include checks in your CI/CD pipeline to prevent this issue.

• Baselines: Update your server hardening baseline or policy to require the ‘X-XSS-Protection’ header with a value of ‘1; mode=block’. For example, CIS benchmarks provide guidance on secure header configuration.
• Pipelines: Add static analysis tools (SAST) to your CI/CD pipeline to check for missing security headers in web application code or configuration files.
• Asset and patch process: Review server configurations regularly as part of a scheduled asset review cycle, at least quarterly.

7. Risks, Side Effects, and Roll Back

Adding the header should not cause service disruption but may affect compatibility with very old browsers.

• Risk or side effect 1: Compatibility issues with older browsers that do not support the ‘X-XSS-Protection’ header (unlikely to be a significant issue).
• Risk or side effect 2: Incorrect configuration could lead to unexpected browser behaviour.
• Roll back: Remove the added line from your web server’s configuration file and restart the server.

8. References and Resources

Link only to sources that match this exact vulnerability. Use official advisories and trusted documentation.

• Vendor advisory or bulletin: N/A
• NVD or CVE entry: N/A
• Product or platform documentation relevant to the fix: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection