Responsible disclosure

Last updated: 20 October 2026

1. Introduction

People trust us with their own details, their handwriting and the names and addresses of the people they write to. If you think you've found a security vulnerability in Snailgram, we want to hear about it. This policy explains how to report one, the rules we ask you to follow while looking, and what we'll do in return.

It's published by AWS, CYY & Co. Pty Ltd (ACN 686 116 245) as trustee for Mumu, Lulu & Co. (ABN 54 837 123 965), which runs Snailgram.

We don't run a paid bug bounty and don't pay rewards for reports. With your permission, we'll thank you by name on this page once the issue is fixed.

2. Scope

This policy covers:

• our website at snailgram.com.au, including the card studio and checkout,
• the services behind it that make covers, store designs and handwriting samples, and take orders, and
• the emails we send about orders.

It doesn't cover services run by others that we use, such as Square, Australia Post, Amazon Web Services, Fastmail or Google. Please report issues in those to the provider concerned.

3. How to report

Email support@snailgram.com.au with "Security" in the subject line. Please include:

• a description of the issue and the impact you think it has,
• the page, endpoint or feature affected,
• step-by-step instructions to reproduce it, with any proof-of-concept code, screenshots or requests, and
• how we can contact you, and whether you'd like to be thanked by name.

If you find an exposed key, password or other secret, tell us straight away and don't use it. Please write in English if you can.

4. What we ask of you

When looking for and reporting a vulnerability, you must:

• test only with orders, designs and handwriting samples that are your own, or that you have the owner's permission to use,
• stop as soon as you reach personal information, messages, addresses or handwriting that aren't yours, and tell us what you accessed. Don't copy, keep, change or delete it, or share it with anyone,
• not degrade or interrupt the site, including by denial-of-service attacks, load testing or high-volume automated scanning,
• not order cards to anyone without their consent, or contact our customers, the people they write to or our team,
• not use social engineering, phishing or physical attacks against our team, premises or providers,
• not use another person's payment card or details,
• do only what's needed to show that the vulnerability exists,
• keep the details confidential until we've fixed the issue, or until 90 days after your report, whichever is sooner, unless we agree otherwise with you, and
• comply with the law.

5. What we'll do

When you report a vulnerability under this policy, we'll:

• acknowledge your report within 2 business days,
• tell you whether we can reproduce the issue, and keep you updated on our progress,
• aim to fix a confirmed vulnerability within 90 days, and sooner where it puts personal information at risk, and
• tell you when the issue is fixed, and thank you by name if you've asked us to.

If the issue involved personal information, we'll assess it and notify the people affected and the Office of the Australian Information Commissioner, as section 11 of our privacy policy describes.

6. Safe harbour

If you act in good faith and follow this policy, we'll treat your research as authorised, won't take legal action against you over it and won't report you to law enforcement. If someone else takes legal action against you for research that followed this policy, we'll make it known that we authorised it.

This doesn't apply if you've broken this policy, accessed more than you needed to, or asked for payment in exchange for not disclosing an issue. If you're unsure whether something you plan to do is allowed, ask us first at support@snailgram.com.au.

7. What we don't treat as a vulnerability

The following are generally outside this policy, unless you can show a real impact on the security of the site or the people who use it:

• reports from automated scanners without a working proof of concept,
• missing security headers, cookie flags or email authentication records (SPF, DKIM, DMARC) on their own,
• clickjacking on pages with no action that could cause harm,
• self-XSS, or issues that need physical access to someone's unlocked device,
• getting the cover generator to make an unexpected or unsuitable image, unless it exposes someone else's data or bypasses payment,
• software version disclosure, or missing rate limits on actions with no security consequence, and
• denial of service, and vulnerabilities in the third-party services listed in section 2.

8. Changes to this policy

We may change this policy by publishing a new version on this page and updating the date at the top. The version published when you make a report applies to that report.