Security Policy

1. Our Security Commitment

Beezifi Inc. is committed to maintaining the confidentiality, integrity, and availability of all data entrusted to our platform. We apply security controls at every layer of the stack — from the database schema to the HTTP response headers — and treat security as an ongoing operational discipline rather than a one-time configuration.

We believe in transparency. This document explains precisely what we do to protect your data and what we expect from you as an administrator or user of the platform.

2. Data Isolation

Technical implementation:

• Each workspace is provisioned as a separate MySQL database with the prefix crm_ followed by the workspace slug (e.g., crm_acme).
• The application resolves the correct database at the API layer using a validated tenant identifier passed in a required request header. Requests without a valid tenant header are rejected before any data access occurs.
• Tenant slugs are validated against a strict allowlist pattern and a reserved-word blocklist before provisioning or resolution.
• The system admin control panel operates on a separate root database (beezificrm) with no access to workspace data except through explicit, audited database connections.

3. Authentication & Access Control

Password Security

All passwords are hashed using bcrypt with a work factor of 10 before storage. We never store, log, or transmit plaintext passwords at any point. Password reset flows issue short-lived, single-use tokens only.

Session Tokens

The platform uses JSON Web Tokens (JWT) for session management. Tokens are:

• Signed with a secret key stored in server-side environment variables (never in code or client storage)
• Short-lived with a configurable expiry window
• Verified on every protected API request before any data access is permitted
• Scoped — workspace user tokens and system admin tokens carry distinct claims and are validated separately

Two-Factor Authentication (TOTP)

Every user account — including system administrators — can enable TOTP-based two-factor authentication compatible with Google Authenticator, Authy, 1Password, and any RFC 6238-compliant app. When enabled:

• The TOTP secret is generated server-side and displayed once as a QR code during setup
• A valid 6-digit code is required on every login in addition to the password
• TOTP secrets are stored encrypted in the database and are never returned via the API after initial setup

We strongly recommend enabling TOTP for all admin accounts.

Role-Based Access Control

Every API endpoint enforces role-based access controls. The platform supports five roles with increasingly restrictive permissions:

• Admin — full workspace access including user management and settings
• Manager — read/write on all CRM modules; cannot manage users
• Sales Rep — read/write on contacts, companies, deals, leads, and their own tasks
• Support Rep — read/write on contacts and tickets; read-only elsewhere
• Read-Only — view access only; no create, edit, or delete permissions

Role assignments are enforced at the API middleware layer. Attempting to call an endpoint above your role returns a 403 Forbidden response with no data exposure.

Rate Limiting

Authentication endpoints (login, TOTP verification) are rate-limited per IP address to prevent brute-force attacks. Excessive failed attempts result in temporary lockout at the network layer.

4. Data Encryption

5. Network & Infrastructure Security

• Firewall & network segmentation: The application server, database server, and any ancillary services are separated by network controls. Database ports are not exposed to the public internet.
• Least-privilege access: The application database user is granted only the permissions it needs to operate. Root-level database access is restricted to provisioning operations and uses a separate, audited credential.
• Dependency management: Production dependencies are regularly audited for known vulnerabilities. Critical security updates are applied promptly.
• Environment separation: Development, staging, and production environments are fully separated. Production credentials are never used in development or test environments.

6. Application Security

HTTP Security Headers

The API server uses Helmet.js to apply a suite of HTTP security headers on every response, including:

• Content-Security-Policy — restricts sources of scripts, styles, and other resources
• Strict-Transport-Security — enforces HTTPS for all future requests
• X-Frame-Options: DENY — prevents clickjacking via iframe embedding
• X-Content-Type-Options: nosniff — prevents MIME-type sniffing attacks
• Referrer-Policy — controls referrer information sent with requests

Input Validation & SQL Injection Prevention

All database queries use parameterized statements via the mysql2 driver. User-supplied input is never interpolated directly into SQL strings. Tenant slugs and identifiers are validated against strict regular expressions before use in any database or filesystem operation.

CORS Policy

Cross-Origin Resource Sharing (CORS) is configured to allow only trusted origins. Requests from untrusted origins are rejected at the network layer.

Dependency Supply Chain

We use a minimal, well-maintained set of production dependencies. All packages are pinned to specific versions. We run automated vulnerability scans on the dependency tree as part of our deployment process.

7. Audit Logging

Every significant action within a workspace is written to an append-only audit log, including:

• User logins and login failures (with timestamp and IP address)
• Record creation, modification, and deletion (with the acting user's identity)
• User invitations, role changes, and deactivations
• Workspace settings changes

Audit records are timestamped in UTC and attributed to the authenticated user who performed the action. Audit logs are readable by workspace admins and are not modifiable by any application user. System-level audit logs (infrastructure access, admin panel actions) are maintained separately and retained for a minimum of one year.

8. Incident Response

Detection

We monitor infrastructure and application logs for anomalous patterns, including unusual authentication activity, unexpected data access volumes, and dependency vulnerability alerts.

Response

In the event of a confirmed security incident:

1. The affected system or workspace is isolated to prevent further exposure
2. The scope and nature of the incident is assessed by our security team
3. Affected workspaces are notified within 72 hours of discovery, as required by applicable data protection law
4. A post-incident report describing the nature of the breach, data affected, and remediation steps taken is provided to affected administrators

Notification

Breach notifications are sent to the admin email address on file for each affected workspace. If you suspect your workspace has been compromised, contact us immediately at security@beezifi.com. Include your workspace name, the nature of the suspected issue, and any supporting details.

9. Your Responsibilities

Security is a shared responsibility. As a workspace administrator or user, you are responsible for:

• Using strong, unique passwords for your CRM account, distinct from passwords used on other services
• Enabling TOTP 2FA on all administrator accounts — we strongly recommend this
• Managing user access appropriately — removing users promptly when they leave your organization and assigning the least-privileged role necessary for each user's function
• Keeping devices secure — the platform's security cannot compensate for a compromised device or phished credential
• Reporting suspicious activity — if you notice unexpected logins, data changes, or any anomaly in your workspace, contact us immediately
• Not sharing credentials — each user should have their own account; shared logins defeat audit logging and access control

10. Vulnerability Disclosure

We welcome responsible disclosure of security vulnerabilities. If you discover a potential security issue in our platform, please report it to us before public disclosure so we can investigate and remediate it.