Vulnerability disclosure

If someone finds a flaw in your site today, where do they send it?

Most organisations cannot answer that. Not because they decided against it, but because nobody was ever asked. This is what a reporting route is, how to check yours in about a minute, and the four ways one can look present when it is not.

What a reporting route actually is

Two things, either of which is enough to start:

• A security.txt file at /.well-known/security.txt on your domain. This is a published standard — RFC 9116 — and it is a plain text file naming a contact address, and optionally a policy link, a preferred language and an encryption key. It takes minutes to write and it is the first place a researcher looks, because it is the only place that is the same on every site.
• A disclosure page a person can find from your site: what you want reported, where to send it, and what you will do in return.

Neither is a security control. Neither stops an attack. What they do is far narrower and worth being precise about: they make it possible for someone who already found a problem to tell you about it.

What happens when there is no route

People find flaws in ordinary systems constantly — a misconfigured bucket noticed in passing, a token in a JavaScript bundle, an endpoint that answers a question it should not. The finder is usually not an attacker. They are someone who now has a decision to make, and with no address to send it to, they make it without you.

They can:

• Do nothing. The most common outcome, and the one you never learn about.
• Post it. On a forum, a blog, or a conference slide, because that is what is available.
• Email whoever they can find. A sales address, a support queue, a director on LinkedIn — where it is read as spam and deleted.
• Sell it. Rare, but the option exists, and a closed door makes it relatively more attractive.

You do not get a say in which. That is the whole cost of the missing file: not that you are more likely to be attacked, but that you have handed the decision about your own vulnerability to a stranger.

Four ways a route looks present when it is not

Checking is harder than it sounds, and a status code alone will mislead you. These four patterns all produce a confident, wrong answer.

1. The soft 404

You request /security and get HTTP 200. It looks like a page exists. Open it and it is the site's empty template — sometimes titled literally Page — because the server returns 200 for every path that does not exist. The test is not the status code, it is whether the body says anything. Try a path you invented, like /definitely-not-real-9x7. If that also returns 200, your status codes are telling you nothing.

2. The page about a different kind of security

/security resolves, and it is genuinely a page — about physical security products, a trade show the company exhibited at, or advice to customers on choosing passwords. A researcher looking for somewhere to send a report finds it, reads two lines, and leaves.

3. The programme nobody can find

Some organisations run a real programme on a third-party platform and never link to it from their own domain. It exists, it is staffed, and it is invisible to anyone who starts where everyone starts: your website. If you have a programme, security.txt should point at it. One line.

4. The domain that is not yours any more

The domain you assume is the company's turns out to be parked, redirecting to a lander, or a lookalike registered by someone else — while the real site lives somewhere adjacent. Anything you conclude from checking it is about a domain you do not control, which is its own finding.

A route is where a report arrives. It is not what makes one arrive.

This is the part that gets skipped. Publishing security.txt is correct and costs almost nothing, and you should do it today whether or not you ever speak to us. But a policy is an address, not a programme. What reaches an open mailbox is whatever a passer-by happens to trip over, and the people who find the serious things mostly work where they are paid.

So a disclosure route and structured testing answer two different questions. The route answers can someone tell us? Testing answers is anyone actually looking? An organisation with a route and no programme has made itself reachable and learned nothing. That is still strictly better than the alternative, and it is where most organisations should start.

Where private testing fits

When you do want someone looking, the choice is not only "public programme or nothing". A public programme announces to every competitor and opportunist that you are looking, and invites strangers you have not checked to probe a brand you spent years building.

A private, invitation-only programme inverts that: identity-verified researchers, invited onto a scope you name, under an NDA and a written authorisation, with findings reaching you triaged and nothing published unless you approve it. If you are weighing that against a scheduled engagement instead, the comparison with penetration testing sets out where each one genuinely wins.

If you would rather not build one yourself, we will run it for you at no cost. We host the page your security.txt points at, read what arrives, and pass you only what is real — no fee, no contract, and nothing touches your systems. How the free disclosure programme works.

Exception Security runs private, invitation-only offensive security engagements. There is no subscription, setup fee or retainer — clients are billed only for a finding they have accepted, at a reward they set. If you want a second opinion on what your own domain publishes, write to support@exceptionsecurity.com and we will tell you what we see, whether or not it goes anywhere.