How we protect your data, what we hold, and how to reach us with questions, security findings, or compliance requests.
The architectural advantage
Most JAD tools run entirely in your browser. Files you upload to a tool are decoded, transformed, and re-encoded locally — they never travel to a JAD server. This isn't a privacy policy; it's a property of how the tools are built. We can't leak data we never receive.
The exceptions are deliberate and listed in the Privacy Policy: your account profile, your subscription record, and metadata about which tools you've run (tool name, file size, duration — never file contents).
What we run on
- Cloudflare Pages — TLS 1.3, automatic HTTPS, global edge deployment. We use HSTS with a 2-year max-age and the preload list.
- Supabase (Postgres) — managed Postgres in the EU region by default. RLS is enabled on every table; the application talks via the service-role key over HTTPS, never via raw TCP.
- Stripe Payments Europe — we never see card numbers. PCI scope is limited to forwarding the customer to Stripe-hosted Checkout.
- Resend — for transactional email. Encrypted in transit; we keep a 90-day delivery audit log.
- Auth.js (next-auth) — Google OAuth + JWT sessions. The session JWT is encrypted with
AUTH_SECRET and never decoded client-side.
Defence layers
- Webhook idempotency — every Stripe event is dedupe-checked against a server-side reservation table before side effects run.
- Rate limiting — atomic per-key hourly caps via a Postgres function, with
X-RateLimit-* headers on every response. - Constant-time comparisons — API key hashes, runner pair-poll secrets, and cron secrets all compare via XOR-reduce so timing can't leak prefixes.
- Encrypted at rest — runner refresh tokens are AES-256-GCM-encrypted with a server-only key before any database write.
- Short-lived JWTs — runner access tokens expire every 15 minutes; the refresh round-trip re-checks tier against the live subscription.
- CSP, HSTS, frame-ancestors — every response ships with a strict Content-Security-Policy, HSTS preload, and X-Frame-Options DENY.
Reporting a vulnerability
Found something? Email [email protected] with as much detail as you can: reproduction steps, the impact you observed, and the JAD account email you used (if any). PGP / S/MIME isn't set up yet; for sensitive findings, ask in the email thread and we'll arrange a secure channel.
Our /.well-known/security.txt is the canonical machine-readable contact.
What you can expect from us
- Acknowledgement within 2 business days.
- An initial assessment (impact, severity, our remediation plan) within 5 business days.
- We won't take legal action against good-faith research that respects user privacy and avoids degrading the service.
- We're a small team and don't currently run a paid bounty programme — but we will credit reporters in our changelog if you'd like.
What we ask of you
- Don't test against accounts you don't own.
- Don't exfiltrate, modify, or destroy customer data.
- Give us a reasonable disclosure window before going public.
- No DoS, brute-force, or social-engineering attacks against our staff or customers.
For B2B customers
For DPAs, sub-processor lists, or completed security questionnaires (CAIQ, SIG, custom), email [email protected]. We respond to every questionnaire within 10 business days.
We don't currently hold SOC 2 or ISO 27001 certifications. That's on the roadmap once team size warrants the audit cost; in the meantime our architecture (browser-local processing, no file upload) often answers the questionnaire questions differently from a typical SaaS.
Status & transparency
Health probe: /api/health — a public JSON endpoint suitable for uptime monitors. A customer-facing status page is on the roadmap; in the meantime, material security incidents are disclosed by email to affected customers and on the changelog.
Contact
Operated by JAD Apps. General questions go to [email protected]; security findings to [email protected]; data-protection / DSAR enquiries to [email protected].