Audit and fix your app from your editor, over MCP
Actuant
Get early access

Insights › Security

security.txt: the one-page file that tells researchers how to reach you

security.txt is a standard that tells security researchers where to report vulnerabilities they find in your app. It takes two minutes to set up and it's the first thing a researcher checks. Here's what's in it and where it goes.

Aug 8, 2026 · 4 min read

The short version

security.txt is an IETF standard (RFC 9116) that tells security researchers where to report vulnerabilities. It's a text file at /.well-known/security.txt with your contact info and disclosure policy. It takes two minutes to create and it's the first thing a researcher looks for — its absence signals that the app isn't expecting security reports, which can make a finder less likely to report responsibly.

What it looks like

security.txttxt
Contact: mailto:security@yourapp.com
Expires: 2027-08-08T00:00:00.000Z
Preferred-Languages: en
Canonical: https://yourapp.com/.well-known/security.txt

The fields

  • `Contact:` — Where to send vulnerability reports. mailto:security@yourapp.com is the standard. You can also link to a reporting form with a full URL. Multiple Contact: lines are allowed.
  • `Expires:` — When this file should be considered stale. ISO 8601 date. Set it a year out and put a calendar reminder to update it. An expired security.txt signals neglect.
  • `Preferred-Languages:` — Which languages you accept reports in. en is fine for most apps.
  • `Canonical:` — The canonical URL of this file. Useful for verifying you're reading the official copy.
  • `Encryption:` — (Optional) A link to your PGP key, if you want encrypted reports.
  • `Acknowledgments:` — (Optional) A link to your hall of fame or acknowledgments page.
  • `Policy:` — (Optional) A link to your full disclosure policy if you have one.

Where to put it

The file must be served at /.well-known/security.txt. This is the standard path every researcher and scanner checks. A redirect from the root to the well-known path is allowed, but the file should also be reachable at the canonical well-known URL.

The two-minute setup

  1. 1

    Create a security.txt file

    Write it with your security contact email and an expiry date one year from now.

  2. 2

    Put it in your static files

    If you're on Vercel or Netlify, put it in public/.well-known/security.txt. If your app serves static files from a different directory, put it there. The key is that https://yourapp.com/.well-known/security.txt must return the file.

  3. 3

    Verify it's being served

    Open https://yourapp.com/.well-known/security.txt in a browser. You should see the plain text, not a 404.

Does it actually matter?

For a new app, the practical security impact of a missing security.txt is small — you're unlikely to have an independent researcher find a vulnerability in your first month. But its absence is one of the first things a security-conscious visitor or enterprise customer checks, and a generated app ships without one by default. It's a two-minute trust signal that costs nothing and signals that you take security seriously enough to have thought about it.

Actuant checks whether /.well-known/security.txt returns a valid file with at least a Contact: and Expires: field.

Keep reading

Security headers: the six your app needs and what each one protects

Security headers are HTTP response headers that tell the browser how to defend your visitors. A generated deploy sets none of them. Here are the six that matter, what each one does, and how to check they're actually being served.

Content-Security-Policy: what it protects, how to write one, and the mistake that makes it useless

A Content-Security-Policy tells the browser which scripts, styles and connections to trust — it's your primary defense against XSS. A generated app ships with none. Here's how to write one that's strong enough to matter and test it without breaking anything.