docs: add security.txt

[bjohansebas]

ref: #1973

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

cc: @expressjs/security-wg

[netlify]

✅ Deploy Preview for expressjscom-preview ready!

Name	Link
🔨 Latest commit	39f59e5
🔍 Latest deploy log	https://app.netlify.com/projects/expressjscom-preview/deploys/696435b8179a7a00072629f9
😎 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.

[ctcpip]

shouldn't we try to comply with the spec?

[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

[bjohansebas]

I created a script to update the expiration date.

For the Acknowledgments field, i created this issue for discussion #2132

[bjohansebas]

I left this date to verify that the automation works and opens the PR correctly.

[bjohansebas]

cc: @expressjs/security-wg

[jonchurch]

I’m generally cautious about automations that open PRs, even though we do already use that pattern in this repo. My first instinct here was a much simpler solutio, a non-blocking CI check validates if the expiry is ~30 days away.

But to review the approach w/ PR creation:

I’d prefer not to add new script infrastructure for something this small. The current approach runs a script which opaquely handles both validation and bumping the date, when really this should be two things:

• do we need to update the expiry soon?
• And then (a human) validating the security.txt and bumping the expires

I don't think what this job is doing is obvious from the GHA, you have to read the script to know what this job is really doing.

We can gate the job and perform the bump entirely inline in GitHub Actions without introducing a bespoke JS parser. For example:

# Gate: is the expiry coming up?
- name: Check security.txt expiry
  id: expiry
  run: |
    expires=$(grep -i '^Expires:' .well-known/security.txt | sed 's/.*: //')
    if [ "$(date -d "$expires" +%s)" -le "$(date -d '+30 days' +%s)" ]; then
      echo "bump=true" >> "$GITHUB_OUTPUT"
    fi

- name: Bump Expires
  if: steps.expiry.outputs.bump == 'true'
  run: |
    sed -i "s/^Expires:.*/Expires: $(date -u -d '+180 days' +%Y-%m-%dT%H:%M:%SZ)/I" \
      .well-known/security.txt

- name: Create Pull Request
  if: steps.expiry.outputs.bump == 'true'
  uses: gr2m/create-or-update-pull-request-action@v1

This keeps the automation surface very small and avoids adding one off scripts in the repo. And if something breaks in this, it breaks loudly, and without us having to add any error handling. Which is desireable IMO.

Code is cheap to produce nowadays, but I still strongly prefer producing, reviewing, and maintaining as little as possible.

On intent:

Separately from the mechanics, I want to preserve the spirit of the Expires field. It’s meant to be an explicit revalidation that the contact and disclosure information is still accurate, not just a date that gets mechanically refreshed.

If we do go the PR based route, I’d strongly prefer the PR description explicitly ask reviewers to confirm the contents of security.txt, not just merge to extend the date. This is essential IMO for if none of us are around who understand this file anymore. (requested that change in #1974 (comment))

[bjohansebas]

This keeps the automation surface very small and avoids adding one off scripts in the repo. And if something breaks in this, it breaks loudly, and without us having to add any error handling. Which is desireable IMO.

I have to say I’m not good at Bash, which is why I didn’t do it that way, but your solution seems better and simpler to me.

[bjohansebas]

thanks @jonchurch !

[jonchurch]

Love me some pipefail
https://gist.github.com/mohanpedala/1e2ff5661761d3abd0385e8223e16425

[jonchurch]

I pushed an update that swaps this to using bash, sed, and grep to accomplish the expires check and then update expires if needed