Security & Privacy
Built for trust and community data sovereignty
Dedicated Subdomain per Jamaat
Each Jamaat operates on its own dedicated web address (e.g. bhopal.jamaatcloud.com). Another Jamaat’s staff or member accounts cannot authenticate or access data on your address.
Server-Enforced Data Scoping
Member, office and finance records carry their Jamaat’s ID, and every API read and write is filtered and checked on the server — the browser is never trusted as a security boundary.
Fixed 48-Key Permission Catalogue
Roles are built from a verified catalogue of granular permission keys (e.g. maliyah.receipt.print, fmb.thali.manage). A Jamaat can grant its staff only what the platform enabled for that office.
One-Way Password Hashing
All staff and member passwords are encrypted using modern one-way scrypt password hashing. Passwords cannot be read back by anyone, including platform administrators. Sign-in attempts are rate-limited.
Secure HttpOnly Sessions
Authentication tokens are sealed in HttpOnly, SameSite cookies bound to the specific host. If a member access is suspended or password reset, existing sessions are signed out within seconds.
Administrative Action Logging
All system sign-ins, permission grants, and key administrative decisions are systematically recorded with user identifiers and timestamps for office auditability.
Frequently asked technical questions
Can one Jamaat see another Jamaat’s members or collections?
No. Every database read and write requires a verified session bound to the host. The server filters every collection by the Jamaat that host belongs to, so an office works only with its own records.
How is data backed up?
Database backups are automated with continuous cluster snapshots, point-in-time recovery, and multi-region replication on enterprise cloud infrastructure.
Have specific security or compliance requirements?
Speak with our technical engineering team.