At Swift Centre, the security of our systems and data is a priority. We value the security research community and recognise the part researchers play in finding problems before anyone else does. If you believe you have found a vulnerability in our systems, we'd like to hear about it.
This policy is published by Swift Centre Research Ltd (company number 14003610) on behalf of both Swift Centre companies, and covers swiftcentre.org, app.swiftcentre.org and the systems behind them, and any other service we operate under the swiftcentre.org domain. Reports about Swift Centre Advisory Ltd (company number 17015645) are welcome here too and are handled under the same terms.
Reporting a vulnerability
Send your finding to info@swiftcentre.org with as much detail as you can:
- what the vulnerability is
- how to reproduce it
- what someone could do with it
- any proof-of-concept code or screenshots, if you have them
Please give us reasonable time to fix the issue before making it public.
What we commit to
- We will not take legal action against you provided you follow this policy.
- We will acknowledge your report within five working days, and keep you informed as we work on it.
- We will credit you publicly for the find, if you'd like us to.
Rules of engagement
- Don't do anything that could damage or interrupt our systems, data or services.
- Don't modify or delete data that isn't yours.
- Don't run automated scanning that generates significant load.
- Don't use social engineering, phishing or physical attacks against our staff or offices.
How far to go when you find something
We ask for demonstrated impact, and we also ask you to stop early. Those pull in opposite directions, so here is where we draw the line.
Establish what is exposed and roughly how much, then stop. Enough to show a real problem — the shape of the data, an approximate count, one or two records as proof — is what we need, and it is enough for a report to be in scope. Going further is not.
- Do: confirm the class of data reachable, estimate the scale, and keep a minimal sample.
- Don't: download or retain the full set, catalogue individuals, or use what you find to reach anything else.
- If in doubt, stop and ask. Tell us what you have found and what you would need to do to prove it, and we will tell you whether to go on. A report that stops at "I could read records here, and stopped" will not be rejected for lack of proof.
If you do hold personal data at the end of your testing, tell us what you have and delete it once we confirm the finding. If you create anything in our systems while testing — accounts, workspaces, records — list it in your report so we can remove it.
Recognition
If you responsibly disclose a valid security issue, we may offer a reward as a token of thanks. We decide this case by case, based on how serious the issue is and the quality of the report. There is no fixed scheme and no guarantee of payment.
Out of scope
Reports that describe theoretical problems with no demonstrated impact, findings from automated scanners without analysis, and issues in third-party services we don't control are generally out of scope — though if you're not sure, send it anyway and we'll take a look.
"No demonstrated impact" means the report does not show the problem is real. It does not mean you stopped early: a finding you deliberately left unexplored under the section above is in scope, and we would rather have that than a complete extract.
Missing hardening measures that carry no demonstrated consequence for us — an absent CAA record, a missing security header, a long value accepted by an input field — are generally out of scope on their own. We are still glad to hear about them; they simply aren't treated as vulnerabilities.