Experiment 02 | Syrax Operations

Objective

Define and implement a responsible disclosure process that enables vulnerability reporting without authorizing active security testing.
This experiment uses my personal website as a controlled environment to design clear disclosure boundaries, implement a standards-compliant security.txt file, and publish an explicit no-scan disclosure policy. The objective is to separate discoverability from permission, ensuring that security issues can be reported responsibly while avoiding implicit or unintended authorization for probing, scanning, or testing activity.

Setup

Personal static website hosted on Cloudflare Pages.
Custom vulnerability disclosure policy published as a public HTML page.
security.txt implemented at /.well-known/security.txt in accordance with RFC 9116.
Disclosure policy configured to explicitly deny authorization for active security testing.
Local development environment used for editing and verification prior to deployment.
Verification was performed using curl -i to inspect full responses and curl -I to validate HTTP headers, content type, and routing behavior.

Methodology

1. Disclosure Policy Design

Reviewed common vulnerability disclosure practices and deliberately chose a no authorized scanning posture appropriate for a personal, static site. The disclosure policy was written to:

allow reporting of accidentally discovered issues only
explicitly deny authorization for scanning, probing, or testing
clearly define acceptable and prohibited actions
avoid ambiguous “safe harbor” language

This ensured that permission boundaries were explicit and defensible.

2. security.txt Implementation (RFC 9116)

Implemented a security.txt file at the standardized location /.well-known/security.txt in accordance with RFC 9116. The file included:

a security contact address
a direct link to the disclosure policy
expiry and canonical fields
explicit comments stating that no security testing is authorized

The goal was to provide discoverability without permission.

3. Deployment and Routing Validation

Deployed the .well-known directory and disclosure policy via Cloudflare Pages. Initial validation revealed that requests to /.well-known/security.txt returned the site’s homepage instead of the text file, caused by an incorrect filename. The issue was corrected by renaming the file to the exact RFC-defined name and redeploying the site.

This step highlighted how minor deployment errors can silently break standards compliance.

4. Verification

Verified correct behavior using command-line inspection:

curl -i to confirm response headers and body content
curl -I to validate HTTP status, content type, and absence of redirects

Successful verification confirmed:

HTTP 200 responses
text/plain content type
correct file contents
consistent application of security headers

Observations

Publishing a security.txt file increases discoverability for security contacts but does not imply authorization to perform security testing. This distinction is frequently misunderstood and requires explicit clarification in both policy and implementation.
Minor deployment issues, such as an incorrectly named file, can silently break standards compliance and cause fallback behavior that masks configuration errors.
Cloudflare Pages will serve the site’s default HTML when a well-known resource is missing, making command-line verification essential.
Verifying both headers and response bodies using curl -I and curl -i provided confidence that the disclosure mechanism behaved as intended.
Clearly defining authorization boundaries reduced ambiguity and ensured the disclosure process aligned with the site’s risk profile.

Next Steps

Periodically review the disclosure policy to ensure it remains aligned with the site’s scope and risk profile.
Revalidate security.txt compliance after future site changes or deployments.
Monitor inbound reports to assess whether the current no-scan posture remains appropriate.
Revisit authorization boundaries if the site’s functionality or exposure expands.