Security

All token comparisons (invite tokens, verification tokens, password reset tokens, OAuth state) use constant-time string comparison. This prevents an attacker from inferring valid token prefixes by measuring response latency.

Standard string equality (String.equals) short-circuits on the first mismatch and leaks timing information. restheart-accounts uses MessageDigest.isEqual on the SHA-256 digests of both values — a standard constant-time technique.

POST /auth/register creates the account before the address is proven: anyone can register any email, with a password of their choosing, and the owner proves the address later by following the verification link. Two rules make sure that a password chosen before that proof never becomes a way into the account (since 9.13.0, GHSA-m7m7-gjxg-cjmm):

An account activated by the verification link itself keeps the password given at registration, since the person who registered and the person who followed the link are the same. An unverified account is never deleted: whatever the application stored in the user document at registration stays, and the owner reclaims the address through POST /auth/forgot-password.

All tokens (invite, verification, password reset, OAuth state) are:

Password strength is enforced server-side using the zxcvbn algorithm (Dropbox) at the point of:

The minimum score is configurable (minimumPasswordStrength, default 3 = "Strong"). Client-side zxcvbn checks are encouraged as UX guidance but are not trusted as security controls.

Before issuing a JWT on invitation activation, the server clears any existing session. This prevents a logged-in user from accidentally activating an invitation as a different identity (session fixation variant).

Consent tracking (terms & conditions, privacy policy versions) is not handled by the Accounts plugin. See Consents Management for guidance on implementing custom consent tracking. === Google OAuth security

When accountsInitializer is enabled, it unconditionally restricts what the generic MongoDB REST resource at /users can be used for, regardless of any ACL the application defines:

Why: an ACL commonly grants an authenticated user permission to PATCH their own /users/{email} document, so they can self-edit their profile (name, avatar, …​) or application-level data (consents, preferences, …​). Without this restriction, that same permission would let the user rewrite any field on their own document — including roles, team/teams, or a directly-set password — which is a privilege-escalation path (e.g. promoting themselves to owner in a team, or joining a team they were never invited to). This restriction closes that path unconditionally, for every application built on restheart-accounts, independent of how permissive its own ACL is — while still letting applications use the generic REST resource for self-service data that carries no such risk.

This does not affect any restheart-accounts endpoint itself: every service that legitimately needs to set roles, team/teams, tokens, or a hashed password writes to MongoDB directly via the driver, not through the REST resource — so none of those flows are subject to this restriction.

If your application has its own reason to let certain accounts write more than profile.* to /users via the generic REST resource (for example, an internal admin console that manages roles/teams directly), configure users-unrestricted-roles in accountsConfig:

Accounts with any of the listed roles bypass this restriction entirely — both the PUT/POST block and the field denylist on PATCH. Leave it unset (the default) to apply the restriction to every caller, with no exceptions.

In a multi-tenant deployment, users-unrestricted-roles can also be overridden per team via override-accounts-users-unrestricted-roles — see Multi-tenancy for the full override mechanism.

accountsInitializer is enabled at the node level, independent of whether a given tenant has actually opted into restheart-accounts (e.g. Ulabase enables it once per service node, but Sign-up Management is an opt-in feature per service). A tenant that never enabled it never opted into these opinions on /users either — so a deployment-layer interceptor running before authentication (e.g. TeamConfigInterceptor, at REQUEST_BEFORE_EXCHANGE_INIT) can attach override-accounts-signup-mgmt-enabled: false to skip the restriction entirely for that tenant, for every caller. This must be set before authentication: the veto is evaluated as part of authorization, which runs before any REQUEST_AFTER_AUTH interceptor gets a chance to run.

Which user-document fields are copied into an issued JWT, the claims that always survive a per-tenant override, and the denylist that no configuration can bypass, are described in Authentication — JWT claims.

They are documented there rather than here because they are not specific to restheart-accounts: the same JwtIssuer applies them to every token this deployment issues — on /token, from the accounts endpoints, and to OAuth authorization codes alike.

Since 9.12.2 restheart-accounts limits how the emails it sends can be abused. The first two protections below are configured with the accountsEmailPolicy provider (see Configuration).

restheart-accounts relies on RESTHeart’s built-in bruteForceAttackGuard (sliding-window rate limiter per IP) for protection against token-guessing and credential stuffing.