Sécurité

Comment ça marche

• Chiffrement de grade bancaire avec un algorithme reconnu et recommandé par les agences de cybersécurité internationales
• Chiffrement authentifié : chaque donnée inclut une signature d'intégrité qui détecte toute altération ou corruption
• Chaque opération utilise un vecteur unique aléatoire. Même montant chiffré deux fois = résultat différent à chaque fois
• Validation stricte du format et de l'intégrité des données avant tout déchiffrement
• Clé de chiffrement propre à chaque utilisateur, tirée aléatoirement à l'inscription et stockée elle-même chiffrée. Une copie de la base, seule, ne permet de déchiffrer aucun compte

Ce qui est chiffré

Mots de passe

• Hachage avec un algorithme de dernière génération, vainqueur d'une compétition internationale de cryptographie et résistant aux attaques par GPU/ASIC
• Paramètres calibrés au-dessus des recommandations OWASP pour résister aux attaques par dictionnaire
• Plancher d'entropie calculé sur la longueur et la variété des caractères, 50 bits minimum d'après le NIST SP 800-63B, au lieu de règles arbitraires ("1 majuscule, 1 chiffre...")
• Refus des motifs répétés et des mots de passe trop pauvres en caractères distincts. Le seul plancher d'entropie ne les voit pas : il compte l'alphabet employé, pas ce qui est écrit avec
• Comparaison aux fuites connues auprès de HaveIBeenPwned, côté serveur, par k-anonymity : seuls les cinq premiers caractères de l'empreinte SHA-1 sont transmis, jamais le mot de passe, et les suffixes sont comparés ici. Si le service ne répond pas, l'inscription passe : votre création de compte ne dépend pas d'un tiers
• Ces trois contrôles ont lieu sur le serveur, et pas seulement dans le navigateur : une requête forgée directement sur l'API les rencontre aussi
• Votre mot de passe n'est jamais stocké ni loggé. Seul un hash irréversible est conservé

Sessions

• Tokens d'authentification dans des cookies httpOnly, inaccessibles depuis JavaScript et immunisés contre les attaques XSS
• Politique same-site stricte : les cookies ne sont jamais envoyés lors de navigations cross-site
• Tokens de courte durée avec rotation automatique à chaque renouvellement
• Rotation atomique : si le renouvellement échoue, l'ancienne session reste valide (pas de déconnexion accidentelle)
• Cinq appareils connectés au maximum par compte. Au delà, c'est celui dont vous vous êtes servi le moins récemment qui est déconnecté, jamais celui qui s'est connecté le premier
• Cache éphémère optionnel : les sessions validées peuvent être mises en cache pendant 5 minutes maximum pour réduire la charge serveur. Le cache est automatiquement invalidé à la déconnexion

Récupération de compte

• Phrase de récupération unique générée à l'inscription. C'est le seul moyen de récupérer un compte en cas de mot de passe oublié
• La phrase est affichée une seule fois et n'est jamais stockée en clair côté serveur
• Tentatives de récupération limitées par heure pour empêcher les attaques par force brute

Contre les attaques par force brute

• Rate limiting sur les routes de connexion et sur l'ensemble de l'API, compté par adresse IP avant authentification et par compte ensuite, de sorte que deux personnes derrière la même connexion ne se pénalisent pas
• Rate limiting par compte : plusieurs échecs consécutifs = verrouillage temporaire automatique
• Double comptage des échecs de connexion : 5 par compte et 10 par adresse IP sur une fenêtre de 15 minutes, puis blocage temporaire
• Détection de spikes : surveillance des erreurs serveur en temps réel pour détecter les attaques automatisées
• Protection renforcée sur les routes sensibles (récupération de compte, changement de mot de passe)

Contre les injections et falsifications

• Protection CSRF obligatoire sur toutes les routes qui modifient des données
• Requêtes paramétrées : aucune injection SQL possible par conception
• Validation stricte côté serveur sur toutes les entrées utilisateur, jamais de confiance au frontend
• Limites sur la taille des requêtes et le nombre d'éléments par opération en masse

