Security bydefault.

Account security

• Passwords are intended to be protected using a modern password-hashing algorithm rather than stored in readable form.
• Browser authentication is designed around opaque, revocable server-side sessions and HttpOnly cookies rather than tokens stored in localStorage.
• Sensitive account actions will use rate limiting and abuse protection.
• Sessions can expire and be revoked independently of the account password.

Infrastructure boundaries

• Public traffic reaches the API through HTTPS and a controlled application entry point.
• PostgreSQL and Redis are intended to remain private and not expose their database ports directly to the public internet.
• Secrets belong in protected production environment configuration, not in public frontend code or source-control history.
• Production services are designed so Redis outages do not make ordinary PostgreSQL-backed account sessions unusable.

Data protection

We minimize the information stored for each feature, restrict internal access where practical, and avoid logging passwords, session cookies, reset tokens, verification secrets or database credentials.

Operations and recovery

• Structured request logging and request IDs for incident investigation without logging authentication secrets.
• Database backups separate from ordinary VM snapshots.
• Documented restore procedures and periodic restore testing as production usage grows.
• Health checks that verify service availability without exposing sensitive infrastructure details.

Security reporting

A dedicated security-reporting channel and responsible-disclosure instructions will be published before the account platform is opened broadly. Until then, do not test Nejma systems in a way that could affect other users or service availability.

Current status

Nejma account and backend infrastructure is currently being implemented. This page describes the security architecture we are building toward and will be updated to reflect verified production controls before public launch.