Un comptable disposant de droits en lecture seule pouvait annuler des factures et effacer l'historique des paiements dans l'outil de comptabilité open-source Akaunting, exposant les petites entreprises à une perte de données silencieuse. La faille a été corrigée dans la version 3.2.0, mais l'erreur — lier les contrôles de permission à une liste de noms de méthodes codée en dur — menace toujours tout système reposant sur un contrôle d'accès basé sur les rôles.

Comment le bug s'est glissé

L'API d'Akaunting valide les droits d'un utilisateur en consultant une liste d'autorisation (allowlist) de noms de méthodes. La liste couvrait les opérations CRUD habituelles — create, read, update, delete — mais omettait plusieurs points de terminaison (endpoints) de changement de statut :

  • markSent
  • markCancelled
  • markReceived

Comme ces gestionnaires (handlers) ne figuraient pas sur la liste, le framework n'appelait jamais la routine de vérification des permissions lors de leur exécution. Un utilisateur disposant d'un rôle en lecture seule pouvait émettre une simple requête GET vers l'endpoint markCancelled et le système la traiterait comme un changement d'état légitime.

L'annulation d'une facture fait plus que marquer le document comme nul ; elle supprime également tous les enregistrements de paiement liés à cette facture. Résultat : un utilisateur sans droit de modification peut effacer la trace financière d'une transaction.

Ce que les tests ont révélé

La vulnérabilité est apparue dans l'image Docker officielle d'Akaunting :

  • Une requête PUT standard pour mettre à jour une facture renvoyait 403 Forbidden, confirmant que le chemin de mise à jour habituel était protégé.
  • Une requête GET vers l'endpoint d'annulation réussissait sans erreur d'autorisation, exposant la faille.

Pourquoi c'est important

Les états financiers peuvent être altérés sans piste d'audit claire, ce qui rend la fraude plus difficile à détecter et les erreurs honnêtes plus difficiles à corriger.

Le correctif

La version 3.2.0 élargit la carte des permissions pour inclure les actions de statut précédemment omises. À partir de cette version, toute requête modifiant l'état d'un document — qu'il soit marqué comme envoyé, annulé ou reçu — doit passer par la même vérification de rôle qu'une mise à jour standard. Cela rétablit l'attente selon laquelle un rôle en lecture seule ne peut réellement pas modifier les données.

Leçons pour les développeurs

  • N'assimilez jamais les noms de méthodes à la sécurité. L'ajout d'un nouvel endpoint n'hérite pas automatiquement de la protection ; auditez chaque méthode publique pour détecter d'éventuels effets de bord.
  • Une liste d'autorisation n'est aussi complète que la liste elle-même. Une liste statique de verbes « autorisés » laisse la porte ouverte aux oublis.
  • Séparez l'intention du verbe HTTP. GET est censé être en lecture seule, mais ici, il a effectué un changement d'état. Limitez les mutations aux verbes POST, PUT, DELETE, PATCH.
  • Automatisez les contrôles de couverture des permissions. Les outils d'analyse statique peuvent signaler les méthodes de contrôleur dépourvues d'appel d'autorisation, permettant de détecter les failles avant la mise en production.
  • Testez avec des comptes au privilège minimal. Le test basé sur Docker utilisait un utilisateur en lecture seule ; la reproduction de tels scénarios dans les pipelines CI permet de faire remonter ces problèmes précocement.

Ce qu'il faut surveiller ensuite

La communauté d'Akaunting a déjà publié la version corrigée. Les administrateurs doivent vérifier la version de leur instance et appliquer la mise à jour sans tarder.

Pour les développeurs qui construisent tout système basé sur les rôles, la leçon est claire : un modèle de permissions qui dépend du souvenir de chaque action possible est fragile par conception. Déclarez explicitement quelles opérations modifient l'état, imposez des contrôles au niveau du framework et auditez régulièrement la base de code. Ce n'est qu'à cette condition qu'un label « lecture seule » peut être considéré comme fiable pour maintenir l'intégrité des registres financiers.