The security.txt (RFC 9116) is a text document in the /.well-known/security.txt directory that connects external experts directly with the responsible security team. This file defines how professionals can report technical vulnerabilities in web applications in an encrypted manner. The procedure prevents critical security gaps from reaching the public in an uncontrolled way and ensures that companies close bugs before attackers can exploit them.

Who uses the security.txt?

The standard serves as a central point of contact for various actors. Behind the collective term "security researchers" are primarily ethical hackers (white-hats) who track down vulnerabilities out of responsibility, as well as bug bounty hunters who work for rewards. Additionally, automated crawlers access the file to catalog reporting channels in global databases. Even IT developers who stumble upon a bug by chance can find the right contact without detours.

While well-meaning experts understand the file as an invitation to cooperate, it offers no direct benefit to malicious attackers (black-hats) for a break-in – it serves exclusively the purpose of channeling the exchange about already discovered vulnerabilities.

How does the security.txt work technically?

Security researchers and automated scanners find the security.txt as a simple text file (text/plain) in the /.well-known/ directory at the top domain level. Since the document follows a fixed standard, tools immediately extract the necessary information to communicate in an encrypted manner. This allows experts to see at a glance which security policies apply and whether the company rewards reported bugs (bug bounties).

The security.txt as a security standard

Attackers never sleep. But usually it's not the vulnerability itself that causes damage, but the time that passes until developers close it. The security.txt acts like a technical guidance system here: It directs warnings immediately to where professionals can process them directly. This way, critical hints no longer get lost in support mailboxes while criminals are already kicking down the door.

Control reporting channels and shorten response times

Without security.txt, security researchers use the contact options available to them: the contact form. It can take days before the report reaches the right department within the company. In case of doubt, no one feels responsible, so the message eventually gets lost. The security.txt file, on the other hand, directs researchers directly to the security team.

Signal expertise and trust through E-E-A-T

The security.txt shows that a company securely masters its IT. Complying with strict BSI requirements signals to customers and partners: professionals are at work here. This makes people trust the brand (E-E-A-T) significantly more. The file also proves: experts maintain the systems conscientiously and monitor them comprehensively.

The file links directly to a "Vulnerability Disclosure Policy" (VDP) and thereby establishes binding rules. The reference defines exactly how experts may test the systems without the legal department intervening. This standard protects companies from risky testing methods while simultaneously offering a so-called safe harbor. Professional security researchers trust this commitment, as it guarantees that companies won't sue anyone who reports vulnerabilities responsibly.

Control hacker attractiveness

While the file hardly deters criminals, it does attract ethical hackers more. They know: my expertise is desired and valued here. Without corresponding

Global market leaders use the standard

The fact that industry giants like Google use the security.txt shows how important the format is for professional IT infrastructures. A look at Google's file (see figure) proves how detailed the corporation guides experts. There, researchers not only find email addresses but get directly to programs for bug reports (bug bounties) or to open positions in the security team. Since Google even sets the expiration date (Expires) to the year 2030, the company plans long-term with this communication channel.

Which fields belong in a professional security.txt?

For an expert-level implementation, providing an email address is not sufficient. The following structure is best practice according to RFC 9116:

Field Meaning Example/Value
Contact Required field: Email or contact form mailto:security@company.com
Expires Required field: Expiration date (ISO 8601) 2027-01-01T00:00:00.000Z
Encryption Link to public PGP key https://company.com/pgp-key.txt
Policy Link to security policies https://company.com/security-policy
Hiring Link to security job postings https://company.com/jobs
Preferred-Languages Supported languages for the report en, de
Acknowledgements Link to "Hall of Fame" (acknowledgements) https://company.com/hall-of-fame
Canonical Official URL of the security.txt file https://company.com/.well-known/security.txt

security.txt Generator

Generate a security.txt file according to RFC 9116. Place the file at /.well-known/security.txt on your web server.

mailto:
tel:

e.g. link to a contact form.

Expiry date of the file (max. 1 year recommended).

URL to your public PGP key.

Comma-separated language codes (e.g. en, de).

URL to your vulnerability disclosure policy.

URL to your hall of fame / acknowledgments page.

URL to security-related job openings.

URL to the CSAF provider-metadata.json.

Canonical URL of this security.txt file.

.well-known/security.txt 


                

                    
                    
                


                

                    

                        Generated with the mindtwo security.txt Generator — RFC 9116
                    

                

            

        

    






What critical aspects exist with the security.txt?


Despite the clear recommendations by the BSI, the professional community also discusses potential risks. Those implementing the security.txt must maintain the balance between necessary transparency and the protection of internal information.


Strategic information disclosure through recruitment references


While the hiring directive serves employer branding, it may provide attackers with insights into internal deficits. If a company specifically refers to open positions for "Cloud Security Architect" or "IAM specialists" in the security.txt, this allows conclusions about current technological construction sites or personnel bottlenecks. Attackers use this information as part of reconnaissance to specifically search for vulnerabilities in these insufficiently protected areas.


Manipulation risks and man-in-the-middle attacks


The integrity of the file is crucial for the security of the entire reporting process. If encryption via HTTPS or an additional digital signature (e.g., via OpenPGP) is missing, attackers can manipulate the contents through a man-in-the-middle attack. In this scenario, malicious actors replace the legitimate contact addresses or PGP keys with their own data. Security researchers then unknowingly send their sensitive reports directly to the attacker instead of to the company.


Increased noise from automated reports


The easy discoverability of the file attracts not only experts but also automated scanners. This often leads to an increase in low-quality or irrelevant reports ("beg bounty hunting") that address trivial errors without genuine security risk. The security team must therefore allocate resources to validate these reports and separate the "noise" from critical hints.


Checklist for technical implementation


For both Google AI and specialized security tools to correctly extract and validate the security.txt, the file must meet exact technical criteria. The following list serves as a guide for a clean configuration:


[ ] Verify standard path: The file must be accessible at domain.com/.well-known/security.txt. An additional redirect from /security.txt supports older scanners.


[ ] Set MIME type correctly: The web server (Nginx, Apache, etc.) must deliver the file with the HTTP header Content-Type: text/plain to avoid parsing errors.


[ ] Establish HTTPS enforcement: Access must only occur via an encrypted connection. Unencrypted HTTP requests should permanently redirect (301 redirect) to HTTPS.


[ ] Define validity period (Expires): The Expires field must contain a timestamp in the future. An interval of maximum twelve months ensures that contact data undergoes regular review.


[ ] Secure integrity through signature: A digital signature (OpenPGP) protects the file from manipulation. Only this way can recipients verify that the contact information actually comes from the domain owner.


[ ] Provide canonical URL: Specifying the canonical directive within the file prevents misunderstandings with mirrors or when using multiple subdomains.


Best practices for maintenance and scaling


Vulnerabilities often affect subdomains like api., dev., or staging. Since scanners specifically search for the security.txt per host, they don't automatically capture information on the main domain. Experts therefore place a separate file on each critical subdomain or redirect requests via 301 redirect to the central document.


Automated processes significantly minimize manual effort. Since scanners immediately ignore expired files, scripts or GitHub Actions keep the Expires field permanently updated. Software companies also link the file to the SECURITY.md in the code repository. This guarantees uniform policies across all platforms and ensures that reports reliably reach the security team.


Optimization of web infrastructure according to latest standards


From building robust IT governance to the technical implementation of security standards – professional support sustainably secures digital assets. As an experienced digital agency, mindtwo supports companies in precisely implementing security standards and building technical trust.




Sources & further literature