Security

This page describes the security controls NamiDB Cloud has in place today. It describes what is implemented, not aspirations; when a control changes, this page changes with it. The same measures form Annex II of our Data Processing Addendum.

• Dedicated storage per organization. Each organization’s databases and backups live in storage dedicated to that organization, in the storage location assigned when the organization is created. Committed writes are stored durably before they are acknowledged.
• One engine per organization. Queries run in an isolated engine process dedicated to the organization, with least privileges and memory and CPU limits per plan. Engines scale to zero after inactivity and keep no copy of your data outside your organization’s storage.
• Scoped, short-lived storage credentials. An engine receives temporary credentials that only open its own organization’s storage and are renewed before they expire.
• Engine-level authorization. Each engine has its own random read-write and read-only tokens. A read-only API key, or an organization over its write allowance, gets the read-only token, so the engine itself refuses writes on HTTP and Bolt alike.
• Restricted network access. Engines can reach only the storage service they need; every other outbound destination is blocked.

• TLS on every public endpoint: app.namidb.com, auth.namidb.com, status.namidb.com and db.namidb.com (HTTPS, MCP and Bolt over TLS). Certificates are issued and renewed automatically; the console sends HSTS.
• Internal traffic that crosses a network between our systems is encrypted as well.
• Default-deny network rules: only the public endpoints above are reachable from the internet, and internal interfaces require their own credentials.
• Customer Content is encrypted at rest.
• Backups of the Service’s own records are encrypted before they are stored off-site, with the decryption key kept separately from the systems that write them.

API keys

• Keys look like nmdb_live_<id>_<secret>, with about 256 bits of randomness, and are shown exactly once. We store only an HMAC-SHA256 of the key under a server-side secret, and signed-in users cannot even read that hash.
• Keys carry a role (read-write or read-only), an optional set of databases and an optional expiry.
• Revoking a key takes effect across the data plane within about two seconds.
• Per-key and per-organization rate and concurrency limits; client addresses that present too many invalid keys are rate limited.

Console accounts

• Passwords need at least 10 characters, are checked against known breached passwords (k-anonymity, only a hash prefix leaves the Service) and are stored as salted bcrypt hashes.
• Email verification and sign-in codes are single use and expire after 15 minutes.
• Sign-in, sign-up, magic links and password recovery never reveal whether an address has an account. Code verification is rate limited per address and per IP, shared by every console replica, and fails closed.
• The browser never talks to the authentication service directly. Session cookies are HttpOnly, Secure and SameSite; session tokens are verified by their signature (ES256) on every request. GitHub and Google sign-in use PKCE.
• Setting a new password from a recovery link requires a short-lived, signed proof that the link was just redeemed.
• Security headers on every page: a Content Security Policy, frame denial, nosniff, a strict referrer policy, a restrictive permissions policy, and no referrer on URLs that carry one-time tokens.

• Account, organization, key and billing records live in a database NamiDB operates itself. Every table has row-level security; users read only their own organizations, and changes go through database functions that check the caller’s role.
• Each internal component has its own credential and only the permissions it needs (least privilege).
• Payment card details never reach NamiDB: they are entered on Stripe’s pages, and we receive only references.
• NamiDB staff do not access Customer Content in the ordinary course. Production access is limited to authorized personnel who need it to operate the Service, with individual accounts, two-factor authentication and no shared credentials; administrative actions are logged, and access is removed when it is no longer needed.
• Secrets are generated per environment, never written to logs, and are rotated on a fixed schedule (every 90 to 365 days depending on the secret) and immediately when exposure is suspected.

• Automated monitoring of every component, external probes of every public endpoint, and alerting on failures, error rates, certificate expiry, capacity and stale jobs. Logs are centralised and kept 30 days (90 days for security logs); they exclude passwords, keys, cookies and request bodies, and one-time tokens are redacted from logged URLs.
• The Service’s own records (accounts, organizations, keys, billing state) are backed up continuously to encrypted off-site storage, kept 30 days, and restored in a drill every quarter.
• Customer database backups: on demand on every plan, and on paid plans every 6 hours, kept 48 hours except one a day, which is kept 7 days (Pro) or 30 days (Scale); on-demand backups are kept 3 days on Free and as long as the daily ones on paid plans. They are stored in the organization’s own dedicated storage and always restored into a new database, so a restore never overwrites live data.
• A documented incident process with severity levels, roles, status-page updates at status.namidb.com, customer email for major incidents and a written postmortem. Security incidents affecting personal data are notified to affected customers within 48 hours of our becoming aware of them.
• Changes ship through version control and automated type checks, linting, unit and end-to-end tests; dependencies are pinned to exact versions, and security updates are applied automatically.

• Keep API keys in a secret manager or server-side environment; never ship read-write keys in browser or mobile code.
• Use read-only keys, database scopes and expiry wherever they fit, and revoke keys you no longer use.
• Review your organization’s members and roles regularly.
• Keep your own exports of data you cannot afford to lose: our backups don’t replace copies you control.

We welcome reports from security researchers. Email info@namidb.com with the subject “Security report”. Write in English or Spanish, and include the affected endpoint or component, steps to reproduce, the impact you believe it has, and how to reach you. Our security.txt lists the same contact.

What we commit to

• Acknowledge your report within 3 business days.
• Give you an initial assessment within 10 business days, and an update at least every 14 days until it is resolved.
• Agree a disclosure date with you. We ask for 90 days from the report, or until a fix is released if sooner; we will tell you if we need longer and why.
• Credit you publicly when the issue is fixed, if you want to be credited.

We do not run a paid bug bounty program at this time.

Scope

In scope: app.namidb.com, auth.namidb.com, db.namidb.com (HTTPS, MCP and Bolt), the open-source NamiDB engine as we run it, and our SDKs. Test only against organizations and accounts you created yourself.

Out of scope:

• denial-of-service and volumetric testing, and anything that degrades the Service for other customers;
• social engineering of NamiDB staff or customers, and physical attacks;
• systems and services operated by our subprocessors and other third-party providers, which you should report to them;
• findings without a demonstrated security impact, such as missing headers on non-sensitive pages, banner or version disclosure, self-XSS, clickjacking on pages without sensitive actions, or rate limits you consider too generous;
• reports from automated scanners without a verified, exploitable issue.

Rules of engagement

1. Do not access, modify or delete data that is not yours. If you reach other customers’ data, stop and report it immediately; do not keep it.
2. Do not degrade the Service; stay within your plan’s limits.
3. Do not use a vulnerability beyond what is needed to demonstrate it, and do not pivot to other systems.
4. Keep the report confidential until we agree a disclosure date.
5. Comply with the law.

Safe harbor

If you make a good-faith effort to comply with this policy, we consider your research authorised: we will not pursue or support legal action against you for it, including under the Computer Fraud and Abuse Act, the DMCA’s anti-circumvention provisions or similar laws, and we waive the restrictions in our Terms and Acceptable Use Policy that would otherwise prohibit it, solely for that research. If a third party brings legal action against you for activity that complied with this policy, we will make it known that your actions were authorised. If in doubt about whether something is allowed, ask us at info@namidb.com before you do it.