Seorang akuntan dengan akses read-only dapat membatalkan faktur dan menghapus riwayat pembayaran di alat pembukuan sumber terbuka Akaunting, yang mengekspos bisnis kecil pada kehilangan data secara diam-diam. Celah ini telah diperbaiki pada versi 3.2.0, namun kesalahannya—mengaitkan pemeriksaan izin ke daftar nama metode yang bersifat hard-coded—masih mengancam sistem apa pun yang mengandalkan kontrol akses berbasis peran (role-based access control).

Bagaimana bug tersebut lolos

API Akaunting memvalidasi hak pengguna dengan merujuk pada allowlist nama metode. Daftar tersebut mencakup operasi CRUD biasa—create, read, update, delete—tetapi melewatkan beberapa endpoint pengubah status:

  • markSent
  • markCancelled
  • markReceived

Karena handler tersebut tidak ada dalam daftar, framework tidak pernah memanggil rutinitas pemeriksaan izin saat dijalankan. Pengguna dengan peran read-only dapat mengirimkan permintaan GET sederhana ke endpoint markCancelled dan sistem akan menganggapnya sebagai perubahan status yang sah.

Membatalkan faktur tidak hanya menandai dokumen sebagai batal; hal ini juga menghapus semua catatan pembayaran yang terkait dengan faktur tersebut. Hasilnya: pengguna tanpa hak edit dapat menghapus jejak keuangan dari suatu transaksi.

Apa yang ditunjukkan oleh pengujian

Kerentanan tersebut muncul pada Docker image resmi Akaunting:

  • Permintaan PUT standar untuk memperbarui faktur mengembalikan 403 Forbidden, yang mengonfirmasi bahwa jalur pembaruan reguler telah terlindungi.
  • Permintaan GET ke endpoint pembatalan berhasil tanpa kesalahan otorisasi, yang mengungkap celah tersebut.

Mengapa ini penting

Laporan keuangan dapat diubah tanpa jejak audit yang jelas, sehingga penipuan lebih sulit dideteksi dan kesalahan yang tidak disengaja lebih sulit diperbaiki.

Perbaikan

Versi 3.2.0 memperluas peta izin untuk menyertakan tindakan status yang sebelumnya terlewatkan. Sejak rilis tersebut, setiap permintaan yang mengubah status dokumen—baik ditandai sebagai terkirim, dibatalkan, atau diterima—harus melewati verifikasi peran yang sama dengan pembaruan standar. Hal ini mengembalikan ekspektasi bahwa peran read-only benar-benar tidak dapat mengubah data.

Pelajaran bagi pengembang

  • Jangan pernah menyamakan nama metode dengan keamanan. Menambahkan endpoint baru tidak secara otomatis mewarisi perlindungan; audit setiap metode publik untuk melihat efek sampingnya.
  • Allowlist hanya selengkap daftar itu sendiri. Daftar statis dari kata kerja "baik" membuka pintu bagi kelalaian.
  • Pisahkan niat dari kata kerja HTTP. GET dimaksudkan untuk read-only, tetapi di sini ia melakukan perubahan status. Batasi mutasi pada POST, PUT, DELETE, PATCH.
  • Otomatiskan pemeriksaan cakupan izin. Alat analisis statis dapat menandai metode controller yang kekurangan panggilan otorisasi, menangkap celah sebelum dirilis.
  • Uji dengan akun least-privilege. Pengujian berbasis Docker menggunakan pengguna read-only; mereplikasi skenario seperti itu dalam pipeline CI akan memunculkan masalah serupa lebih awal.

Apa yang perlu diperhatikan selanjutnya

Komunitas Akaunting telah merilis versi yang telah diperbaiki. Administrator harus memverifikasi versi instansi mereka dan segera menerapkan pembaruan.

Bagi pengembang yang membangun sistem berbasis peran apa pun, pelajarannya jelas: model izin yang bergantung pada ingatan akan setiap tindakan yang mungkin terjadi bersifat rapuh secara desain. Deklarasikan secara eksplisit operasi mana yang mengubah status, terapkan pemeriksaan di tingkat framework, dan audit basis kode secara rutin. Hanya dengan cara itulah label "read-only" dapat dipercaya untuk menjaga catatan keuangan tetap utuh.