For AI agents: the complete documentation index is available at https://dotpress.dev/llms.txt, the full documentation bundle is available at https://dotpress.dev/llms-full.txt, and this page is available as Markdown at https://dotpress.dev/auth/security.md.

    Security checklist

    @dotpress/auth is secure by default: rotating refresh tokens, short-lived access tokens, throttled logins, httpOnly cookies protected against CSRF. Some decisions remain yours. Check this list before going to production.

    Keys and tokens

    • The private key is stored in a secret manager, never in the repository or an image. Keys
    • Each environment has its own key pair, and its own issuer. Keys
    • The keys are rotated on a schedule, and you know how to rotate them after a leak. Rotation
    • accessTokenTTL stays short: 15 minutes by default. Access tokens
    • The username is not written in the tokens, unless needed (usernameClaim). Access tokens

    Browsers

    • Browser applications use the cookie mode with accessTokenInCookie: no token is readable by the JavaScript of the page. Cookie mode
    • The API is served over HTTPS only, and the cookies stay secure. Cookies
    • CORS lists the trusted origins explicitly, without '*' or a function accepting any origin. CORS
    • No GET route changes data: they are not checked against cross-site requests. CSRF
    • Mobile applications keep their tokens in the secure storage of the platform (Keychain, Keystore), never in plain files.

    Sessions

    • Every session is revoked when a password is changed or reset, and when an account is disabled. Password change
    • findUserById() returns undefined for deleted, disabled and banned accounts. Data provider
    • Privileged applications (backoffice) have an absolute session timeout. Session lifetimes
    • Sensitive applications reject the tokens of a revoked session at once, with isSessionRevoked. Revocation
    • onRefreshTokenReuse raises an alert: a reused refresh token means a stolen session. Rotation

    Passwords and logins

    • Passwords are long (12 characters or more), without composition rules, and checked against known leaks. Rules
    • The schemas of sign-up and password change reject passwords over 72 bytes (isPasswordTooLong). 72-byte limit
    • The bcrypt cost (passwordHashRounds) is measured on your servers, and matches your stored hashes. Hashing
    • With several instances, the login throttle uses a shared store. Shared store
    • Behind a proxy, the server trusts the proxy headers, so that each client has its own IP address. Proxy
    • Sign-up and password reset answer the same way whether the account exists or not. Enumeration

    Authorization

    • Every route reading or changing a resource checks that the user may access this resource, not only that a user is logged in. Authorization
    • Response schemas list the returned fields: password hashes and internal fields never reach the client. Validation
    • The routes of a backoffice require its client and a role (requireClient(), requireRole()). Clients

    The app

    • exposeErrors is disabled in production. Errors
    • Unexpected errors are reported (onError), and login failures are logged (onLoginFailed). Login events
    • Dependencies are kept up to date, and the security advisories of Dotpress are followed: see the security policy.