Beg bounties

1. Why this page exists

We genuinely value people who take the time to find and report real security problems, and we want to make that easy. We also receive a steady trickle of a very different kind of message: an unsolicited email that names a trivial, publicly observable misconfiguration, dresses it up as a critical finding, and asks — sometimes politely, sometimes not — for a “bounty” or “reward” before any details are shared.

That second category has a name: a beg bounty. This page sets out how we treat both, so nobody wastes their time — including you.

2. What a beg bounty is

A beg bounty is an email that leads with a demand for payment for a “finding” that is usually:

• discoverable in seconds by pointing an automated scanner at a public domain;
• a missing best-practice header or record rather than an exploitable flaw; and
• sent to a company that has never advertised a paid bug-bounty programme.

The tell is the ordering: a legitimate researcher tells you what’s wrong so you can fix it. A beg bounty withholds the detail — or pads out a scanner’s output with alarming language — until money is discussed. Friendliness isn’t evidence to the contrary; a warm tone is often part of the pitch.

3. What we will not pay for

We do not offer cash rewards, and the following in particular will be acknowledged with thanks at most. On their own, without a working exploit and a real-world impact, they are not vulnerabilities we will treat as such:

• missing or “weak” email records — SPF, DKIM, DMARC, BIMI — on any of our domains;
• missing security headers — CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, permissions policy, and friends;
• supported TLS versions or cipher suites, certificate details, or “your site accepts TLS 1.2”;
• software or framework version disclosure, banner grabbing, or a .well-known path existing;
• the absence of rate limiting, CAPTCHA, or DNSSEC where there is no demonstrated abuse;
• self-XSS, clickjacking on pages with no sensitive state-changing action, or missing cookie flags on non-sensitive cookies;
• “best-practice” or compliance findings with no demonstrated security impact, and the raw output of an automated scanner presented as a report; and
• reports about third parties we don’t control (for example our payment provider or CDN) — take those to them.

Many of these are deliberate trade-offs, already known to us, or handled at a layer you can’t see from the outside. A configuration being visible is not the same as it being a problem.

4. If your email leads with a demand

We won’t engage on those terms. Concretely:

• we do not negotiate payment in exchange for the details of a “finding”;
• we are not moved by deadlines, or by threats to publish, to notify our customers, or to post on social media — telling people what you claim to have found is your right, and pressuring us with it only tells us how to read the rest of your message; and
• invoices, crypto wallet addresses, and “consulting fees” attached to an unsolicited report go unpaid.

None of this is hostility toward security research. It’s the opposite: paying beg bounties funds the noise that makes it harder for real reports to be heard.

5. If you’ve actually found something

Then thank you, sincerely — we want to hear it, and we’ll take it seriously. A report that helps us is one that lets us reproduce and fix the issue:

• tell us the specific endpoint, URL, or flow, and the impact — what an attacker could actually do;
• include the steps to reproduce it, and a proof of concept if you have one;
• keep it to data and accounts that are yours, and don’t run anything that degrades the service or exposes other people’s information; and
• give us a reasonable window to fix it before any public write-up.

In return we’ll confirm receipt, keep you updated, fix what needs fixing, and — with your permission — credit you. We don’t run a paid bounty programme today, so please don’t expect a cash reward; genuine, high-impact reports that are new to us may earn our public thanks and a place in our acknowledgements. If that ever changes, we’ll say so here.

6. Good-faith safe harbour

If you make a good-faith effort to follow the guidance above — you don’t access more data than needed to demonstrate the issue, you don’t harm the service or its users, and you give us a chance to respond before going public — we will treat your research as authorised and will not pursue action against you for it. This is about honest, constructive disclosure; it does not cover extortion, data theft, or disruption.

7. How to report

Use the contact details in our security.txt, or email security@livingpage.app with “security” in the subject. Lead with the details, not the invoice, and we’ll take it from there.