Good faith security disclosure

01Our commitment

We hold passports, transcripts and payment records for people applying to study abroad. Anyone who takes the time to find a weakness in how we protect that material and tells us about it is doing our applicants a favour, and we treat them that way.

If you find a vulnerability, report it and we will work with you on it. We acknowledge every report, we tell you what we found, we tell you when it is fixed, and we credit you if you want the credit. What we ask in return is that you test without causing harm and keep the finding to yourself until we have shipped a fix.

02Safe harbour

If you follow this policy in good faith, we consider your research authorised. We will not bring or support legal action against you over it, and we will not report it as an attack.

If someone else raises a claim about testing that followed this policy, we will make it clear that you were acting with our authorisation. If you are unsure whether something you plan to do is within the rules, ask us first and we will answer.

This protection depends on staying inside the rules below. Testing that destroys data, takes data, breaks the service for applicants, or goes public before a fix sits outside it.

03What is in scope

Findings we care about most: anything that crosses a tenant or ownership boundary, anything that reaches a document or a record belonging to someone else, authentication and session weaknesses, injection, broken access control on a mutation, and anything that lets a payment be marked as paid without paying.

• The public website and everything it serves.
• The student portal, including eligibility, applications, documents and payment flows.
• The university portal and its access boundaries.
• Our own APIs and webhook endpoints.
• Any subdomain we operate that serves the product.

04What is out of scope

• Denial of service, load testing, stress testing and anything that degrades the service for applicants.
• Social engineering of our staff, applicants or suppliers, and any form of phishing.
• Physical attacks against offices, people or hardware.
• Findings in a third party service we merely use, which belong in that provider's own programme.
• Reports produced by a scanner with no demonstrated impact, including missing headers, cookie flags and version numbers on their own.
• Self inflicted issues that need the victim to paste code into their own console, and attacks that need a device that is already compromised.
• Weaknesses that need a user to be running an unsupported or unpatched browser.
• Rate limiting observations with no demonstrated abuse, and reports about email deliverability records with no exploitation path.

05Rules of engagement

These rules are not negotiable, and they are what safe harbour depends on.

• Test without destruction. Do not delete, alter, encrypt or corrupt anything, and do not leave anything behind.
• Use accounts you created for testing. Do not use an applicant's account, and do not attempt to take one over.
• Stop at proof. The moment a finding gives you access to another person's data, stop, record only what is needed to show the issue exists, and report it.
• Take nothing. Do not download, copy, retain or share personal data, documents, credentials or database contents.
• Do not pivot. Do not move deeper into our systems, install a shell, add persistence or scan other hosts from ours.
• Keep the volume low. No automated flooding, no brute force at scale, no traffic that would affect a real applicant.
• Do not interfere with live applications, payments or messages belonging to anyone else.
• Delete any data you did come across as soon as the report is filed, and tell us that you did.

06Non disclosure

A finding stays confidential until we tell you a fix has shipped and we agree in writing that it can be discussed. This covers the finding itself, any part of it, and anything you saw while investigating it.

That means no blog posts, no conference talks, no social media, no screenshots, no proof of concept code and no sharing with a third party or another programme, in whole or in part, without our written permission.

We do not use this to bury problems. We will agree a disclosure timeline with you, we aim to fix serious findings quickly, and once the fix is out we are happy for you to write about it with the details we agree.

Any personal data you encountered is never publishable, before or after a fix, under any circumstances.

07What happens after you report

• We acknowledge the report within three working days.
• We triage it, reproduce it and set a severity, and we tell you what we concluded.
• We keep you updated while the fix is built, and we tell you when it ships.
• We will ask you to confirm the fix resolves what you found.
• If we judge something out of scope or already known, we say so plainly and explain why.

08Recognition

We do not run a paid bounty programme. What we offer is a fast, honest response, a fix, and public credit in the name or handle you choose once the fix has shipped. If you would rather not be named, that is fine too: say so and we will keep you out of it.

09Reporting a finding

Use the form below. One finding per report, with the steps we need to reproduce it. You do not need an account, and we reply to the address you give us.

If a finding is being actively exploited, say so in the first line of the summary and we will treat it as an incident.