Trust & Security
DropShop BD handles seller credentials, customer addresses, and order data. Here is exactly how we secure it.
Row-level security on every table
Every public-schema table has Postgres RLS enabled with owner-scoped policies. Sellers can only ever read or write their own rows — enforced at the database, not at the application layer.
HMAC-signed webhooks
Outbound webhooks use HMAC-SHA256 with timing-safe comparison. Replay windows are bounded. Receivers verify signatures before processing.
OAuth state token signing
OAuth callbacks verify HMAC-signed state tokens with a 15-minute TTL. CSRF and replay attacks on the callback path are blocked by construction.
Atomic rate limiting
API key rate limits run inside a SECURITY DEFINER Postgres function — no read-then-write race condition. 60 requests/minute per key, fail-closed on infrastructure failure.
Redacted audit logs
Every supplier API call is logged to provider_logs with sensitive fields (tokens, signatures, session keys) masked before insert. Webhook response bodies and request headers are intentionally never persisted.
Generic error responses
API errors are returned with a generic public message and an internal ref ID. Raw upstream errors, database hints, and stack traces never reach the client.
Responsible disclosure
Found a vulnerability? Email security@msg.bd with reproduction steps. We acknowledge within 24 hours and credit researchers on the changelog with permission.