Security measures

This page lists the security measures actually in place in the platform, and names those that are not yet. It describes no certification: none has been obtained to date.

Identity and access

• passwords are stored as argon2id hashes;
• mandatory second factor (TOTP time-based codes) for every human account, with protection against code replay; each account's key is encrypted at rest (AES-256-GCM), with a key kept outside the database;
• revocable server-side sessions, of which only the fingerprint is kept; lockout after repeated failures, identical responses whatever the cause of a failure;
• roles in three exclusive families (configuration, decision, audit), no self-elevation, step-up verification for sensitive actions; rights are enforced by the server.

Separation of institutions

Each institution has its own database schema, protected by row-level security that is enabled and forced, and by a context carried by the transaction. The application connects with a role that can neither bypass these rules nor modify the audit trail. Isolation is tested at every integration, negative control included. See Architecture overview.

Audit trail

Each institution has its own audit chain: every event is timestamped and chained to the previous one by a SHA-256 fingerprint, within the same transaction as the operation it records. The trail is append-only: the application role can only read and append, and a database guard refuses any modification or deletion, including by the owner of the tables. A verifier recomputes the chain and points to the first invalid event. Events contain no free text that could carry personal data.

Consultations are logged in the same chain: every read of an application (record, evaluation, applicant history, consents, provenance) records, in the very transaction of the read, who consulted which application and which view; a worklist page records the number of applications shown. No value read is copied, and a refused read leaves no trace.

The real level is stated without rounding up: the trail is tamper-evident, not tamper-proof. An actor with full rights on the database who rewrote the whole end of the chain while recomputing every fingerprint would produce a consistent chain, because no fingerprint is yet anchored outside the database.

Web surface

The interface and the portal are served with strict headers: content security policy, HSTS, framing ban, nosniff, restrictive referrer and permissions policies. The session token is never exposed to the browser.

Secrets, dependencies and containers

No secret is versioned, and detection covers the code as well as its history. Dependencies are audited and their licences checked at every integration. Containers run as an unprivileged user; the reference stack mounts their file system read-only, and the Python package installer is removed from the API image.

What is still under construction

• end-to-end encryption of exchanges in production: there is no production environment yet; only pre-production is served over HTTPS, with its database reached over an encrypted connection;
• no field-level encryption of credit data; only the second-factor key is encrypted that way;
• no external anchoring of the audit trail and no third-party timestamping;
• no security audit by an independent third party has been carried out yet.