https://en.wikipedia.org/wiki/Security.txt
Reposted from r/selfhosted.
You must log in or register to comment.
- 2 days
I do, but with a few tweaks that cut most of the junk the other comments mention:
- Point
Contact:at a dedicated alias, not your main inbox, and filter it hard. If the noise gets bad you can drop the alias without touching anything else. - Add a
Policy:line linking to a short page that says plainly there is no bug bounty and no payment for reports. Most beg-bounty mails are mass-sent with a payment ask, so this gives you something to point them at and lets you bin them without guilt. - Don’t forget
Expires:, it’s actually required by RFC 9116 and a lot of hand-written files leave it out. Set a calendar reminder to bump it. - Serve it at
/.well-known/security.txt; the root path is only a legacy fallback.
Whether it’s worth it for a homelab is debatable, but if you host anything other people rely on (a Matrix/Lemmy instance, a shared Nextcloud), having one real contact path beats someone finding a hole and having nowhere to send it.
- Point
- Synestine@sh.itjust.worksEnglish2 days
If you run any sort of public facing website, you’ll likely get some of those eventually.
- Pomal@sh.itjust.worksEnglish10 hours
Inherently this. Keeping security/spam/admin@ open are generally benevolent behaviors for the internet. The more appropriate response is to start blocking domains and hosting providers from contacting those channels. If someone cares, they’ll reach out.
Microsoft properties on the other hand, can suck my whole asshole.
2 daysI was gonna say you had it in the wrong place, but it looks like you also serve it in the /.well-known/ location as well.
- 3abas@lemmy.worldEnglish2 days
I have a security.txt with an email to report vulnerabilities and a public key to encrypt sensitive information. The only reports I ever got were on the contract us form, unencrypted.
