Security

Authentication is delegated to Wenme using OAuth 2.1 with PKCE. JWTs are signed with Ed25519 / EdDSA — no symmetric secrets in transit, no password database that can leak. Sessions are short-lived and bound to httpOnly, SameSite cookies on the originating subdomain.

Authorisation is delegated to Darwan, which evaluates RBAC combined with ABAC policy against each privileged request and writes an immutable audit record (principal, resource, decision, reason). Authorisation logic lives outside the application code so it can be reviewed and changed without redeploying the marketplace.

3.1 KYC and Deal Room storage

KYC and Deal Room files live on MinIO inside our private network with AES-256 server-side encryption. Buckets are non-public; signed URLs expire in minutes. Engineering staff have no production access to KYC objects — decryption is gated behind compliance role and purpose-coded request.

3.2 Field-level encryption

Sensitive numeric fields — bank account numbers, NID numbers, TIN numbers, audited revenue figures, escrow amounts — are encrypted at the application layer with AES-256-GCM and per-tenant data keys. Database administrators see ciphertext, not plaintext.

3.3 Watermarked Deal Rooms

Every document inside a Deal Room is dynamically watermarked with the viewing user’s identifying details and a timestamp. Views, downloads, prints and exports are logged. NDA execution is captured as a signed artefact admissible in Bangladeshi courts.

3.4 Secure Chat content filtering

The Secure Chat layer scans outgoing messages for phone numbers, email addresses, and common messenger handles. Suspected leaks are blocked or quarantined for review. This protects both parties from accidental or deliberate circumvention of the disclosure ladder.

Production runs on Docker Swarm behind Traefik with wildcard TLS issued via the Cloudflare DNS-01 challenge. Deploys are SSH-triggered — there are no public webhooks, since a webhook endpoint is RCE-grade attack surface for no operational benefit.

Server .env files are excluded from rsync deploys so that secrets local to a host are never overwritten by a repo push. PostgreSQL backups are encrypted, off-host, and tested; restoration drills are part of pre-launch sign-off.

Funds at closing are held in segregated escrow accounts at Prime Bank PLC. Releases are tied to milestone evidence (RJSC Form 117 stamping, control handover, post-close warranty expiry) and require dual sign-off. All movements are reportable to Bangladesh Bank where applicable.

5.1 What we defend against

Our controls are designed to defeat: account takeover (passwordless + short-lived sessions + Darwan ABAC), data exfiltration through chat or the Deal Room (regex contact filtering, watermarked PDFs, per-view audit), server-side leakage of financials (field-level AES-256-GCM, no engineering access to KYC plaintext), insecure direct object reference attacks on Listings or Offers (Darwan policy is consulted on every read; ownership is asserted, not assumed), JWT replay (short TTL, audience binding, rotation), and session fixation (PKCE, origin-bound httpOnly cookies, no cross-site session reuse).

5.2 What we do not yet defend against

We do not protect against client-device compromise — if an attacker controls a Buyer’s laptop, we cannot stop them reading what that Buyer is allowed to read. We cannot prevent re-sharing of a document that has been legitimately downloaded and printed, although the watermark makes the source identifiable. We do not detect cross-platform identity collision (the same natural person holding both a Buyer and a Seller account at unrelated parties); KYC reduces but does not eliminate this.

5.3 Acknowledged but not fully mitigated

Side-channel timing attacks against rate-limited endpoints — for example, inferring whether an account exists by measuring response times against the rate-limit response — are acknowledged as a residual risk. We apply constant-time comparison on lookup paths and randomised jitter on rate-limit responses, but we do not claim full mitigation. If you have a practical exploit in this class, please report it via §06.

6.1 How to report

Send a confidential report to security@exit.bd. Include reproduction steps, impact, and any proof-of-concept you have. A PGP key is available on request. Do not file vulnerabilities through public channels (Twitter, GitHub issues, support chat).

6.2 Safe-harbour clause

Researchers acting in good faith under these rules are protected from legal action by KaritKarma Limited under the Bangladesh Digital Security Act 2018, the Computer Misuse provisions of the ICT Act 2006, and any equivalent jurisdictional law. We commit not to pursue civil or criminal claims against a researcher who (a) tests only on accounts they own, (b) does not access, modify or exfiltrate other users’ data, (c) does not socially engineer staff, customers or partners, (d) does not run automated scans that create denial-of-service, and (e) gives us reasonable time to remediate before public disclosure.

6.3 Response service-level

We aim for initial triage within five (5) business days of receipt — confirming receipt, severity assessment, and a remediation owner. For high-severity issues we target a fix within thirty (30) calendar days; medium-severity within ninety (90); low-severity within one hundred and eighty (180). We will tell you if a particular finding requires longer and why.

6.4 Reward expectations

Pre-funding, our acknowledgement is non-monetary: a public hall-of-fame entry once the marketplace is live (with your consent) and a written acknowledgement letter. Post-funding, we will introduce a tiered monetary reward scheme aligned with severity. Researchers who report material issues during the pre-funding window will be considered for retroactive recognition when the monetary tier is introduced.

We commit to a quarterly security update. The first edition publishes in 2026-Q3 and covers the period from public launch. Each update is dated, versioned, and archived; previous editions remain accessible.

7.1 What gets published

The number of disclosure reports received, classified by severity band; mean and worst-case time-to-triage and time-to-fix; a high-level summary of structural changes (new controls, retired controls, library upgrades that closed a CVE class); and any known incidents affecting users, with the corrective action.

7.2 What does not get published

We do not publish details of unpatched vulnerabilities, the identity of reporters without consent, customer-specific incident data, or proprietary defensive code paths whose disclosure would weaken protection. Where a regulator (Bangladesh Bank, future PDP supervisory authority) compels disclosure to it, we comply with the regulator first and update the public report as legally permitted.

7.3 Where to find it

Quarterly updates publish at /security/updates. Subscribers to the Exit.bd security mailing list (request via security@exit.bd) receive the report by email on publication day.