A security.txt file tells researchers how to report a vulnerability in your game or platform. Host it at /.well-known/security.txt over HTTPS, include a Contact and an Expires field, serve it as plain text, and renew it before it expires. Then make sure someone reads the inbox.
What RFC 9116 says
RFC 9116 defines security.txt as a plain text file in a machine parsable format that publishes vulnerability disclosure contacts and practices.
- Location: at /.well-known/security.txt over HTTPS. A top level security.txt is allowed for legacy compatibility, or can redirect to the well known path. If both exist, the well known version takes precedence.
- Content type: text/plain with UTF-8 charset.
- Required fields: Contact and Expires. Contact gives a way to report, such as a mailto address, a phone number or an HTTPS address. Expires appears once and uses RFC 3339 date time format. The RFC recommends setting it less than a year ahead.
- All other fields are optional.
Why studios should bother
Games and creator platforms attract researchers, curious players and cheat developers. Some will find real flaws. If they cannot find a contact, they may report publicly, send it to a random support agent, or not report at all. A clear contact point gives you a chance to fix things first.
What to put in it
Beyond the two required fields, optional fields can point to your disclosure policy page, list preferred languages and link to a hall of fame page if you run one. Keep it short and accurate. Only list what you will actually honor.
A disclosure policy to go with it
Write a short page that says:
- What is in scope, for example your game servers, web properties and apps, and what is out of scope.
- What testing is not allowed, such as attacks that degrade the service for other players or access to other players' data.
- How long you will take to acknowledge a report. Pick a number you can meet.
- Whether you offer rewards. Do not promise what you have not budgeted.
Make the inbox real
A security contact that bounces is worse than none. Use a shared mailbox that more than one person reads, set up routing to engineering, and track reports in your normal ticket system. Practise one report end to end so you know who triages, who fixes and who replies.
Keep it fresh
An expired security.txt signals to tools and researchers that the data is stale and should not be used. Put the renewal date in a calendar, or generate the file in your release process.
Checklist
- Create the file with Contact and Expires.
- Host at the well known path, text/plain.
- Publish a disclosure policy page.
- Test the mailbox with a dummy report.
- Renew before expiry.
Safeguard helps on the finding side with zero day discovery and dependency scanning, but responding to outside reports is a process you own. Free scan: https://gold.safeguard.sh/scan.
Quick check
Which fields are mandatory in security.txt?
Contact and Expires. Expires must appear only once.
Sources
Last reviewed: 19 October 2026.
