If you have found a security problem in SendBeam, we want to hear about it, and this page tells you how. It is written for security researchers and for anyone who has stumbled across something that looks wrong. You do not need permission to report, you do not need an account, and you will not be asked to sign anything.
SendBeam sends email on behalf of other people and holds their subscriber lists, so a fault here can affect people who have never heard of us. We treat reports accordingly.
How to report
Email security@sendbeam.io. That is the fastest route and the one we prefer. If you would rather not use email, use the contact form and choose "Reporting a security issue".
You may report anonymously. If you do, give us some way to ask a follow-up question if you want one — a throwaway address is fine. We do not currently publish a PGP key; if you need to send us something that must be encrypted, say so in your first message and we will agree a method with you.
Please do not open a public issue on one of our repositories, and please do not post the details on social media before you have talked to us.
What to put in your report
- what you found, and what an attacker could do with it;
- the exact URL, endpoint or feature, and the steps to reproduce it;
- anything we need to see it ourselves — a request, a short script, a screenshot or a recording;
- the account, workspace or test address you used, so we can find your activity in our logs;
- the date and time you tested, with the time zone;
- whether anyone else knows, and whether you plan to publish.
Write in English if you can. One issue per report, please — separate problems in one email are easy to lose.
What you get back from us
- Acknowledgement within one working day. A person reads it, not a robot.
- An assessment within five working days: whether we could reproduce it, how serious we think it is, and what we intend to do.
- An update at least every fourteen days while the report is open, without you having to chase us.
- A fix within ninety days for anything we accept, and faster than that for anything serious. If we are going to miss that, we will tell you before we miss it, and say why.
- An answer either way. If we decide something is not a vulnerability, or that we are not going to fix it, we will tell you that and explain our reasoning rather than going quiet.
Working days are Monday to Friday, UK public holidays excepted. If a report shows customer data is exposed right now, we act on it the same day.
What is in scope
These are ours, and you may test them:
- sendbeam.io — the public site, the application and everything served from it;
- the API at
sendbeam.io/api, including the endpoints our client libraries use; - our hosted form pages and link-tracking endpoints, wherever they are embedded;
- the subdomains we operate for sending mail and for setting up customer domains;
- the client code we publish — our WordPress plugin, our Zapier app and our starter templates.
Anything not on that list is out of scope. If you think something of ours is missing from it, ask us before you test it and we will tell you.
What is not ours to authorise
Much of what looks like SendBeam belongs to our customers, and we cannot give you permission to test other people's property. Out of scope:
- customer sending domains and their DNS. A customer verifies their own domain with us; the domain, its records and its reputation are theirs;
- customer websites that happen to carry a SendBeam form, pop-up or tracked link. The site is theirs — report to them;
- the content customers send. If a SendBeam customer is sending something abusive, that is not a vulnerability report; email abuse@sendbeam.io and read our Acceptable Use Policy;
- our suppliers' own systems. Our hosting, database, payment and delivery providers run their own disclosure programmes; a fault in their product should go to them.
Some reports are about how the product is meant to work rather than a fault. Sending email from a verified domain, tracking opens and clicks for the customer who owns the campaign, and importing a list you have the right to import are all features. So are missing hardening headers with no demonstrated impact, findings from a scanner with no working proof, and reports about the mail configuration of domains we do not control. We will read those, but we will usually close them.
What you must not do
Stay within these and you stay inside the safe harbour below. Step outside them and you are on your own.
- Do not touch anyone else's data. Use your own account and your own test addresses. If a flaw exposes someone else's data, stop at the point you have proved it — take the smallest possible evidence, do not read further, do not download it, do not change or delete it, and do not keep a copy. Tell us what you saw and delete it.
- Do not pass anyone else's personal data to a third party, and do not publish it, redacted or otherwise.
- Do not send email to real people. This is a sending platform; a proof of concept that lands in a stranger's inbox is not a proof of concept.
- No denial of service. No load testing, no flooding, no resource exhaustion, no deliberately filling a queue.
- No automated scanning that degrades the service. Rate-limit yourself. If your tooling would page us at three in the morning, throttle it or ask us first.
- No social engineering. No phishing, no pretexting, no calls or messages to our staff, our customers or our suppliers.
- No physical attacks on offices, hardware or people.
- Do not degrade, disrupt or interrupt the service for anyone else, and do not leave anything behind — no backdoors, no persistence, no test accounts you do not tell us about.
- Do not extort us. A report conditional on payment is not a report.
Safe harbour
If you follow this policy, we will treat your testing as authorised. In plain terms, that means we will not report you to the police, we will not bring a claim against you, and we will not ask your employer, your host or your university to act against you. If a third party comes after you for research you did under this policy, tell us and we will make it known that your testing was authorised.
This is a promise about how we will behave. We cannot waive anyone else's rights, and we cannot promise anything on behalf of our customers or our suppliers — which is why the scope section above matters. If you are unsure whether something is allowed, ask first: an email to security@sendbeam.io costs you nothing and settles it.
Good faith is the test. Accidents happen during honest research, and going slightly further than you meant to before you stopped will not lose you the safe harbour, so long as you stop, tell us, and do not keep what you found.
There is no bounty
We do not pay for vulnerability reports. SendBeam is a small, self-funded company and we would rather tell you that plainly than run a programme we cannot fund properly. Nothing here is an offer of payment, and you should not report to us expecting one.
What you get instead is a fast, human answer, an honest assessment, a fix, and public credit if you want it. If that changes, this page changes with it.
Telling other people
We work to coordinated disclosure. Please give us ninety days from your first report, or until the fix is live, whichever comes first, before you publish. If you need longer for your own reasons, that is fine. If ninety days is not enough because the fix is genuinely hard, we will come and ask you, and explain why.
We will not ask you to sign a non-disclosure agreement as a condition of reporting, and we will not use this policy to keep a problem quiet indefinitely. When we publish a fix that mattered, we say so in our changelog. If a fault affected customer data, we tell the affected customers directly and, where the law requires it, the Information Commissioner's Office.
We would rather you published a good write-up with our fix in it than published nothing. Send us the draft if you like and we will check it for accuracy — that is an offer, not a condition.
Credit
If you want credit, say so in your report and tell us the name and link you want used. We will name you when we announce the fix. If you would rather stay anonymous, say that instead and we will keep you out of it. We will not name you without asking.
Where else this is published
This policy is the one referenced by our security.txt file, published under RFC 9116. That file lists our security contacts and points back here. If the two ever disagree, this page is the one that governs.
We review this policy at least once a year, and whenever we change the contacts or the timescales in it. The date it was last changed is at the top of the page.