CRM security checklist

• Every read and write goes through authorize(actor, action, record) with role, record scope (own|team|all) and tenant checks, backed by RLS; direct object access by id re-checks scope so IDOR on /contacts/[id] and the API fails closed.
• Field-level permissions are applied by projectRecord on output and by the query builder on input: a field with access none cannot be read, filtered, sorted, searched, aggregated or exported, which also closes the 'filter to infer a hidden value' oracle; write access is enforced per field on update and import.
• Admin screens (roles, field permissions, audit, imports) require a recent re-authentication and admin role; the last admin cannot be removed; invitations are single-use and expire.

• Contacts hold personal data (names, emails, phones, notes): encrypted at rest and in transit, excluded from logs and analytics (hashed ids only), exportable and erasable per data subject, with do_not_contact and consent-source fields respected by every bulk and email action.

• CSV imports are untrusted: size, row and column caps, UTF-8 validation, delimiter sniffing, per-cell length caps and strict type coercion; exports neutralise spreadsheet-formula injection (cells starting with = + - @ tab or CR are prefixed with an apostrophe).

• Notes, custom text fields and imported values are stored as text and rendered escaped by React; rich notes use a sanitized allow-list of markdown elements; links get rel=noopener nofollow and are never auto-fetched server-side without an SSRF guard.

• Every create, update, delete, permission change, login, import, export and bulk op writes an audit_log row in the same transaction; the table is append-only with a hash chain, daily verification and an alert on any break.

• Mass data exfiltration controls: exports and API reads are row-capped, role-gated (rep exports only owned records unless granted), rate limited, audited and alerting on unusual volume per user; departing-user revocation ends sessions and API keys immediately.
• Every billable or unbounded resource has a code-enforced cap that fails closed: import rows and MB, export rows, bulk-op rows, custom fields per entity, file storage per workspace, reminder emails per user per day, outbound webhook deliveries per day and API calls per key; at the cap the operation is refused with an explicit error, never queued.

• Webhook signing secrets, API keys and email OAuth tokens are stored encrypted or hashed (API keys shown once), referenced by id in rows, never logged or returned after creation, and rotatable without downtime.

• GDPR / CCPA (applies to EU or California contacts): Contacts are personal data of third parties: record lawful basis and source, honour access, rectification and erasure requests across contacts, activities, audit snapshots and exports, retention limits, and a DPA with the customer; erase must also reach backups on the documented schedule.
• Email and calling consent (CAN-SPAM, CASL, PECR, TCPA) (applies to outreach or email features): Track consent and unsubscribe status per contact (do_not_contact) and block bulk email and call actions for contacts without a valid basis.
• SOC 2 style controls (applies to B2B / enterprise customers): Append-only audit trail, role-based least privilege, access reviews, change history and export logging are the controls enterprise buyers ask for; the hash-chained audit log is designed to support them.
• Accessibility: Keyboard-operable tables, kanban drag alternatives (move-to menu) and WCAG 2.2 AA contrast.

• import rows per job: IMPORT_MAX_ROWS and IMPORT_MAX_MB; upload refused over the limit and one import at a time per workspace.
• export rows per job: EXPORT_MAX_ROWS; job fails closed before writing a file over the cap.
• bulk op rows: BULK_MAX_ROWS; bulk op refused at creation when the filter matches more.
• file storage gb: WORKSPACE_STORAGE_MB per workspace; presign refused at 100%.
• reminder emails per user day: REMINDER_EMAILS_PER_USER_DAY and a workspace monthly send cap; sends refused at the cap.
• custom fields per entity: MAX_CUSTOM_FIELDS_PER_ENTITY; creation refused at the cap.

Forge64 gives every app its own Postgres database and runs a quality gate that flags unauthenticated writes and secrets in client code before you see the app. It does not replace your own testing, and it holds no third-party security certification today.

This is a reference design for the category, not a promise that every item is generated today. Built-ins such as email, background jobs, file uploads and search are coming soon, so anything here that needs them is something you add yourself for now.

• Sign in as two different users and try to open each other's records by changing the id in the address.
• Submit each form with an empty value, a very long value and a script tag, and check the result.
• Call each write endpoint without signing in and check that it refuses.

What is the biggest security risk in a CRM?

Every read and write goes through authorize(actor, action, record) with role, record scope (own|team|all) and tenant checks, backed by RLS; direct object access by id re-checks scope so IDOR on /contacts/[id] and the API fails closed.

Does a CRM have compliance obligations?

GDPR / CCPA, if you have EU or California contacts: Contacts are personal data of third parties: record lawful basis and source, honour access, rectification and erasure requests across contacts, activities, audit snapshots and exports, retention limits, and a DPA with the customer; erase must also reach backups on the documented schedule. This is a starting point, not legal advice.

Will Forge64 certify my app as secure?

No. Forge64 holds no third-party security certification today and does not certify apps. The checklist is a way to test your own app.

• How to build a CRM
• CRM architecture
• Example prompt for a CRM
• CRM scaling checklist
• Often combined: SaaS dashboard
• Often combined: AI document chatbot
• All app types