security.txt and responsible disclosure: a practical operator guide

This guide summarises RFC 9116 and common operator practice. It is not an invitation to test NovaMX systems outside the published rules.

What problem security.txt solves

Researchers who find a weakness need a reliable contact path. Without one, reports go to generic info@ addresses, marketing forms, or public channels. security.txt gives a machine-readable, expected location for Contact and policy links.

Where to publish

RFC 9116 prefers https://<domain>/.well-known/security.txt. A file at https://<domain>/security.txt may exist for compatibility, but the well-known path is the canonical target. Use HTTPS. Keep the file UTF-8 plain text.

Fields that matter in practice

1. Contact: mailto: or https: URL for reports (required in practice for usefulness).
2. Expires: an ISO 8601 timestamp; refresh before expiry so researchers trust the file.
3. Preferred-Languages: for example en and nl.
4. Canonical: the exact HTTPS URL of this security.txt.
5. Policy: link to your disclosure or vulnerability disclosure policy page.
6. Acknowledgments / Hiring: optional; only add if maintained.

Responsible disclosure basics

Publish clear expectations: what is in scope, what is out of scope (for example social engineering of staff), how quickly you acknowledge reports, and that you will not pursue good-faith researchers who follow the rules. Require enough detail to reproduce the issue. Do not demand NDAs before you triage.

Relation to Internet.nl and headers

Internet.nl groups several website hygiene checks under security options. security.txt may appear alongside header expectations such as Content-Security-Policy related checks in the broader ecosystem. Treat the live report as authoritative for scoring. A perfect security.txt does not replace TLS, DNSSEC or RPKI.

What NovaMX publishes

NovaMX publishes security contact information for novamx.eu via the well-known security.txt path and documents trust facts on the Security and trust page. Reports for NovaMX systems should use the published security or abuse contacts, not random staff mailboxes. Customer domains need their own security.txt when those domains are in scope for researchers.

Customer domains on NovaMX hosting

If NovaMX hosts your website, you remain responsible for the content of security.txt unless a product feature publishes it for you. Prefer a monitored mailbox such as security@your-domain. Point Policy at a short page you control. Set Expires within a year and diarise renewal.

Operational checklist

1. Create security@ or an equivalent ticket queue with 24/7 paging for severity.
2. Write a one-page disclosure policy (scope, safe harbour, timelines).
3. Publish /.well-known/security.txt with Contact, Expires, Canonical, Preferred-Languages, Policy.
4. Re-run Internet.nl after publication; store the permalink.
5. Review Expires quarterly; rotate contacts when staff change.

What not to do

1. Do not list personal mobile numbers that change without updating the file.
2. Do not claim a bug bounty if you do not run one.
3. Do not invite destructive testing on production without a written programme.
4. Do not paste secrets or internal hostnames into the file.

Common questions

Is security.txt mandatory by law in the Netherlands?

There is no general consumer law that every site must publish security.txt. It is still strong hygiene and may be required for a 100% Internet.nl website score under the current norm.

Can I use only a web form?

Yes if the Contact URL is stable and monitored. Many operators also provide mailto: for researchers who prefer mail.

Does NovaMX open customer sites for scanning because of this guide?

No. Researchers must follow each domain’s published policy. Unauthorised testing remains unacceptable.

Where do I read NovaMX trust facts?

See Security and trust on novamx.eu, plus the Internet.nl path guide for scoring context.

Next steps

Publish security.txt, then verify with Internet.nl and your trust page.