Skip to content

All about security.txt policies

A security.txt policy is the file served at /.well-known/security.txt on your domain — a known location where security researchers look when they want to report a vulnerability. Create one policy in Core, then attach it to as many domain routers as you like.

Wondering how it works and why you'd bother? This article explains why security.txt exists, what each field on a policy does, how policies attach to domain routers, and the per-cluster default that's applied to new domain routers automatically.

Why security.txt is a good idea

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 clearly-published channel, what tends to happen:

  • They email security@yourdomain.com and it bounces, or goes to a shared inbox no one reads.
  • They use the public contact form and a support agent closes the ticket as spam.
  • They DM your company on social media and nobody sees it.
  • They give up and publish the bug publicly. Now anyone can exploit it before you've fixed it.

security.txt — defined by RFC 9116 — fixes this with one machine-readable file in a known location: https://yourdomain.com/.well-known/security.txt. It tells researchers (and the automated scanners many of them use) how to reach your security team, in what languages, and where to find your full disclosure policy.

Set once, apply to many

The usual way to publish a security.txt is to put a text file inside /.well-known/ on every site you operate — one copy per document root. When the policy expires (every security.txt has a mandatory expiry date — see Expires below), or your security email changes, or you add a PGP key, you have to touch every site again. Miss one and that file goes stale; scanners treat it as invalid.

In Core, you create the policy once and attach it to as many domain routers as you like. Update the policy and every attached domain serves the new file immediately. There's nothing on disk — Cyberfusion serves security.txt dynamically based on the policy attached to the domain router handling the request.

You can also mark one policy per cluster as the default. Every new domain router on that cluster is attached to it automatically.

Where to find security.txt policies

In Core, the top-level 'Security.txt Policies' page lists every policy across your clusters. Each row shows:

  • 'Name' — the label you gave the policy (Core-internal, not visible to researchers).
  • 'Status' — 'Valid' or 'Expired'.
  • 'Expires' — time until or since the expiry date.
  • 'Used by' — how many domain routers reference this policy. Hover for the full domain list.
  • 'Default' — whether this policy is the cluster's default.
  • 'Cluster' — which cluster the policy belongs to.

Click 'Create Security.txt Policy' to open the create form.

Per-policy 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 — 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, and the detail page shows how long until (or since) it expires. To extend the date, open the policy and click 'Update expiry date'.

Default for cluster

Toggle on to make this policy the cluster's default. New domain routers on this cluster will then have the policy attached automatically when they're created.

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

Email contacts

One or more email addresses for security reports. At least one 'Email Contact' or 'URL Contact' is required.

URL contacts

One or more URLs where researchers can submit a report — typically a form on your site or a third-party platform (HackerOne, Intigriti, OpenBugBounty). At least one 'Email Contact' or 'URL Contact' is required.

Policy URLs

Links to your full vulnerability disclosure policy — the page that explains what you accept reports for, your response time, whether you pay a bounty, and the rules researchers should follow.

Encryption Key URLs

Links to PGP public keys researchers can use to encrypt their report. Useful if the vulnerability itself involves your email channel (for example, a flaw in your mail server that could let someone read incoming reports).

Acknowledgment URLs

Links to a page recognising researchers who have responsibly disclosed vulnerabilities — a "hall of fame".

Opening URLs

Links to security-related job openings at your organisation.

Preferred Languages

Toggle on the languages your security team can handle. English and Dutch are supported. Researchers use this to pick the language they write their report in.

Attaching policies to domain routers

There are two ways to do this — both end up writing the same security_txt_policy_id on the domain router.

From the policy

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

For long lists, the 'Bulk select' switch at the top toggles every row on or off at once.

A row that's toggled off but shows a small link to another policy ('X is attached') means that domain router is currently using a different policy — toggling on here moves it from that policy to this one.

From the domain router

On a domain router's detail page, the 'Security.txt Policy' tile shows the currently attached policy (or 'None'). Click 'Update' and pick a policy from the dropdown.

Same cluster only

Policies and domain routers are paired per cluster. A policy in cluster A can only be attached to domain routers in cluster A. If you run multiple clusters and want the same security.txt everywhere, create one policy per cluster.

What gets served

When a visitor requests https://yourdomain.com/.well-known/security.txt, Cyberfusion looks up the policy attached to the domain router for yourdomain.com and returns an RFC 9116-formatted text file built from the fields you set.

If no policy is attached, no file is served — visitors get the same 404 they'd get for any other missing path.

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