Discuss your project

TOOLBOX · SECURITY CHECK

Check and Create security.txt.

Do security researchers find the right contact on your website? Check your security.txt according to RFC 9116 or create a new one right away.

Type of check

The bot check protects the toolbox against automated abuse.

We fetch /.well-known/security.txt once, like a browser, and also /security.txt if needed. We do not store results permanently.

No security.txt yet? Create one right here

GENERATOR

Create
security.txt.

Fill in the fields, check the preview, download the file. Everything happens in your browser; we do not see your details.

Results in the Canonical field. Every domain and subdomain needs a file of its own.

Contact required

The first entry is the preferred channel. Email addresses and phone numbers automatically become mailto: and tel:.

Default: one year from today minus one day. RFC 9116 recommends less than a year.

Languages in which you accept reports. Without this, reporters assume English.

Policy for reports

Public OpenPGP key

Thanks to reporters

Security jobs

Preview

# security.txt according to RFC 9116
# Check and renew before the expiry date (Expires).
Preferred-Languages: en, de
  • RequiredContact: Reporting Channel. State at least one contact channel: email with mailto:, phone with tel: or a page with https://. The first entry is the preferred channel.
  • RequiredExpires: Expiry Date. Set a date less than a year in the future and renew it in good time before it expires.
  • RecommendedCanonical: Own Address. Enter the file’s own address as Canonical.
  • RecommendedPolicy: Rules for Reports. Publish and link a page with the rules for reports.
  • Place the file at /.well-known/security.txt, as text/plain; charset=utf-8 and only over HTTPS.
  • Every domain and subdomain needs a file of its own. It only applies to the address at which it is located.
  • Check the details and renew Expires before the expiry date. Reporters should no longer use an expired file.
  • Optionally sign it: gpg --clearsign security.txt creates a signed version that you publish instead of the unsigned one.

WHAT BELONGS IN IT

Two Mandatory Fields.
One Clear Reporting Channel.

RFC 9116 deliberately keeps the file small. Contact and Expires are mandatory; everything else helps reporters write to you correctly and securely.

  • Required

    Contact

    Where reports go: email with mailto:, phone with tel: or a page with https://. The first entry is the preferred channel.

  • Required

    Expires

    Until when the details apply, as a date with time according to RFC 3339. Exactly once, recommended less than a year in the future.

  • Recommended

    Canonical

    The address at which the file is meant to apply. If the retrieval location differs, reporters should not trust the content.

  • Recommended

    Policy

    Link to your rules for reports: scope, process and what is allowed. The file alone is no permission for tests.

  • Optional

    Encryption

    Link to your public key so that details of a vulnerability do not travel by email in plain text.

  • Optional

    Preferred-Languages

    Languages in which you accept reports, such as “en, de”. Without this, reporters assume English.

Plus Acknowledgments (thanks) and Hiring (job offers). Sources: RFC 9116 (Sections 2 to 5), IANA registry of the fields, Directive (EU) 2022/2555 (Art. 12 and 21), BSI-CS 149 and BSI TR-03183-3.

QUESTIONS

Good to Know.

What is a security.txt?

A small text file at /.well-known/security.txt on your website. It tells security researchers how to report a vulnerability they have found to you. The format is defined in RFC 9116 of the IETF, published in April 2022. Only two fields are mandatory: Contact and Expires.

Is a security.txt required for NIS2?

No, the NIS2 Directive (EU) 2022/2555 does not mention the file. But it requires essential and important entities to take risk management measures that explicitly include “vulnerability handling and disclosure” (Art. 21(2)(e)). A security.txt is a simple, uniformly described building block for this: reports from outside arrive in the right place. The German BSI recommends the file in its cyber security recommendation BSI-CS 149 and makes it a mandatory requirement for manufacturers in the technical guideline TR-03183-3. We are happy to clarify with you what your national implementation law requires in detail.

Why does the file need an expiry date?

Outdated contact details are dangerous: reports go nowhere or reach third parties. RFC 9116 therefore makes Expires mandatory and recommends a date less than a year in the future. Once it has passed, reporters should no longer use the file. The generator sets one year from today minus one day; put the renewal in your calendar.

Do I have to sign the file?

No, but RFC 9116 recommends an OpenPGP cleartext signature together with the Canonical field. This way reporters can check that content and location really come from you. Our check recognizes the structure of a signature but does not verify it cryptographically. That needs your public key, for example with gpg --verify.

What happens to my input?

The generator and the “paste text” mode run entirely in your browser; the details do not leave your device. With the check by domain, our server fetches the file once, like a browser. The result stays in memory for five minutes so that repeated requests do not put load on the website again, and is not stored permanently.

TOOLBOX

More
Tools.

YOUR NEXT STEP

You Have the Result.
What Comes Next?

We assess findings, prioritize by risk and put changes into practice on request: as a project with EXPERTS or as ongoing operations with GRID.

Discuss the Result