security.txt: Give Researchers a Simple Way to Report Bugs (RFC 9116)

Quick answer: security.txt is a plain-text file at /.well-known/security.txt, defined by RFC 9116, that provides a standardized way for researchers to report vulnerabilities. It requires two fields: Contact and Expires. For AI-built apps, it is a vital safety net that ensures bugs are reported privately rather than disclosed publicly.

By Paula C · Kraftwire Software

Key Takeaway

A security.txt file is a plain-text file located at /.well-known/security.txt that provides a standardized way for security researchers to report vulnerabilities to you. Defined by RFC 9116, it serves as a "digital mailbox" for bug reports. To be valid, it must contain at least two fields: Contact (where to send reports) and Expires (when the information should be updated). For developers using AI tools like Cursor, Lovable, or Windsurf, shipping this file is a critical step in a vibe coding security checklist because it ensures that when a researcher finds a leaked API key or a broken RLS policy, they have a direct path to tell you privately instead of posting it on social media.

The Problem: The "Silent" Vulnerability Gap

When a security researcher discovers a flaw in your application, they face a dilemma. If your website only lists a sales email or a generic support form, the researcher may assume their report will be ignored or handled by someone without technical security knowledge. In many cases, if a clear reporting channel isn't found within minutes, the researcher may give up, or worse, disclose the bug publicly to force a response.

This is particularly relevant for modern, fast-shipped applications. When these high-risk bugs exist, the lack of a security.txt file means you are essentially flying blind. You are relying on luck rather than a structured intake process. By implementing RFC 9116, you provide a machine-readable signpost that says, "We take security seriously, and here is exactly how to help us."

What Is a security.txt File? (RFC 9116)

It is not a piece of code that "secures" your site; rather, it is a communication protocol. It lives at a predictable URL so that both humans and automated security tools can find it.

For developers building with AI, this is a "set it and forget it" security win. Whether you are managing Windsurf security risks or auditing a Lovable application, adding this file ensures that your rapid deployment cycle doesn't leave your security communications in the dark.

Required and Recommended Fields

RFC 9116 defines specific directives. While the spec allows for several fields, two are strictly mandatory for the file to be considered valid.

Required Fields

• Contact · This directive MUST be present. It provides a URI for researchers to report vulnerabilities. This can be a mailto: email address (e.g., mailto:security@example.com) or a https:// URL pointing to a secure web form.
• Expires · This directive MUST be present. It indicates the date and time after which the data in the file should be considered stale.

Recommended Fields

• Encryption · A link to your PGP public key. This allows researchers to encrypt their reports, ensuring that sensitive vulnerability details aren't intercepted in transit.
• Policy · A link to your vulnerability disclosure policy (VDP). This document outlines "safe harbor" terms, promising that you won't take legal action against researchers who follow your rules.
• Acknowledgments · A link to a "hall of fame" or page where you thank researchers who have helped secure your site.
• Canonical · The authoritative URL for your security.txt file, which helps prevent confusion if the file is mirrored or cached elsewhere.
• Hiring · A link to your security careers page.

Example of a Valid security.txt File

A standard file for a modern AI-built startup might look like this:

Implementation: Location and Headers

To comply with RFC 9116, the file must be served correctly:

• Path: The primary location is /.well-known/security.txt. While placing it at the root (/security.txt) is common for legacy reasons, the .well-known directory is the standard.
• Protocol: The file MUST be served over HTTPS to ensure integrity.
• Content-Type: The server should return a text/plain MIME type.
• Maintenance: You must update the Expires field before it passes. An expired file is often ignored by automated scanners and professional researchers as it suggests the security contact may no longer be monitored.

If you are using a platform like Vercel or Netlify to host your AI-built app, you can simply add this file to your public or static folder. For more on platform-specific setups, see our Vercel security checklist.

Why This Matters for AI-Built Apps

Vibe-coding and AI-assisted development allow for incredible speed, but they also introduce specific risks.

