Security
How this shop is built to protect your data, and how to tell us if you find a hole in it.
Reporting a vulnerability
Email security@synthbridge.net. Include what you found, how to reproduce it, and what you think the impact is. The machine-readable version of this section is at /.well-known/security.txt.
| Acknowledgement | Within 3 business days. |
|---|---|
| Triage | Within 10 business days, with our assessment of severity. |
| Fix | Critical issues inside 7 days. Everything else on a schedule we agree with you. |
| Credit | Named on our acknowledgements page, if you want to be. |
| Legal | We will not pursue anyone who reports in good faith and follows the rules below. |
Rules for testing
- Test against your own account, your own orders and your own data.
- No denial of service, no load testing, no spam, no social engineering of staff or customers.
- Do not access, modify or keep anyone else's data. If you reach some by accident, stop and tell us.
- Give us a reasonable chance to fix it before you publish.
How the shop is built
| Card data | Never touches our servers. The card field is hosted by a PCI DSS Level 1 payment processor and runs in their frame. We are eligible for SAQ A because of that architecture, not because of a policy document. |
|---|---|
| In transit | TLS everywhere, HSTS with a two-year max-age and preload. |
| At rest | Customer records are held in encrypted managed storage under SOC 2 Type II certified infrastructure. |
| Prices | Every amount charged is recomputed on our servers from our own records at the moment of payment. A price, a discount or a shipping cost sent by a browser is ignored. |
| Stock | Overselling is prevented by a database constraint, not by application logic. The last unit of anything can only be sold once, whatever two simultaneous shoppers do. |
| Content security | A content security policy without unsafe-inline on scripts. This site has no inline script anywhere, which is what makes that possible. |
| Admin access | Role-based, least privilege, with step-up re-authentication before anything touching payment keys. Every change writes an audit row naming who did it and when. |
| Personal data in logs | Email addresses, phone numbers and IP addresses are hashed with a secret key before anything is written down. Our logs cannot be turned back into a customer list. |
| Rate limiting | Per-endpoint, counted server-side. Authentication and payment paths fail closed. |
| Images | Served through opaque ids. Storage keys never appear in a URL, so they cannot be guessed or walked. |
What we would tell you about
If customer data were exposed, we would write to everyone affected with what happened, what was taken, what we have done and what you should do. We would do that inside 72 hours of confirming it, and we would publish a post-mortem afterwards.
Out of scope
Reports generated by an automated scanner with no demonstrated impact, missing headers on pages that hold nothing, rate limits on public catalogue reads, and issues in third-party services we do not control (report those to the vendor). Social-engineering findings are out of scope by definition.