All about security.txt policies

A security.txt policy is the file served at /.well-known/security.txt on your domain, a known location security researchers check when they want to report a vulnerability. You write the policy once in Core and attach it to as many of your domains as you like.

Wondering how it works and why you'd bother? This article explains why security.txt exists, what each field does, how you attach a policy to your domains, and how to have every new domain pick it up automatically.

Creating and attaching a policy

1. Open the top-level 'Security.txt Policies' page and click 'Create Security.txt Policy'.
2. Attach it to the domains that should serve it, covered in Attaching to your domains.

Two things to know before you start:

• Every policy has a mandatory expiry date. Past it, many tools treat the file as invalid. See Expires.
• The file isn't served on a wildcard domain such as *.example.com. See What gets served.

What it solves

When someone finds a security issue on your site — a leaked API token, a way to read other people's data, an exposed admin endpoint — they need a way to tell you. Without a published channel, this is what tends to happen:

• They email security@yourdomain.com and it bounces, or lands in a shared inbox nobody reads.
• They use the public contact form, and a support agent closes the ticket as spam.
• They message your company on social media and nobody sees it.
• They give up and publish the bug publicly, so anyone can exploit it before you have fixed it.

security.txt puts the answer in one machine-readable file at https://yourdomain.com/.well-known/security.txt: how to reach your security team, in which languages, and where your full disclosure policy is. Researchers read it, and so do the automated scanners many of them use.

One policy, many domains

The usual way to publish security.txt is a text file inside /.well-known/ on every site, one copy per document root. When the policy expires, your security email changes, or you add a PGP key, you touch every site again — and miss one, and that file goes stale, which scanners treat as invalid.

In Core you create the policy once and attach it to as many of your domains as you like. Update it and every attached domain serves the new file immediately.

Nothing is written to disk. Cyberfusion builds the file from the policy attached to the domain the visitor asked for.

Fields

'Name'

A short label (up to 32 characters: letters, digits, dashes, underscores, spaces) used to pick the policy in lists inside Core. Not part of the served file, so researchers never see it.

'Expires'

Every security.txt carries a mandatory expiry date. Researchers and scanners use it to check the contacts are still current. Once past the date, many tools treat the file as invalid.

The list page shows 'Expired' next to any policy past its date. To extend it, open the policy and click 'Update expiry date'.

'Default for cluster'

Toggle on and every new domain you add on that cluster gets this policy attached automatically.

Only one per cluster can be the default. If the cluster already has one, the toggle is locked and a link to the existing default is shown. Turn it off on the current default first, then on for the new one.

Contacts — at least one is required

• 'Email Contact' — one or more email addresses for security reports.
• 'URL Contact' — one or more URLs where researchers can submit a report: a form on your site, or a platform such as HackerOne, Intigriti or OpenBugBounty.

You need at least one of the two.

The optional link fields

• 'Policy URLs' — your full vulnerability disclosure policy: what you accept reports for, your response time, whether you pay a bounty, and the rules researchers should follow.
• 'Encryption Key URLs' — PGP public keys researchers can use to encrypt their report. Useful when the vulnerability involves your email channel itself, for example a flaw in your mail server that could let someone read incoming reports.
• 'Acknowledgment URLs' — a page recognising researchers who disclosed responsibly, often called a "hall of fame".
• 'Opening URLs' — security-related job openings at your organisation.
• 'Preferred Languages' — the languages your security team can handle. English and Dutch are supported. Researchers use this to pick which language to write in.

Attaching to your domains

Two routes, with the same result.

From the policy

The policy's 'Domain Routers' section lists every domain on the same cluster, each with a toggle. Flip on the ones that should serve this policy, then click 'Save'.

• 'Bulk select' at the top toggles every row at once.
• A row that is off but shows 'X is attached' is using a different policy. Toggling it on here moves it to this one.

From the domain router

The 'Security.txt Policy' tile shows the attached policy, or 'None'. Click 'Update' and pick from the dropdown.

Same cluster only

Policies and domains are paired per cluster: a policy on one cluster can only be attached to domains on that same cluster.

Running several clusters and want the same security.txt everywhere? Create one policy per cluster.

What gets served

A request to https://yourdomain.com/.well-known/security.txt returns an RFC 9116-formatted text file built from the fields you set.

No policy attached → no file is served. Visitors get the same 404 as for any other missing path.

The listing page

Each row shows:

• 'Name' — the Core-internal label.
• 'Status' — 'Valid' or 'Expired'.
• 'Expires' — time until or since the expiry date.
• 'Used by' — how many domains use this policy. Hover for the full list.
• 'Default' — whether it is the cluster's default.

'Cluster' shows which cluster the policy belongs to.

The matching standards scan

The Standards Scans toggle on a domain includes a security.txt check. With a policy attached and scans enabled on the same domain, that field passes on the next scan.