Security & cybersecurity

The realistic threats to a platform like this one are not exotic. In rough order of how likely they are to matter:

• One customer reaching another customer's data. The highest-cost failure available to us, because the people harmed are clients who never chose us. It is defended in the database rather than the application, so an application bug is not enough to cause it.
• Account takeover through a stolen, reused or guessed password. Defended with rate limiting on sign-in, bot protection on account creation, and session material the browser's scripts cannot read.
• Injected scripts running in a signed-in page and reading what is on screen. Defended by sanitising everything a user submits before it is rendered, and by a Content Security Policy that names the only hosts permitted to run code.
• A compromised or malicious dependency. Defended by auditing dependencies on every push and on a schedule, and by the script policy above, which refuses code from hosts we have not named even if something in our own bundle asks for it.
• Leaked credentials. Defended by keeping secrets out of source code entirely, scanning every commit and every scheduled build for them, and refusing a commit that contains one.
• Forged payment events. Defended by verifying the cryptographic signature on every message from our payment provider before acting on it.

Type checking, linting, a secret scan and the automated tests covering the changed code run when a change is committed and again in continuous integration on every push. The production branch cannot be force-pushed or deleted, and that restriction has no bypass for anyone, including us. How far each of those gates reaches, and what they do not do, is set out in section 04 of our Information security policy.

Server endpoints check their input, confirm who is asking, and confirm that person is entitled to the record they named - in that order. Ownership is never taken from a claim made by the browser.

Application errors are reported to a monitoring service with personal information stripped and on-screen text masked. Administrative actions on our operations console are recorded.

When something looks wrong we investigate the mechanism rather than the symptom, and where an incident affects information we hold, our Data breach response policy governs what happens next.

If you find a security issue, tell us at support@buyersagents.com.au. Include enough detail to reproduce it.

We will acknowledge your report, keep you informed, and will not pursue action against anyone who reports a genuine issue in good faith - provided you do not access, alter, destroy or retain other people's data, degrade the service for others, or disclose the issue publicly before we have had a reasonable opportunity to fix it.

We do not currently run a paid bug bounty.

Some of the boundary is yours, and no control we build reaches across it. Use a strong password you have not used elsewhere. Do not share your login. Tell us immediately if you think your account has been accessed by someone else.

If you connect your own mailbox or calendar, you are granting this platform access to that account. You can withdraw it at any time from your integration settings, or from your email provider's own security page.

No system is perfectly secure, and we do not claim otherwise. We hold no third-party security certification. Where this policy describes a control it is because we operate it, not because it has been audited by someone else.

This policy is reviewed when the platform changes materially, and at least annually. The effective date at the top is the version you are reading.