Security & incident response

1. Scope

This policy covers the Snaptare backend (api.snaptare.app), the tablet PWA (app.snaptare.app), the marketing site (www.snaptare.app), and the supporting infrastructure operated by Petitgen Ltd. It does not cover Shopify's own platform, which has its own privacy and security commitments to merchants.

2. What a security incident is

For Snaptare, an incident is any of:

• Unauthorised access to merchant data (or credible suspicion of it).
• Loss, leak, or unauthorised disclosure of OAuth access tokens.
• An exploited vulnerability in our application, infrastructure, or a sub-processor that affects merchant data.
• Sustained denial of service that prevents merchants ringing sales.
• Compromise of a maintainer's credentials, signing keys, or deployment access.

Bugs that affect functionality but don't put data at risk (a layout glitch, a slow query, a flaky webhook) are not security incidents — they're handled via the normal support and engineering queue.

3. Severity tiers and response times

4. Who responds

Snaptare is operated by a small founder team. The on-call responder is Sébastien Mathieu (reach via [email protected]), reachable 24/7 for SEV-1 reports. We do not yet operate a tiered on-call rotation; we will publish one here when the team grows past a single responder. We log every reported incident and its disposition, even if it turns out to be a false alarm.

5. What we do when an incident is confirmed

1. Contain. Revoke compromised credentials, rotate API keys and OAuth secrets, block hostile traffic at the edge, and disable affected code paths if needed. We always have the ability to roll a deployment back within minutes.
2. Assess. Determine what data, if any, was accessed or exfiltrated; which merchants are affected; and the root cause. Pull audit logs, webhook delivery logs, and Postgres query logs to build a timeline.
3. Notify. See §6 for who gets told, on what timetable.
4. Remediate. Ship the fix and re-deploy. Re-run the Shopify automated checks to confirm we're still passing the platform's compliance gates.
5. Review. Within 14 days of resolution, run a blameless post-mortem and write up: timeline, root cause, what worked, what didn't, and the concrete changes we're making so it can't recur. The write-up is shared with affected merchants on request.

6. Notification — who we tell, and when

• Affected merchants: within 72 hours of confirming an incident that affects them, by email to the merchant contact on file, with a plain-English summary, what data was involved, what we did, and what they should do (if anything). We update merchants again when containment and remediation are complete.
• End customers of affected merchants: end-customer data is the merchant's data under GDPR. We give the merchant everything they need to make their own notifications. We don't contact a merchant's customers directly.
• Regulators: if an incident triggers GDPR Art. 33, we notify the lead supervisory authority within 72 hours of becoming aware of it (or document why we chose not to). For incidents involving New Zealand merchants under the Privacy Act 2020, we follow the Privacy Commissioner's notifiable-breach guidance.
• Shopify: per the Shopify Partner Program Agreement we notify Shopify of any incident affecting data accessed via their APIs.
• The public: for incidents large enough to warrant it, we publish a public post-mortem on this site. We do not publish a post-mortem for incidents that affected only one or two merchants — those get a private write-up instead.

7. Preventive controls

• TLS everywhere. All traffic to api.snaptare.app and www.snaptare.app is TLS 1.2+ with HSTS preload.
• Encryption at rest. The Postgres database is on encrypted storage at Hetzner (EU). Daily snapshot backups inherit that encryption.
• Least-privilege OAuth scopes. We only request the Shopify scopes we actually use, listed in the privacy policy §2.
• HMAC-verified webhooks. Every Shopify webhook is HMAC-verified with a constant-time comparison before any handler logic runs.
• Session-token authentication. All tablet PWA requests carry a session token; the backend rejects unsigned or expired tokens.
• No card data, ever. Snaptare never sees card numbers. Payments are recorded against a manual Shopify gateway by the operator.
• Audit log. Every webhook delivery and protected data action is recorded in an append-only audit log, retained for 30 days then purged.
• Separate environments. Production and staging run on separate hosts with separate databases and separate Shopify app records.
• Dependency hygiene. Dependabot is enabled on the repository; security advisories are triaged within 7 days.
• Code review. Changes ship via pull request with at least one reviewer (human or AI) before merge.

8. Data minimisation as a security control

The strongest control we have is the data we don't hold. Snaptare does not persist end-customer profiles — customer search results vanish from memory the moment the search modal closes, and the only end-customer reference saved is the Shopify customer ID attached to a draft order, which Shopify already owns. See the privacy policy §3 for the full picture.

9. Reporting a vulnerability (responsible disclosure)

If you believe you've found a security issue in Snaptare, please email [email protected] with:

• A description of the issue and where you found it.
• The steps needed to reproduce it.
• The impact you believe it has.
• Your name (or a handle) so we can credit you if you'd like.

We will acknowledge your report within 1 business day and aim to confirm or refute the finding within 5 business days. Please do not test against merchant production stores, do not access data that isn't yours, and do not publicly disclose the issue before we've had a chance to fix it. We don't currently run a paid bounty programme — we'll credit responsible reporters publicly with their permission.

10. Third-party security audits

We have not yet undergone a SOC 2, ISO 27001, or equivalent third-party audit. Snaptare is in pre-launch; we'll commission a SOC 2 Type I readiness review once usage justifies the cost. In the meantime, the controls above are independently verifiable by reading the source code (the backend is open to merchants on request) and by inspecting our public infrastructure (TLS, HSTS, and the live HMAC-rejection behaviour at api.snaptare.app/webhook).

11. Changes to this policy

We update this page whenever our security posture materially changes. The revision date at the top of the page reflects the most recent update.

12. Contact

Petitgen Ltd
Security issues: [email protected]
General: [email protected]