How we protect data
Everything we hold is encrypted in transit and at rest. Access to production data is restricted to named individuals on a least-privilege basis and requires authentication for every administrative action. Each customer's data is logically separated from every other customer's. Credentials and signing material are held in a dedicated secret store, never written to logs or responses, and can be rotated on demand or after any suspected exposure.
Two design decisions do more for security than any of that. Admission passes are signed and single-use, and they are verified by the adapter running inside your own stack — so a pass cannot be forged, shared or replayed, and checking one does not involve a call to us. And your shoppers' traffic never routes through our infrastructure: we do not sit in front of your store, so we are not a place where it can be intercepted or taken down.
We collect the minimum needed to decide a queue position, and hold it no longer than that decision and its audit require. What that is in detail is set out in the Data Processing Agreement.
Certifications
We do not hold a SOC 2, ISO 27001 or comparable third-party certification. We would rather say so than imply otherwise. If that changes, it will be stated here.
Cookies
This website sets no cookies at all. There is no analytics script, no tag manager, no advertising pixel and no third-party embed on dropify.dev — which is why you were not asked to dismiss a consent banner to read this page.
Two other places do set cookies, both strictly functional:
- The waiting room and your store. When a shopper joins a queue, a small number of cookies hold their place in line and carry their admission pass to your store. They contain no profile and no identifier that follows anyone between sites, and none of them is read by an analytics or advertising network — there are no third-party trackers in the waiting room at all.
- The dashboard. A session cookie keeps you signed in at app.dropify.dev. It is set on that domain only.
The queue cookies are set on your own domain, not ours. That makes them yours to disclose: they belong in your cookie statement alongside everything else your shop sets, and we cannot make that statement on your behalf. They are strictly necessary for a service the shopper has actively requested, which under article 5(3) of the ePrivacy Directive means they do not require consent — but the disclosure obligation is still yours, and how you word it depends on the rest of your shop.
Reporting a vulnerability
If you believe you have found a security vulnerability — in the hosted service, the dashboard, the waiting room or any of the open-source adapters — report it to security@dropify.dev. Tell us what is affected, how to reproduce it, and what you think the impact is. A working proof of concept helps; a scanner report with no analysis usually does not.
- We acknowledge every report within 72 hours.
- We will tell you what we intend to do about it, and when it is fixed.
- Please give us reasonable time to investigate and remediate before disclosing publicly. We are happy to credit you when we do.
We do not currently run a paid bug bounty.
Safe harbour
We will not pursue legal action over security research carried out in good faith under this policy, and we will say so to anyone who asks. In return, while testing:
- do not access, modify or delete data belonging to another customer or to a shopper — if you need to prove access is possible, stop at the point where that is demonstrated;
- do not degrade the service for anyone else, and do not run volumetric or denial-of-service tests;
- do not use social engineering, phishing or physical attacks against our staff or suppliers;
- report what you find to us rather than to a third party, and give us a chance to respond before going public.
Findings that concern our infrastructure provider rather than us are better sent to them directly; tell us as well and we will help route it.
Contact
Security reports: security@dropify.dev
Privacy questions: privacy@dropify.dev