Security & Vulnerability Disclosure Policy

#1. Reporting

Email security@vevarte.com. Please include what you found, where, how to reproduce it, and what an attacker could do with it. A proof of concept helps enormously; a scanner report pasted in full does not.

You do not need an account, a prior relationship or a legal introduction. Report anonymously if you prefer — we would still like to credit you, but it is not a condition.

#2. Scope

In scope: vevarte.com and its subdomains, the Cloud Functions API, our Firestore security rules, and our published DNS and email authentication records.

Out of scope: anything hosted by a third party (Google, Meta, our payment provider — report those to them, they run bounty programmes and we do not), our physical premises, our staff, and any test requiring social engineering.

Firestore security rules are the interesting target and we will say so plainly: with no customer accounts, the rules are the only thing standing between the data and the internet. A rule that lets an unauthenticated read reach an order document is the highest-value finding on this site, and we would very much like to hear about it before someone else does.

#3. Rules of engagement

• Use only test data. Create your own order with your own details rather than probing a real one.
• If you do encounter someone else's personal data, stop immediately, do not save it, do not screenshot beyond what proves the issue, and tell us in the report. Continuing to enumerate after the first record is where research becomes something else.
• Do not degrade the service. No load testing, no denial of service, no automated scanning at volume — the site serves a real shop and a stress test at 3pm on a Saturday is indistinguishable from an attack.
• Do not alter or delete data, and do not install anything persistent.
• No social engineering of our staff, customers or suppliers. No phishing, no pretexting, no calling the showroom pretending to be from Google.
• No physical intrusion.
• Give us reasonable time to fix it before publishing — see section 5.

#4. Safe harbour

Research conducted in good faith and within this policy is authorised access for the purposes of the Prevention of Electronic Crimes Act 2016 and any equivalent law. Specifically, we commit that:

• We will not bring or support a civil claim against you.
• We will not refer you to law enforcement.
• If a third party brings action against you for research within this policy, we will make it publicly known that your activity was authorised.
• We will not ask you to sign a non-disclosure agreement as a condition of reporting, and we will not use a bounty as a lever to buy silence.

This authorisation ends if you go outside the rules in section 3 — in particular if you exfiltrate customer data, extort us, or sell the finding to somebody else. It is a genuine safe harbour, not a trap, and it exists because the alternative is that people who find problems on our site say nothing.

#5. Coordinated disclosure and credit

Please give us 90 days before publishing, or until a fix is deployed if that comes sooner. We will not use that period to stall, and if we need longer for something genuinely complicated we will tell you why and agree a date rather than going quiet.

We are happy for you to publish afterwards, and we will not ask you to remove a write-up. We ask only that you leave out customer data and anything that would help someone attack a system we have not finished fixing.

We credit researchers by name or handle, as you prefer, in our security acknowledgements. We do not currently run a paid bounty programme — we are a furniture shop — but where a report is genuinely serious we would like to thank you properly, and we will ask what would be useful. Sometimes that has been a chair.

#6. What we do on our side

• Security rules are written and tested before the data they protect exists, not retrofitted afterwards.
• All traffic is TLS-encrypted; data is encrypted at rest.
• Secrets live server-side in Cloud Functions configuration and are never present in anything a browser downloads. Credentials are gitignored, and the gitignore was proven with real test files before any credential existed.
• Order totals are recalculated server-side; no browser is trusted with a price.
• Staff roles are enforced in the database, not in the interface. A cashier typing an accounts URL is refused by Firestore itself.
• Actions on money, stock and permissions are written to an audit log.
• Dependencies are reviewed and updated; the dependency list is deliberately small.

If a breach affects personal data we will notify the appropriate authority within 72 hours of becoming aware and tell affected people directly — the commitment is in section 10 of the Privacy Policy and this document does not dilute it.