Hosting

Our applications are hosted on servers provided by OVH SAS , within the So you Start and OVH Private Cloud ranges. Our servers run on Ubuntu 22.04. Administration access to these servers is restricted to a very small number of people and requires strong authentication techniques (mandatory RSA keys and disabling of password access). You can see the details of our SSH access configuration on the Rebex SSH Check website.

Disk encryption

On our servers, your data is always encrypted. On our OVH Private Cloud servers (provided by OVH SAS), your data is stored on LUKS encrypted partitions (we use the cryptsetup 2.4.3 version).

Exchanges encryption

Data transiting between your device and our application servers is encrypted, both during upload and download. This is confirmed by the padlock in the address bar of your browser and the URL that indicates the use of HTTPS (in our case, HTTP with TLS 1.3 encryption).

You can view the details of our HTTPS encryption configuration at SSL Labs . Certificates authenticating our servers are provided by Let's Encrypt , an automated and open certification authority.

We redirect all HTTP traffic (port 80) to HTTPS (port 443) and have set up the HSTS settings to tell your browser to do the same.

Follow-up of OWASP Top 10 recommendations

OWASP is an open community working on web application security. In particular, they publish a list of the ten most critical safety risks. We pay a particular attention to the top ten risks mentioned in the latest 2021 version of this list.

  • Injection: We do not write any SQL query manually. All our queries to the database are generated by the Laravel's ORM Eloquent which uses the PDO parameter binding to avoid SQL injections.
  • Incorrect authentication: Our servers are protected against account enumeration attacks and massive attempts by password dictionaries. Our platform requires all our employees to use passwords of force 4 on the a href='https://github.com/dropbox/zxcvbn'> Dropbox zxcvbn scale.
  • Disclosure of sensitive data: We do not store your banking data because it is directly handled by our partner Stripe . Your passwords are encrypted by the bcrypt algorithm after random salting and are therefore never kept in clear text. More generally, all your data, both on the network and on our disks, is encrypted (see details above).
  • XML External Entities: Our internal and external APIs are all based on the JSON format and are therefore not affected by XML attacks. The Excel files (in XLSX format, based on XML) that you send for analysis on our servers are handled by Java XML libraries that have been configured according to the Java-specific OWASP recommendations.
  • Incorrect authorization: Each HTTP request made to our application is first analyzed to verify that the user has sufficient permissions to perform the requested action. In particular, it is impossible for one user to access the data of other users.
  • Bad security configuration: Our applications are deployed on bare isolated Ubuntu servers. We use standard installation scripts to ensure that our security configurations are identical.
  • Cross-Site Scripting: All values entered by a user and injected into the rendering of our pages are first escaped by Laravel's rendering engine Blade to avoid XSS attacks.
  • Unsecured deserialization: We never deserialize a data block directly provided by a user. Our use of serialization is limited to caching certain views.
  • Use of vulnerable components: We use dependency management tools that allow us to easily update all the components on which we depend at once: npm for the JavaScript dependencies of the front-end layer, compose for the PHP dependencies of the back-end layer and maven for the Java dependencies of our calculation engines.
  • Insufficient logging and tracking: We log all successful or failed attempts to connect to our platform. System-level queries are also logged and limited in volume.

Thanks to Laravel's default configuration, we are also protected from CSRF attacks (one of the ten risks in the 2021 version of the OWASP list). Indeed, all our entry points triggering an action (HTTP requests such as DELETE, POST, PUT or UPDATE) require the presence of a token linked to the session.

Intrusion tests

We drive intrusion tests every year to assess the security of our infrastructures and applications. Our last intrusion tests (black and grey box) have been performed by Synetis on January 2024.

Reporting vulnerabilities

Since the first release, we have been inviting our users and security researchers to report vulnerabilities they suspect or have identified. To do this, we follow the requirements of securitytxt.org (a proposed standard to allow websites to define their security policy). In particular, we have set up a dedicated contact address and we respond to all incoming messages.

Free trial