Vos finances sont chiffrées, pas simplement stockées
Chaque montant, chaque transaction, chaque note est chiffré individuellement avec un algorithme de grade bancaire avant d'atteindre notre base de données. Un attaquant qui obtiendrait une copie de la base n'y lirait aucun montant.
Chiffrement au repos
Aucune donnée financière en clair dans la base
Hachage moderne
Mots de passe protégés par un algorithme résistant aux GPU
HTTPS forcé
Connexion chiffrée obligatoire sur toute l'application
Administration cloisonnée
Aucune page d'administration ne déchiffre vos données
Hébergé en France
Données stockées en Union Européenne, conformité RGPD
Anti brute-force
Protection multi-couches contre les tentatives d'intrusion
1. Chiffrement des données
Toutes vos données sensibles sont chiffrées avant d'être stockées en base de données. Le chiffrement et le déchiffrement ont lieu sur le serveur, à chaque requête : la base ne contient que du chiffré, et votre navigateur ne reçoit que ce que votre compte a le droit de voir.
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é
Transactions
Montants, titres, descriptions, notes, montant total de financement
Dépenses fixes
Montants, titres, valeurs de partage, montants/pourcentages par personne
Mois
Solde initial
Templates
Titres, catégories, descriptions
Budgets & Financements
Plafonds de budget, montants des échéances, montants de remboursement attendus
Profil
Salaire (si configuré), identifiants bancaires (PRO)
Ce qui n'est pas chiffré (et pourquoi)
Vos tags et les noms de catégories de vos budgets sont stockés en clair. Ils servent au filtrage et au rapprochement des plafonds, opérations qui portent sur le libellé lui-même.
Les catégories de vos transactions et dépenses fixes sont, elles, chiffrées comme le reste.
Les champs laissés en clair ne contiennent pas de données personnelles sensibles : ce sont des libellés génériques comme "Loyer", "Alimentation" ou "Loisirs", jamais des montants ni des informations d'identification.
Ce que contient la base de données
Voici ce qui est réellement stocké pour un montant de 42,50 euros. Les trois parties sont le vecteur d'initialisation, la signature d'intégrité, puis le montant chiffré. Illisible sans la clé de votre compte.
Pourquoi le chiffrement a lieu sur le serveur
Vos données sont chiffrées avec une clé propre à votre compte. Cette clé est elle-même protégée par une clé maître qui n'est stockée ni dans la base, ni dans les sauvegardes : elle n'existe que dans la configuration du serveur. C'est ce qui rend une copie de la base, ou un dump de sauvegarde dérobé, inexploitable en l'état.
Ce choix d'architecture est ce qui permet au serveur de calculer votre reste à vivre, vos statistiques et vos rapports, de déclencher vos alertes, et surtout de vous rendre l'accès à votre compte en cas de mot de passe oublié sans vous faire perdre une seule transaction. Un modèle où seul votre navigateur détiendrait la clé, dit « zero-knowledge », interdirait tout cela : un mot de passe et une phrase de récupération égarés signifieraient des données perdues définitivement.
Autrement dit, Ostaq fonctionne comme votre banque ou votre logiciel de comptabilité : le service doit pouvoir lire vos données pour les traiter. Le cloisonnement, lui, va plus loin que l'usage : aucune page d'administration ne déchiffre de donnée financière, et aucun montant déchiffré n'est écrit dans les journaux du serveur.
Mon engagement sur l'accès à vos données
Je suis la seule personne à administrer ce serveur, et je m'engage contractuellement, à l'article 8.1 des conditions générales, à ne jamais consulter vos données financières, à ne jamais les extraire ni les transmettre à un tiers, et à ne répondre à une réquisition que dans les strictes limites de la loi.
Cet engagement n'est pas une formule : figurant aux CGU, il est contractuel. Y manquer constituerait un traitement de données étranger aux finalités déclarées, au sens du RGPD, et relèverait de la CNIL.
Pour que cet engagement ne repose pas seulement sur ma parole, tout déchiffrement effectué en dehors de l'application passe par un outil unique, qui refuse de fonctionner sans un motif écrit et inscrit dans un journal d'audit la date, ce motif, le compte concerné et le volume de données lues. Ce journal est conservé douze mois. En fonctionnement normal, il ne contient aucune ligne de ce type.
Il faut en dire la limite : ce journal est écrit sur le serveur qui détient la clé. Quelqu'un capable de déchiffrer la base serait aussi capable de le modifier. Ce dispositif rend une consultation traçable, il ne la rend pas impossible — la seule garantie technique en la matière serait un modèle où le serveur ne détient aucune clé, et cette page explique plus bas pourquoi Ostaq ne l'a pas retenu.
Un engagement porte sur ce que je fais, pas sur ce qu'un attaquant pourrait faire. C'est précisément l'objet du reste de cette page : la clé maître hors base et hors sauvegardes, l'administration cloisonnée, l'absence de données sensibles dans les journaux, et les protections décrites ci-dessous.
Note de transparence : la pile technique et les paramètres de sécurité sont publiés dans la documentation technique. Le code source lui-même n'est pas ouvert, mais reste consultable sur demande dans le cadre d'un audit de sécurité.
2. Authentification et sessions
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
- Validation de l'entropie réelle du mot de passe, pas de règles arbitraires ("1 majuscule, 1 chiffre..."), mais une vraie mesure mathématique de sa robustesse
- 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)
- Nombre de sessions limitées par compte. Les plus anciennes sont automatiquement révoquées
- 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
3. Protection de l'API
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 : bloque l'exécution de scripts non autorisés
- 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
4. Infrastructure et hébergement
- Hébergé en France, données stockées en Union Européenne, conformité RGPD totale
- Aucun service tiers dans le fonctionnement du site : pas de Google Analytics, pas de CDN externe, pas de police distante. Seules les sauvegardes sortent du serveur, vers Google Drive, comme détaillé dans la politique de confidentialité
- Infrastructure maîtrisée de bout en bout : chaque composant du serveur est géré directement, sans couche d'abstraction superflue, pour un contrôle total et une surface d'attaque minimale
- Pare-feu actif + blocage automatique des IP malveillantes
- Connexion chiffrée TLS avec certificat renouvelé automatiquement
- Sauvegardes quotidiennes conservées hors du serveur, récupération possible en cas d'incident. Les colonnes financières y restent chiffrées, et un dump récupéré sans la clé maître n'en révèle aucun montant
- Cache en mémoire optionnel : les données de session et les clés de chiffrement peuvent être mises en cache temporairement (5 à 10 minutes) pour améliorer les performances. Ce cache est automatiquement invalidé à la déconnexion ou au changement de mot de passe, et l'application fonctionne normalement sans lui
- Le serveur refuse de démarrer si une variable de sécurité critique est manquante ou mal configurée
5. Veille et amélioration continue
La sécurité n'est pas un état, c'est un processus. Nous assurons une veille active sur les vulnérabilités connues, les recommandations des organismes de référence (OWASP, ANSSI, NIST) et les bonnes pratiques du secteur.
- Revue régulière des dépendances et mise à jour proactive des bibliothèques
- Suivi des CVE (vulnérabilités publiées) sur l'ensemble de la stack
- Renforcement continu : chaque nouvelle fonctionnalité passe par une revue de sécurité avant mise en production
- Logs structurés avec politique Zero Data Leak : aucune donnée financière n'apparaît dans les logs, jamais
- Journal d'audit de sécurité dédié : chaque connexion, déconnexion, tentative échouée, changement de mot de passe et suppression de compte est enregistré dans un fichier d'audit séparé pour la traçabilité des événements de sécurité
- Traçabilité des accès hors application : tout déchiffrement effectué en dehors de l'application y est également inscrit, avec son motif. Journaux conservés douze mois, par rotation quotidienne
- Le panneau d'administration n'expose aucune donnée financière, uniquement les métadonnées nécessaires à la gestion du service
6. Gratuit ou PRO : même niveau de sécurité
La sécurité n'est pas une fonctionnalité premium. Tous les utilisateurs d'Ostaq bénéficient du même chiffrement, de la même protection et des mêmes standards de sécurité, que vous utilisiez la version gratuite ou PRO.
Version gratuite
- Chiffrement AES-256-GCM des données financières
- Hachage de mot de passe dernière génération
- Protection CSRF, rate limiting, headers sécurité
- Hébergement France, zero tiers
Version PRO
- Tout ce qui est dans la version gratuite
- Exports (PDF, CSV) générés en mémoire, jamais stockés sur disque
- Alertes email contenant uniquement des agrégats (aucun détail de transaction)
- Budgets par catégorie avec plafonds chiffrés
- Synchronisation bancaire sécurisée via API PSD2Bientôt
- Données bancaires chiffrées avec le même standard
7. Fonctionnalités PRO : mesures de sécurité spécifiques
Les fonctionnalités PRO introduisent des traitements supplémentaires soumis à des mesures de sécurité dédiées.
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
8. L'histoire derrière Ostaq
L'idée d'Ostaq a longtemps germé dans ma tête, bien avant de savoir coder. Dès 2020-2021, en apprenant la programmation en DUT Informatique, l'envie de créer un outil pour gérer mes finances ne m'a jamais vraiment quitté. En début 2023, pendant ma licence, j'ai décidé de passer à l'action et de coder les premières versions : je n'arrivais pas à gérer mes dépenses ni à prévoir combien il me restait réellement après mes charges fixes.
À la base, le produit actuel était uniquement pour moi et ma compagne. Mais il a été tellement apprécié par notre entourage que j'ai décidé d'en faire un vrai service, accessible à tous. J'ai continué à itérer, version après version, en parallèle de mon travail de Lead Support Engineer. Le projet a évolué au fil du temps, mais l'objectif est resté le même : un outil de gestion financière simple, efficace et respectueux de ses utilisateurs.
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. C'est un choix assumé pour protéger le produit, pas la sécurité : la robustesse du chiffrement et de l'authentification ne repose pas sur le secret du code.
Pour les chercheurs en sécurité ou dans le cadre d'un audit, le code source est consultable sur demande. Contactez-moi à contact@ostaq.com.
Aujourd'hui, Ostaq est un projet que je développe avec soin en dehors de mon travail. Ce n'est pas un side project bâclé : j'y consacre du temps, de l'énergie, et je m'efforce de fournir un produit de qualité. Sans publicité, sans tracking, sans revente de données, dans le respect total du RGPD et des recommandations de la CNIL.
Pourquoi gratuit ? Parce que je crois qu'on devrait pouvoir gérer son argent sans en dépenser, et sans sacrifier sa vie privée. La sécurité et le respect de vos données ne sont pas des options payantes.
9. Ce qu'Ostaq ne fera jamais
Signaler une vulnérabilité
Si vous découvrez une faille de sécurité, merci de la signaler de manière responsable. Ne publiez pas la vulnérabilité publiquement avant qu'elle ne soit corrigée.
Contact : contact@ostaq.com
Chiffrez votre message avec notre clé GPG publique disponible dans les mentions légales.