Skip to content
Back to home

Security at Arqam360

How we protect merchant and visitor data.

Below is a plain-English description of the security controls actually shipped in our platform — drawn from the code, not aspirations. We tell you what we hold today and what's on the roadmap separately, so you can make an informed call.

1. Authentication & access control

  • Password hashing with bcrypt (cost factor 12) — passwords never stored in plaintext, never reversible.
  • JWT-based session auth with 15-minute access tokens + 7-day refresh tokens. Tokens are HttpOnly + Secure cookies; never readable by browser JavaScript.
  • Account lockout after repeated failed login attempts (configurable threshold).
  • Optional two-factor authentication (TOTP) for admin accounts.
  • Role-based access control: owner / admin / editor / viewer roles, enforced at every authenticated route via middleware.
  • Cross-platform SSO via short-lived (60-second) JWTs with replay protection — used for embedded merchant dashboards on Salla, Zid, Shopify, and WordPress.

2. Data encryption

  • All sensitive third-party tokens (OAuth access tokens, API secrets, webhook signing secrets) encrypted at rest with AES-256-GCM. Encryption keys live in environment variables only — never in code, never in the database.
  • TLS 1.2+ enforced on every external endpoint. HSTS headers set with 1-year max-age.
  • API keys are checked against a SHA-256 hash, so the key itself is never needed to authenticate a request.
  • DSAR portal one-time-passwords hashed before storage.
  • Sensitive Mongoose fields use `select: false` by default — never returned by default queries; require explicit projection.

3. Network & application hardening

  • Helmet middleware applies a strict Content Security Policy, X-Frame-Options, Referrer-Policy, and Cross-Origin-Resource-Policy on every response.
  • CSRF protection on every state-changing endpoint via double-submit-cookie tokens.
  • CORS allowlist enforced — no wildcard origins on authenticated routes.
  • Rate limiting on every public endpoint (per-IP and per-API-key); plan-tier limits enforced on authenticated routes.
  • Cookie scanner runs in a sandboxed headless Chromium, with SSRF protection that blocks internal IP ranges (10.x, 192.168.x, 169.254.x) before any HTTP request is issued.
  • All requests carry a unique X-Request-Id, traceable end-to-end through logs.

4. Data minimization & retention

  • No raw email or phone numbers are stored against tracked events — only SHA-256 hashes used for identity resolution.
  • Cookie scanner stores cookie metadata, never cookie values from third-party domains.
  • Routing decision audit logs auto-delete after 90 days via MongoDB TTL indexes.
  • Soft deletes on user data: deletion sets `deletedAt`, then a scheduled job purges after the regulatory retention window.
  • DSAR (data subject access request) auto-retrieval pulls only the data we actually have; we do not aggregate or retain visitor PII beyond what the merchant has explicitly logged.

5. Reliability & operations

  • BullMQ + Redis-backed queues for event delivery, webhook dispatch, and segment evaluation. Failed jobs land in a dead-letter queue for inspection — no silent drops.
  • Circuit breakers on outbound integrations: an endpoint that fails 5 times in a row pauses for 60 seconds, then probes with a single retry — protecting both us and the downstream platform.
  • Prometheus metrics exposed at /metrics: request latencies, queue depths, oldest-job age, circuit-breaker state. /health surfaces component-level status (DB, Redis, Stripe) for uptime probes.
  • Webhook delivery uses HMAC-SHA256 signatures so receivers can verify authenticity. Failed deliveries retry with exponential backoff up to 24 hours.
  • Multi-environment isolation: production / staging / dev use separate databases, Redis instances, and Stripe accounts.

6. Audit & accountability

  • Every administrative action (create client, update settings, sync segment, delete domain, modify routing rule) writes to an immutable audit log with actor, action, resource, and timestamp.
  • Agency team-member actions are recorded both as the team member AND the client they were "acting as" — full traceability for delegated access.
  • Routing decisions (which event went to which platform, with which consent state) are persisted to the RoutingDecision collection — provable per-event compliance audit trail.
  • Audit logs are queryable by admins; CSV export is available.
  • Operator audit records are retained for the life of the account plus five years, matching Saudi PDPL Implementing Regulations Article 33 (records kept during processing and for five years from its completion). Retention is keyed to account closure, not to row age — a fixed expiry would delete a live account’s early records while the processing they document is still running.

In progress / on the roadmap

The following are honestly described as not yet shipped. We list them here rather than claim them prematurely.

SOC 2 Type II

In progress. Controls are designed and most are operating; formal audit window opens once we reach the customer threshold that justifies it.

ISO 27001

Roadmap. The control set substantially overlaps with what SOC 2 will cover; ISO 27001 will follow once the SOC 2 attestation lands.

Penetration testing

Annual third-party penetration tests are planned. Results and remediation reports will be available under DPA on request.

Reporting a vulnerability or requesting our DPA

Suspected security issue? Email admin@arqam360.com. We respond within one business day. We follow coordinated disclosure — please give us a reasonable window before public disclosure.

Need a Data Processing Agreement (DPA)? Email admin@arqam360.com — we ship the standard EU SCCs / GCC equivalents.

This page is updated whenever the underlying controls change. Last reviewed: 2026-04.