How to remediate – Security.txt File Not Detected

1. Introduction

A Security.txt file has not been detected on your server. This file allows security researchers who find vulnerabilities in your web services a defined way to report them securely. Without it, reports may be sent through less secure channels. A missing security.txt file could lead to delayed vulnerability disclosure and increased risk of exploitation. Confidentiality, integrity, and availability may all be impacted if issues are not reported promptly or handled correctly.

2. Technical Explanation

• Root cause: The security.txt file has not been created and placed in the correct directory.
• Exploit mechanism: A researcher discovers a vulnerability but cannot find contact information, potentially leading to public disclosure or sale of the issue.
• Scope: All web servers that would benefit from receiving responsible vulnerability reports are affected.

3. Detection and Assessment

You can confirm if a security.txt file is present by checking your server’s .well-known directory. A thorough method involves using a tool to scan for the file’s existence and validate its format.

• Quick checks: Use a web browser or `curl` command to check for the file at https://yourdomain/.well-known/security.txt.
• Scanning: Nessus plugin 16897 can detect missing security.txt files, but results may vary depending on configuration.
• Logs and evidence: Web server access logs will not show errors for a missing file; however, they might indicate attempts to access the location if researchers are actively looking.

curl -I https://yourdomain/.well-known/security.txt

4. Solution / Remediation Steps

Create and deploy a security.txt file containing contact information for vulnerability reports. Ensure the file is correctly formatted and placed in the .well-known directory of your web server.

4.1 Preparation

• Ensure you have a designated contact email address or PGP key for receiving reports. A roll back plan is simply deleting the security.txt file if issues arise.
• Change windows are not typically needed, but approval from security teams may be required depending on your organisation’s policy.

4.2 Implementation

1. Step 1: Create a security.txt file with contact information following the format outlined at https://securitytxt.org/.
2. Step 2: Deploy the security.txt file to the .well-known directory of your web server.
3. Step 3: Verify that the file is accessible via a web browser or `curl` command.

4.3 Config or Code Example

Before

# No security.txt file present

After

Contact: mailto:[email protected]
Tracker: https://yourbugtracker.example.com/
Policy: https://yourdomain.com/security-policy

4.4 Security Practices Relevant to This Vulnerability

Having a clear vulnerability disclosure policy and process is essential for managing security risks effectively. Input validation is not directly relevant here, but secure communication channels are important. A patch cadence does not apply as this is about configuration.

• Practice 1: Establish a documented vulnerability disclosure program to encourage responsible reporting.
• Practice 2: Use secure communication methods (e.g., PGP encryption) for handling sensitive information.

4.5 Automation (Optional)

If you use configuration management tools, you can automate the deployment of the security.txt file.

# Example Ansible task:
- name: Deploy security.txt
  copy:
    src: /path/to/security.txt
    dest: /var/www/yourdomain/.well-known/security.txt
    owner: www-data
    group: www-data
    mode: 0644

5. Verification / Validation

Confirm the fix by checking that the security.txt file is accessible and contains your contact information. Re-run the earlier detection method to ensure it’s now present.

• Post-fix check: Use `curl -I https://yourdomain/.well-known/security.txt` and verify a 200 OK response with correct content type.
• Re-test: Repeat the initial quick check to confirm the file is now accessible in your browser or via curl.
• Smoke test: Ensure that standard web services (e.g., HTTPS access, form submissions) continue to function normally.
• Monitoring: Check web server logs for any errors related to accessing the .well-known directory.

curl -I https://yourdomain/.well-known/security.txt

6. Preventive Measures and Monitoring

Update your security baseline or policy to include a requirement for a Security.txt file on all public-facing web servers. Consider adding checks in your CI pipeline to ensure the file is present during deployment, for example as part of an IaC scan.

• Baselines: Include a check for the presence and correct placement of security.txt files in your server hardening baseline.
• Asset and patch process: Review web server configurations regularly as part of your asset management process.

7. Risks, Side Effects, and Roll Back

There are minimal risks associated with deploying a Security.txt file. Incorrect contact information could lead to misdirected reports. If issues arise, simply delete the security.txt file from the .well-known directory.

• Risk or side effect 1: Incorrect contact details may result in delayed response times for legitimate vulnerability reports.
• Roll back:
  1. Step 1: Delete the security.txt file from the .well-known directory of your web server.
  2. Step 2: Verify that the file is no longer accessible via a web browser or curl command.

8. References and Resources

• Vendor advisory or bulletin: N/A – This is a configuration issue, not a vendor-specific vulnerability.
• NVD or CVE entry: N/A – No specific CVE exists for missing security.txt files.
• Product or platform documentation relevant to the fix: https://securitytxt.org/ provides comprehensive guidance on creating and deploying a Security.txt file.