Smart Order Capture
Legal

Security & Vulnerability Disclosure

Last updated: 2026-05-16

Pre-launch placeholder. This document has not yet been reviewed by counsel and is published so the user-facing flow exists end-to-end. The final version, signed off before public launch, will replace this text. Do not rely on it as a binding legal document yet.

We treat the security of your account and your data seriously, and we want to make it easy for security researchers to report vulnerabilities. This page describes how we secure the Service, how to report a vulnerability, and what you can expect from us in return.

What we do

In transit

  • All API and web traffic is TLS-only (HSTS preload pending).
  • The Android client refuses cleartext HTTP for production endpoints (network security config).

At rest

  • Database is hosted on managed Postgres with disk-level encryption.
  • Session secrets stored in Android Keystore on-device.
  • Object storage uses signed URLs for screenshots; bucket policy denies public reads of screenshots/ and templates/.
  • Stripe handles all card data; we never see or store full card numbers.

Authentication

  • Better-Auth handles sessions with HttpOnly, Secure, SameSite=Lax cookies.
  • Passwords hashed with the algorithm Better-Auth ships (Argon2id, configured at default cost).
  • Passkey and Google OAuth supported.
  • Per-user, per-route rate limiting on tRPC mutations; aggressive caps on abuse-report and workflow-create endpoints.

Application security

  • Audit log is append-only at the Postgres role level (UPDATE / DELETE revoked on the audit_log table).
  • Denylist enforced at three layers (server, marketplace review worker, on-device interpreter) — see the AUP.
  • All inbound JSON validated by Zod at the API boundary; the Android client validates with the same schema (via codegen).
  • CI requires green typecheck + tests for merge to main.

Reporting a vulnerability

Email security@smartordercapture.com with a description of the issue, steps to reproduce, and (if you have one) a PGP public key for encrypted follow-up. Our PGP fingerprint is published at the bottom of this page.

Our commitment

  • We acknowledge receipt within 2 business days.
  • We aim to provide a substantive response (severity assessment + planned remediation timeline) within 7 business days.
  • We will keep you updated as we work through the fix.
  • We credit reporters in our changelog and (if you want) on a public hall-of-fame page.

Safe harbor

We will not pursue legal action against researchers who, in good faith, engage with this program and:

  • Avoid accessing other users' accounts or data beyond what is necessary to demonstrate the issue.
  • Do not perform DoS, send spam, or social-engineer our employees or users.
  • Give us a reasonable amount of time to fix before public disclosure (we target 90 days; longer if the issue is severe).

Out of scope

  • Reports based solely on the output of automated scanners without a working proof-of-concept.
  • Missing security headers without a demonstrated impact.
  • Self-XSS, clickjacking on non-sensitive pages, or social engineering of our team.
  • Vulnerabilities in third-party services we don't control (report those to the vendor).
  • Findings that require physical access to a user's unlocked device.

Bug bounty

We do not currently run a paid bounty program but plan to launch one once we have a steady baseline. In the meantime, severe issues may receive a discretionary thank-you reward.

Security.txt

Our machine-readable security.txt mirrors this page.

PGP key

Fingerprint: (to be published before public launch)