Compliance portal security
Compliance portal security checklist
Before you launch a compliance portal, check authz, compliance, uploads, pii and abuse. The rules below are the ones this category most often gets wrong; each one is concrete enough to test.
Last checked
Security: authz
- RLS on entity_id for every entity-owned table plus role checks in one guard; auditors are read-only; every id is re-verified against the caller's entity scope (no IDOR).
Security: compliance
- Reported numbers are computed only by deterministic code from versioned factors; model output is never a value until a human accepts it; locked periods refuse in-place updates.
Security: uploads
- Documents are size and page capped, content-type verified, hashed on ingest and stored under entity-prefixed keys; extracted text is treated as untrusted input in every prompt.
Security: pii
- Documents may contain personal and commercial data: minimise stored fields, exclude document text from logs, support export and erasure per policy.
Security: abuse
- Upload, extraction and export endpoints are rate limited per entity and per user, and AI spend is capped per entity per day and fails closed.
Security: secrets
- AI keys and regulator credentials are write-only server secrets, never returned to the client or logged.
Compliance notes
- Regulatory frameworks (applies to regulator-facing exports): Disclosure codes and rules change; keep them as versioned data with citations, never assert a code as verified without evidence.
- Audit evidence (applies to assured reporting): Retain source documents, hashes, approvals and the audit trail for the regulator's retention period.
- GDPR (applies to EU users): Utility bills and staff data can be personal data: lawful basis, minimisation, retention and erasure.
Limits that stop abuse and surprise bills
- ai extraction usd per entity day: capped by ENTITY_DAILY_AI_USD_CAP; over the cap extraction is refused and manual entry still works.
- storage per entity: document size and page caps; locked periods archived to cheap storage.
Test it yourself before launch
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 background jobs, file uploads and search are rolling out; email sent from your app is coming soon, so anything here that needs it 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.
FAQ
- What is the biggest security risk in a compliance portal?
- RLS on entity_id for every entity-owned table plus role checks in one guard; auditors are read-only; every id is re-verified against the caller's entity scope (no IDOR).
- Does a compliance portal have compliance obligations?
- Regulatory frameworks, if you have regulator-facing exports: Disclosure codes and rules change; keep them as versioned data with citations, never assert a code as verified without evidence. 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.
Build your app with Forge64
One prompt to a running app with auth, database, hosting and payments. Start free, no credit card required.
Start building for free