The security of your data is a priority for us. We follow high security standards for our whole infrastructure, including encryption and compliance with recognized recommendations. For the sake of transparency and continuous improvement, you will find below a list of the measures we are implementing.
Our applications are hosted on servers provided by the company OVH SAS, under the So you Start and OVH Private Cloud brands. Our servers are powered by Ubuntu 16.04 and 18.04. Administrative access to these servers is restricted to a very small number of people and requires strong authentication techniques (RSA keys are mandatory and password access is disabled). You can consult the details of our SSH access configuration at Rebex SSH Check.
On our servers, your data is always encrypted. On our So you Start servers (provided by OVH SAS), your data is stored in TrueCrypt containers (we use TrueCrypt version 7.1a-13). On our OVH Private Cloud servers (provided by OVH SAS), your data is stored on LUKS encrypted partitions (we use the cryptsetup 2.0.2 version).
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.2 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 2017 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 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.
- 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 2013 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.
We had intrusion tests (black and grey box) performed on our servers by Novidy's to assess the security of our infrastructures in September 2019.
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.