Skip to main content

Security

Banksia holds business contact details and the findings of website assessments. This page sets out the controls we hold ourselves to, and how to reach us if you find a problem. We describe what we protect and how we respond rather than the internals of how the platform is built — that detail helps an attacker more than it helps you.

Access control

  • Every request is authorised on the server. Hiding a link is never treated as a permission check.
  • Customer data is separated by organisation, and that separation is enforced on each individual query rather than once at the page level.
  • Staff accounts are held to a higher bar than customer accounts, including mandatory multi-factor authentication.
  • Access follows least privilege and is reviewed when someone changes role or leaves.

Accounts and sign-in

  • Passwords are stored only as salted, computationally expensive hashes — never in a readable form.
  • Multi-factor authentication is available to every account, via authenticator apps, single-use recovery codes, or passkeys.
  • Sessions use HTTP-only cookies that are not readable by page scripts, and can be revoked.
  • Public forms are filtered for automated abuse before any work is performed, and a failed check stops the request rather than logging it and continuing.

What we collect, and what we don't

  • Assessments read only what a website already publishes to the public. We never ask for, and do not want, credentials or administrative access to your site.
  • Reports are delivered against a single-use link, marked private so shared caches and proxies will not retain them, and are never placed on a publicly listed URL.
  • Production is never seeded with fabricated or sample customer data.
  • Reports state plainly which signals are experimental. We do not claim to guarantee search rankings or AI citations.

Monitoring and change control

  • Security-relevant actions are written to an audit trail that records who did what, and when.
  • Passwords, tokens, cookies and authorisation headers are stripped from logs before they are written, not after.
  • Every change must pass automated linting, type checking and a full production build before it can ship, and container images are published from that pipeline rather than built by hand.
  • Dependencies are patched on a regular cadence, and out of cycle for high-severity advisories.

Hosting and encryption

Banksia is served over HTTPS, and we require encryption in transit for production traffic. Where we are responsible for a deployment, data is held on encrypted storage and access to it is restricted to the people who need it. The service providers that handle personal information — what each one receives and where it processes it — are listed at Subprocessors. If you need written detail about hosting location or retention for a procurement or vendor assessment, contact us and we will provide it.

If you would rather we did not assess your site

We fetch public pages of a website when someone asks us to. If you own a site and would prefer we did not, you can ask us to stop. We confirm the request through an address at the domain, then refuse every later request to assess it and keep a record that we did. We also decline to assess domains on our own blocklist, and we do not tell a requester which of those applies.

Reporting a vulnerability

If you believe you have found a security issue, email [email protected] with enough detail for us to reproduce it. We will acknowledge your report within two business days and keep you updated until it is resolved. Please give us a reasonable opportunity to fix the issue before disclosing it publicly, and while testing please avoid privacy violations, service degradation, and accessing data that is not your own. We will not pursue action against researchers acting in good faith under these terms.

See our Privacy Policy for what we collect and why, our Subprocessors list for who else handles it, and our Terms of Service for the commitments attached to using Banksia.