docs: add security.txt

[bjohansebas]

ref: https://github.com/expressjs/expressjs.com/issues/1973

preview: https://deploy-preview-1974--expressjscom-preview.netlify.app/security.txt

cc: @expressjs/security-wg

[netlify[bot]]

✅ Deploy Preview for expressjscom-preview ready!

Name	Link
🔨 Latest commit	f6e73f990b1d22ab666828682b18b715d4abb888
🔍 Latest deploy log	https://app.netlify.com/projects/expressjscom-preview/deploys/693ef8bdbfe4dd0008aec0e9
😎 Deploy Preview	https://deploy-preview-1974--expressjscom-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[bjohansebas]

• encryption: as far as I know, we don't have a PGP key for emails, so it's not needed unless we want to start using it.
• Acknowledgments: we don't have that page, do we want it?
• Canonical: this is not necessary, this is the source of the security.txt file.
• expire: we don't need it, because why would we set an expiration date on this content? We will always keep it updated, even though the specification says it's required.
• hiring: we don't need it, we are not hiring, but we are always looking for collaborators
• Preferred-Languages: if not specified, it defaults to English. Do we want to add more languages? We are a diverse group in terms of languages.

[UlisesGascon]

encryption: as far as I know, we don't have a PGP key for emails, so it's not needed unless we want to start using it.

If any reporter requests PGP encryption, we can accommodate them using our personal PGP keys. However, we don’t have a shared/team key at this time.

Acknowledgments: we don't have that page, do we want it?

Personally, I like the idea. It would add an extra step for each report, but many reporters are doing excellent work and I think it’s worth the effort to recognize them publicly. Should we bring this up for discussion in the security working group?

Preferred-Languages: if not specified, it defaults to English. Do we want to add more languages? We are a diverse group in terms of languages.

I think English is the best option to simplify report digestion

expire: we don't need it, because why would we set an expiration date on this content? We will always keep it updated, even though the specification says it's required.

I am afraid that this is mandatory in the spec (https://www.rfc-editor.org/rfc/rfc9116#name-expires). We don’t expect this information to become stale, but the specification says the Expires field must always be present and recommends that the value be less than a year into the future to avoid staleness.

To comply with this requirement, we use one of the following approaches:

• Option A: Set a fixed date like the end of each calendar year (for example, December 31, 2025) and use a reminder system to update it annually.
• Option B (preferred): Automatically generate this field with a rolling expiration, such as today plus 180 days, so it always stays within the recommended freshness window.

We avoid using long-term future dates like the year 2099, since that would technically comply but go against the intent of keeping the file current and accurate.

We can do the automation in the future, so we can land this PR soon.

[ShubhamOulkar]

• expire: we don't need it, because why would we set an expiration date on this content? We will always keep it updated, even though the specification says it's required.

Instead of setting an expiration date, I'd prefer to define the scope of the security.txt file for specific domains.

*Acknowledgments: we don't have that page, do we want it?

Tracking in discussion is a good idea. My personal opinion, we should not do it in open environment.

[bjohansebas]

Instead of setting an expiration date, I'd prefer to define the scope of the security.txt file for specific domains.

@ShubhamOulkar I don't quite understand this idea.

Personally, I like the idea. It would add an extra step for each report, but many reporters are doing excellent work and I think it’s worth the effort to recognize them publicly. Should we bring this up for discussion in the security working group?

Yes, please bring the discussion to the security team. This decision would be outside the scope of the documentation team.

Option B (preferred): Automatically generate this field with a rolling expiration, such as today plus 180 days, so it always stays within the recommended freshness window.

I can work on this new script, I enjoy automating things.

[ShubhamOulkar]

We should place the "security.txt" file under the "/.well-known/" path, e.g., https://example.com/.well-known/security.txt as per RFC8615 of a domain name. Ref: https://www.rfc-editor.org/rfc/rfc9116#name-location-of-the-securitytxt

I don't quite understand this idea.

Its main aim is to define the process of reporting security vulnerabilities. https://www.rfc-editor.org/rfc/rfc9116#name-scope-of-the-file

[github-actions[bot]]

🚦 Lighthouse Results (Mobile & Desktop)

URL	Device	Perf	A11y	Best Practices
/	mobile	🔴 63	🟢 100	🟢 96
/en/blog/posts.html	mobile	🟢 93	🟢 96	🟢 96
/en/5x/api.html	mobile	🟠 75	🟢 95	🟢 96
/	desktop	🟢 100	🟢 100	🟢 96
/en/blog/posts.html	desktop	🟢 100	🟢 96	🟢 92
/en/5x/api.html	desktop	🟢 97	🟢 95	🟢 96

[bjohansebas]

I created a script to update the expiration date.

For the Acknowledgments field, i created this issue for discussion https://github.com/expressjs/expressjs.com/issues/2132