Security and Data Information

This page summarizes security-related controls implemented in BlessBoard based on the current product design. It describes how access is structured for administrators and church users.

Separate church workspaces

Each church branch on BlessBoard is served on its own site context (typically a dedicated hostname). Public pages, member portals, and branch administration for one congregation are scoped to that church’s organization and branch records in the platform database.

Role-based access

BlessBoard separates common roles so people see tools appropriate to their responsibility:

Members — member portal on their church site after sign-in.
Ministry leaders — leader tools for assigned ministries on their church site.
Branch administrators — branch-level administration on their church site.
HQ administrators — multi-branch headquarters tools where enabled for an organization.
BlessBoard platform administrators — super-administrative provisioning and support on blessboard.com (/admin), separate from church tenant sign-in.

Cross-church access is rejected by server-side checks tied to organization and branch context.

Password protection

User passwords are stored using one-way password hashing (bcrypt) rather than plain text. Password reset flows use request queues reviewed by the appropriate administrators (branch, headquarters, or platform level depending on account type).

Session handling

Authenticated areas use a server-side session stored in the platform PostgreSQL database. Session cookies are marked httpOnly, use SameSite=Lax, and use the secure flag in production environments. Sessions are configured with a limited lifetime (currently eight hours of inactivity-based expiry in application settings).

Sign-in protections

Repeated failed church sign-in attempts can temporarily lock an identifier after several consecutive failures.
Password reset request submission is rate limited.
BlessBoard platform administrator login and public platform contact forms have additional rate limiting.
Authenticated church portal and platform administrator forms that change data use CSRF tokens tied to the active session.

Public forms on blessboard.com

Contact and church registration forms on blessboard.com are unauthenticated. They use server-side validation, honeypot fields, and rate limiting rather than session CSRF tokens.

Operational logging

Sign-in attempts and many administrative actions generate audit records to support troubleshooting and administrator review. Support staff identifiers may be masked in security views.

What this page does not cover

BlessBoard does not publish infrastructure certifications, backup schedules, data residency commitments, or breach notification procedures on this page. Those depend on deployment and organizational agreements outside this public summary.

If you believe you found a security issue affecting BlessBoard, use the Contact BlessBoard form and describe the concern. Do not include passwords or unrelated personal data in your message.