Public security
The security we can describe, and nothing more.
Technical measures that can be verified in the Cortex code: authentication, file isolation, deposits, webhooks and limits. No invented certification.
What this page is, and is not
This page describes mechanisms present in the service code on 11 September 2026. It helps a buyer or a fiduciary understand the control; it does not replace an audit.
It is not an ISO or SOC certificate, a penetration-test report, or a guarantee that no incident will occur. Your account settings stay in the signed-in space.
Account access
Sign-in uses Passport and a session stored in PostgreSQL. The session cookie is httpOnly; in production it is also marked secure.
Passwords are stored as hashes. A TOTP second factor can be enabled; the secret is encrypted with AES-256-GCM, with a key distinct from the session key.
Authenticated API mutations (POST, PUT, PATCH, DELETE) are protected against cross-site requests by a CSRF token. Public paths, webhooks and authentication routes are exempt.
Separation of files
Business data is attached to a file identifier (cible_id). The fiduciary context resolves that file for the signed-in user before reads.
This separation is application-level. PostgreSQL does not apply automatic RLS here. A forgotten filter on a new route would remain a real risk — that is why we say it.
Document deposit
A file is not accepted on its extension alone. The service compares the declared type with the magic bytes and rejects inconsistent content.
Image OCR goes through Google Cloud Vision, by default the European endpoint (eu-vision.googleapis.com). The effective configuration remains to be checked unless there is a versioned operational proof. This step is not Swiss hosting of the image.
Payments and e-mail
Stripe receives payment events. If the webhook signing secret is missing, verification fails instead of accepting the event.
Transactional e-mail goes through Brevo. E-mail webhook signatures are compared in constant time.
Where the service runs
The web application and the worker run on an Infomaniak machine in Switzerland. That describes hosting of the Cortex processes, not every processing step.
The database, OCR, some proposals, payment, e-mail and error tracking use other providers. Their countries and clauses remain to be confirmed; they are listed in the privacy policy.
Retention of source files
The code plans, by default, to delete source files of accounting documents after two days. That is not a GDPR-imposed duration; it is a technical choice.
The effective implementation of this delay remains to be checked before presenting it as guaranteed. Entries and extracted data follow a separate retention, while the account exists.
Honest limits
The rate limiter lives in process memory. It is not shared across several machines.
Security headers (CSP, HTTPS) are applied by the server. No measure can guarantee the complete absence of an incident.
Author, date and sources
Cortex editorial team · updated 11 September 2026. Every claim on this page points to a file in the repository or to an operational confirmation already written. What cannot be proved stays off this page.
- Authentication and sessions: server/auth.ts
- 2FA: server/lib/auth/totp.ts
- CSRF: server/middleware/csrf.ts
- File context: server/middleware/fiduciary-context.ts
- Deposits: server/middleware/upload.ts
- OCR: workflows/OCR/OCR.ts
- Stripe: server/integrations/stripe/stripe.ts
- Brevo: server/middleware/brevo-webhook-signature.ts
- Source purge: common/jobs/gdpr-cleanup.ts