Security Policy
Scope
This Security Policy describes how Rexplore Inc. protects Nakama and its users. It covers the Nakama Chrome extension, the stateless serverless functions that perform OAuth token exchange, the sign-in service at account.orenonakama.com, and the marketing site at orenonakama.com. It applies to all Rexplore staff and to the third parties who process data on our behalf.
Security principles
Our design follows a few firm principles: data minimization (we keep as little as possible, and keep nothing server-side that we do not need); least privilege (every component and every OAuth scope is the minimum required); keep user data on the user's device wherever possible; defense in depth; and secure-by-default configuration. Security is a property of the architecture, not a feature bolted on afterwards.
Architecture overview
Nakama is a Manifest V3 Chrome extension paired with stateless serverless functions and a static marketing site. The extension runs in the browser and talks directly to each provider's API. The serverless functions exist only to complete OAuth token exchanges that require a confidential client secret; they hold no database and persist no user data. The sign-in service authenticates you and issues a session. This separation means there is no central store of user content to breach.
Encryption in transit
All network traffic — between the extension and Google, Slack, Telegram, Zoom, GitHub, Figma and other providers, and between your browser and our own functions and sites — uses HTTPS with TLS 1.2 or above. HTTP Strict Transport Security (HSTS) is enforced on our domains. No plaintext transport is used anywhere.
Data at rest
User OAuth tokens are stored only on the user's own device, in Chrome's sandboxed extension storage, protected by the operating system's user-account controls, and deleted on disconnect or uninstall. Nothing about your connected accounts is stored on our servers: the token-exchange functions are stateless and have no database. Confidential client secrets exist only as encrypted environment variables in the hosting platform and are never shipped inside the extension or exposed to the browser. The sign-in service's own datastore is hosted on an encrypted-at-rest managed Postgres (Neon).
Authentication and OAuth
Connections use each provider's standard OAuth 2.0 / OpenID Connect flow with state and, where supported, PKCE to protect the authorization exchange. We request the minimum scopes each feature needs and request them incrementally where providers allow it. You can revoke Nakama's access at any time from the provider (e.g. Google Account permissions, Slack Manage apps, Zoom Marketplace) and by disconnecting inside Nakama.
Token and credential handling
Access and refresh tokens live on your device and are used to call provider APIs directly from your browser. They are never written to our server logs and never sent to any party other than the issuing provider. The confidential client secret used during token exchange stays server-side in encrypted configuration and is rotated promptly if exposure is ever suspected.
Extension hardening
The extension uses Manifest V3 and runs no remote code: all executable code is shipped in the package and reviewed before release. A strict Content Security Policy is enforced, eval and inline-script execution are not used, and the extension ships with no third-party JavaScript runtime libraries, keeping the attack surface small. Host and API permissions are scoped to what each integration needs. Chrome's extension auto-update delivers security fixes to all users without any action on their part.
Network and API security
Wherever possible the extension calls provider APIs directly from the browser so that user content does not transit our infrastructure. Our serverless functions are limited to the OAuth token exchange and do not proxy, inspect or store message, email, file or meeting content.
Infrastructure and platform
Our sites and functions run on a managed cloud platform (Vercel) with credentials and secrets held as encrypted environment variables. Responses are served with hardened security headers, including HSTS, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, a restrictive Referrer-Policy and Permissions-Policy. TLS certificates are managed and auto-renewed by the platform.
Logging and monitoring
Our stateless functions do not log request bodies, tokens or user content. Platform-level access logs (timestamps, paths, status codes — no payloads) are retained by the hosting provider for a short period for abuse prevention and debugging, then discarded. We review platform and dependency security advisories on an ongoing basis.
Access control
Access to production configuration, secrets and the hosting platform is limited to Rexplore engineering staff on a need-to-know basis and protected by strong, multi-factor-capable authentication. Secrets are rotated on staff changes and whenever exposure is suspected.
Secure development lifecycle
All changes are version-controlled and code-reviewed, and are syntax- and behaviour-checked before release. We prefer small, auditable changes. The extension's deliberate minimal-dependency design (no third-party runtime JavaScript) reduces the chance of a vulnerable or malicious dependency reaching users.
Dependency and supply-chain security
We keep dependencies minimal and pinned, monitor advisories for the components we do rely on (Chrome extension APIs, the Node.js runtime, the hosting platform and the sign-in service's libraries), and update promptly when a relevant advisory is published.
Data minimization and retention
Email, file, message and meeting content is fetched on demand, rendered in the panel, and then discarded — it is never persisted on our servers. Tokens and settings live on your device until you disconnect or uninstall. See our Data Retention & Protection Policy for specifics.
Vulnerability disclosure
We welcome reports of suspected vulnerabilities at help@rexplore.xyz and acknowledge them within 3 business days. We ask for reasonable time to remediate before public disclosure and credit reporters who wish to be named. See our Vulnerability Management Policy for triage and remediation targets.
Incident response
Suspected incidents are reviewed within 24 hours, contained immediately (for example by revoking and rotating credentials or disabling an affected function), assessed for impact, and — where user data is affected — notified to those affected without undue delay, and within 72 hours where the law (such as the GDPR) requires. See our Incident Management & Response Policy.
Compliance posture
Nakama is built to align with the GDPR's principles and with Google's API Services User Data Policy, including the Limited Use requirements: data obtained from Google APIs is used only to provide and improve the user-facing features, is not sold, and is not used for advertising. We do not sell user data to anyone.
Subprocessors
We rely on a small set of processors: the hosting platform that serves our sites and runs our functions, and the managed database behind the sign-in service. When you use an AI feature, your request is sent to the AI provider you are using (GPT by default, or your own OpenAI/Anthropic key), which processes it under its own terms; Nakama does not train any model on your data.
Reporting and contact
Report security concerns to help@rexplore.xyz. This policy is reviewed periodically and after any significant change to the product or its infrastructure.