When an AI like Cursor or Bolt.new generates code, it might inadvertently skip security headers or leave a database endpoint exposed. A security.txt file acts as a safety net. It acknowledges that while you strive for perfect code, you have a process in place for when things go wrong. It is a core component of AI code review security because it bridges the gap between automated generation and human oversight.

security.txt vs. Bug Bounties

A common misconception is that a security.txt file is the same as a bug bounty program. It is not.

• security.txt is a communication channel. It costs nothing and carries no obligation to pay researchers.
• Bug Bounty Programs (like those on HackerOne or Bugcrowd) are formal arrangements where you pay for valid reports.

You can have a security.txt file without a bounty program. In fact, most small-to-medium apps should start with a security.txt and a clear disclosure policy before ever considering a paid bounty.

How to Validate Your File

Once you have deployed your file, you should verify it. A missing or malformed file provides no benefit. You can use the SimplyScan security.txt Validator to check for:

• Correct placement in /.well-known/.
• Presence of required Contact and Expires fields.
• Valid date formatting.
• Proper HTTPS delivery.

This tool is part of our suite of 60+ free security tools designed to help developers ship safely.

Beyond the Signpost: A Full Security Audit

While security.txt is an essential first step, it only handles the *reporting* of bugs. To prevent those bugs from existing in the first place, you need a proactive scanning strategy. SimplyScan provides a comprehensive security scanner that grades your app across 8 dimensions, including speed, SEO, and AI visibility (AEO).

While these aren't always "vulnerabilities," they impact user experience and can sometimes be leveraged in denial-of-service scenarios. A full scan helps you identify architecture security risks that a simple text file cannot address.

Summary Checklist for RFC 9116

• Create a security.txt file with Contact and Expires.
• Link to a Policy page to define your disclosure rules.
• Place the file at yourdomain.com/.well-known/security.txt.
• Ensure your web server serves it as text/plain over HTTPS.
• Set a calendar reminder to update the Expires date every 6-12 months.
• Run a free SimplyScan report to ensure no other critical vulnerabilities are currently exposed.

By spending ten minutes setting up this file, you move your application from "hoping for the best" to "prepared for the worst." It is one of the most effective ways to build trust with the global security community.

***

FAQ

Is security.txt a legal requirement for my website?

No, security.txt is a voluntary standard defined by RFC 9116, not a law. However, it is increasingly expected by security professionals. For apps built with AI tools like Cursor or Windsurf, it serves as a professional signal that you have a vulnerability disclosure process in place, which can be a competitive advantage when selling to enterprise clients.

Does having a security.txt file make me a target for hackers?

No. Malicious actors already use automated scripts to find vulnerabilities like exposed secrets regardless of whether you have this file. security.txt is designed for "white hat" researchers who want to help you. It provides them a legal and clear path to report findings privately, reducing the risk of public "zero-day" disclosures.

How long should the Expires date be set for?

RFC 9116 does not set a maximum duration, but a best practice is to set it for 6 to 12 months in the future. Setting it too far out (e.g., 5 years) is discouraged because contact emails and security policies often change. A shorter expiration forces you to review and verify that your security contact information is still accurate.

Can I use a social media profile as a Contact method?

While technically possible if you provide a URI, it is highly discouraged. Security reports often contain sensitive data, logs, and screenshots. A dedicated security email (e.g., security@company.com) or a secure web form is the professional standard. This ensures the report reaches your technical team directly rather than getting lost in social media notifications.

What is the difference between /.well-known/security.txt and /security.txt?

The RFC 9116 standard officially designates /.well-known/security.txt as the correct location. The root location (/security.txt) was used in earlier drafts of the standard and is still checked by many tools for backwards compatibility. For maximum compatibility, you can place it in the .well-known folder and set up a redirect from the root.

Do I need to sign my security.txt file with PGP?

Signing the file with an OpenPGP signature is recommended but not required. A signature allows researchers to verify that the file was actually created by you and hasn't been tampered with by an attacker. If you are just starting out, focus on the required Contact and Expires fields first, then add signatures as your security maturity grows.