Public legal
Security
Public security boundaries for DossierCFO upload, scan, support, and reports.
Security
DossierCFO handles sensitive financial documents and keeps upload, scan, review, AI, and export boundaries separate.
Upload and scan
Primary uploads and evidence uploads are validated server-side for supported extension, MIME type, size, stored-byte SHA-256 checksum, and practical file signatures. Evidence uploads are stored when the file format is supported; relevance, completeness, source mapping, and confidence decide whether the contents can unlock facts, reports, or exports. Pending, scanner_failed, infected, MIME-mismatch, unsupported, or parser-incompatible states must not unlock reports or exports.
Scan state is updated only by the server scan/archive path. ZIP intake blocks path traversal, duplicate paths, nested archives, password/corrupt archives, oversized entries, unsupported executable content, and EICAR-like sentinel content. An authenticated client cannot directly set a scan to clean or create clean virtual ZIP entries through the public API.
Export finalization is internal to the server. An authenticated client cannot attach arbitrary storage or convert a blocked/non-PDF export to ready through the public API.
Access and ownership
Protected areas require a verified session. Documents, reports, exports, and evidence links must stay bound to the owner or expected token.
Workspace isolation uses the authenticated user as the operational tenant boundary. Projects, dossiers, analyses, documents, evidence requests, report exports, AI threads, tool calls, storage URLs, and deletion paths are read or changed only after the owning record is verified; cross-user attempts return non-enumerating errors. Audit events derive tenant, analysis, and actor scope from the owned record or valid evidence link, not from a shared global tenant.
Runtime secrets
Runtime secrets are managed through a dedicated FocusDigital Bitwarden Secrets Manager bootstrap. CI and operator workflows load the selected Bitwarden project for the requested runtime mode and validate required keys before use. Direct provider secrets do not need to be stored in GitHub, apart from the Bitwarden machine-account token, project identifiers, and Bitwarden server URL when required.
Local Google OAuth testing uses the dedicated Portless profile on https://local.dossiercfo.focus-digital.it for the app and https://auth.local.dossiercfo.focus-digital.it/api/auth/callback/google for the Better Auth callback. Standard localhost development remains separate from that OAuth profile.
Incidents
Auth/email, storage, OCR, AI provider, malicious upload, possible PII leak, or data-deletion incidents must follow runbooks with owner, severity, containment steps, and customer communication.
Report suspected incidents to info@focus-digital.it with subject prefix Security incident. The operator must assess whether containment, customer notice, provider escalation, or supervisory-authority notification is required before restoring normal processing.