Headers de sécurité

• Content-Security-Policy : appliquée sur l'API, qui refuse tout script d'origine tierce. Sur les pages du site, elle est pour l'instant en mode observation : le navigateur signale les scripts non conformes sans les bloquer, le temps de vérifier qu'aucun usage légitime n'est empêché
• HSTS : force HTTPS sur l'ensemble du domaine et des sous-domaines
• Protection anti-clickjacking : l'application ne peut pas être intégrée dans une iframe tierce
• Permissions restrictives : caméra, micro et géolocalisation désactivés par défaut

Export de données (CSV, PDF, email)

• Fonctionnalité désactivée par défaut, activable dans les paramètres
• PDF générés en mémoire côté serveur, jamais écrits sur le disque
• CSV générés côté client dans le navigateur, aucun transit serveur
• Réservés au compte propriétaire du mois, et soumis à un plafond dédié de 5 rapports par quart d'heure, en plus de la limitation générale de l'API
• Transmis directement en TLS (HTTPS), aucun stockage intermédiaire
• Les fichiers exportés contiennent des données déchiffrées -l'utilisateur est averti lors de l'activation

Alertes email

• Contiennent uniquement des agrégats (totaux, pourcentages, catégories) -aucun détail de transaction individuelle
• Transport sécurisé via TLS
• Protection anti-injection HTML sur tous les champs utilisateur dans les emails

Budgets par catégorie

• Plafonds de budget chiffrés avec le même standard que les transactions
• Noms de catégories de budget stockés en clair (métadonnées de rapprochement, non sensibles par design). Les catégories des transactions, elles, sont chiffrées
• Accès strictement limité à votre compte uniquement

Objectifs d'épargne

• Noms et montants des objectifs chiffrés avec le même standard que les transactions
• Accès strictement limité à votre compte uniquement

Journaux d'alertes

• Rétention limitée à 90 jours, nettoyage automatique mensuel
• Contiennent uniquement des métadonnées (type d'alerte, date) -aucune donnée financière

Les versions précédentes (open source)

Les premières itérations du projet sont publiques sur GitHub. Le service s'est appelé FinanceMate jusqu'en août 2026, date à laquelle il a pris le nom d'Ostaq. Ces dépôts n'ont rien à voir avec le code du SaaS actuel, mais ils montrent le chemin parcouru.

Le code actuel

Le code source d'Ostaq dans sa version actuelle n'est pas open source. La solidité du chiffrement et de l'authentification ne repose pas sur ce secret : un algorithme qui aurait besoin d'être caché serait un mauvais algorithme.

Ce qui motive ce choix est ailleurs. Ostaq est un service en ligne qui détient des données financières. Elles sont chiffrées, mais le service qui les sert reste exposé, et je le maintiens seul. Publier l'intégralité du code d'une instance en production, c'est publier sa surface d'attaque, et je ne suis pas à l'aise de le faire dans ces conditions.

Un accès en lecture, portant sur une version figée et pour une durée limitée, peut être accordé à un auditeur mandaté, sur demande motivée et après signature d'un accord de confidentialité. Écrivez à contact@ostaq.com.

Si vous pensez avoir découvert une faille, la marche à suivre est en bas de cette page.

Ce que ça coûte, et pourquoi Ostaq Pro

Gratuit pour vous ne veut pas dire gratuit tout court. Ostaq a un coût réel : l'achat et le renouvellement des noms de domaine, un serveur dimensionné pour encaisser du trafic plutôt que le moins cher du marché, les certificats, la sauvegarde chiffrée hors site. Et surtout du temps, beaucoup, en dehors de mon travail.

Je le finance moi-même, par goût du code et parce que je voulais démontrer qu'une application peut se passer de publicité et de traçage sans rien sacrifier à la sécurité.

Ostaq Pro servira d'abord à couvrir ces frais, puis à consacrer davantage de moyens au produit. C'est le contraire d'un péage sur la sécurité : ce qui protège vos données restera toujours dans la version gratuite.