Security and vulnerability disclosure

Email jack.spence@musketgoose.com. Put "security" in the subject line and it will be read the same day it arrives, including at a weekend.

Tell us what you found, where, and how to reproduce it. A short description with the exact request or the exact steps is worth more than a scanner report, and we would rather have two paragraphs today than a formal write up next month.

You do not need to know how serious it is. Send it anyway and let us work that out.

• What the issue is, in your own words.
• The URL, endpoint or page where it happens.
• The steps to reproduce it, or the request that triggers it.
• What an attacker could do with it, if you know.
• How you would like to be credited, or whether you would rather not be.

If you report a vulnerability in good faith and follow this policy, we will not take legal action against you, we will not report you to the authorities for it, and we will not ask your employer to.

That undertaking is the point of this page. South Africa's Cybercrimes Act 19 of 2020 makes unauthorised access an offence, and without written authorisation an honest researcher is taking a real risk to tell us something we need to know. This page is that authorisation, within the scope below.

• We will acknowledge your report within two working days.
• We will tell you whether we consider it a vulnerability, and why, within ten working days.
• We will keep you updated while we fix it, and tell you when it is fixed.
• We will credit you if you would like to be credited, and stay quiet about you if you would not.
• We will not ask you to sign a non-disclosure agreement as a condition of us fixing it.

Systems we own and run:

• https://musketgoose.com and everything on it, including the operator platform at /dashboard and the sign in page.
• Our published DNS and email configuration.

• Use only accounts you own, or test data you created.
• Stop as soon as you have confirmed a vulnerability. Do not go further into the system to see how far you can get.
• Do not access, download, alter or delete anyone else's data. If you come across personal information by accident, stop, tell us, and delete what you have.
• Do not run denial of service tests, and keep automated traffic to a rate the site can absorb.
• Give us a reasonable time to fix it before telling anyone else. Ninety days is the norm and we will usually be much faster. If we disagree about timing, say so and we will work it out.
• Do not ask for payment in exchange for the details of a vulnerability. We do not run a bug bounty, and a report conditioned on payment is not a good faith report.

There is no reward programme, and we would rather say so plainly than leave you to find out after you have done the work.

What we do offer is a fast, straight answer from the people who wrote the code, credit if you want it, and a reference if it would be useful to you.

So that you know what to expect before you start looking.

• Every account has a role, and permission is checked on the server for every request rather than only in the interface.
• Passwords are stored as hashes. Sessions are signed, HttpOnly cookies backed by server side records, so a session can be revoked centrally.
• Failed sign in attempts are rate limited and locked out.
• IP addresses in audit and session records are hashed before storage.
• Actions inside the platform are written to an audit log with sensitive values redacted.
• Credentials for third party services are held in the environment and never in the database.
• The password vault is encrypted in the browser, so the server stores ciphertext it cannot read.

Where a vulnerability has actually exposed personal information, section 22 of the Protection of Personal Information Act requires us to notify the Information Regulator and the people affected as soon as reasonably possible. We will, and our privacy notice sets out what that notification contains.

Reporting a vulnerability to us does not make you responsible for that notification. It is ours.

These contact details are also published in machine readable form at https://musketgoose.com/.well-known/security.txt, following RFC 9116.

That file expires on 30 June 2027. The expiry is deliberate: it forces somebody here to confirm the address still reaches a person, rather than leaving a stale contact on the internet for years. A test fails our build before the date arrives.