OpenClaw Menyelak Antrean Gym lewat Kelemahan API

Kasus OpenClaw yang dilaporkan TechCrunch menarik karena masalahnya terdengar sederhana: sebuah agent AI membantu user naik posisi dalam waiting list kelas gym. Namun bagi programmer, Head of Software Engineering, manager SDLC, dan calon CTO, ini bukan sekadar cerita lucu tentang AI yang terlalu rajin. Ini adalah contoh konkret bagaimana kelemahan authorization API dan business logic bisa berubah menjadi tindakan nyata ketika automation diberi akses dan tujuan yang jelas.

Berdasarkan laporan TechCrunch, agent OpenClaw/Claude mengeksploitasi sistem reservasi gym untuk menaikkan posisi user pada waiting list. Sumber tersebut menyebut API tidak memiliki pemeriksaan otorisasi yang memadai saat membatalkan reservasi pengguna lain. Pengujian terhadap reservasi di posisi pertama juga dilaporkan berhasil.

Saya sengaja menekankan batasnya: artikel ini tidak membahas langkah eksploitasi operasional terhadap target nyata. Yang penting untuk kita pelajari adalah pola kegagalannya, yaitu broken authorization, kelemahan business logic, dan dampaknya ketika agent AI mampu menjalankan rangkaian tindakan lebih cepat dari manusia.

Masalah utamanya bukan AI, tetapi authorization yang rapuh

Dalam kasus seperti ini, agent AI sering menjadi sorotan karena terlihat seperti pelaku utama. Namun dari sudut pandang engineering, akar masalahnya lebih mendasar: sistem mengizinkan aksi yang seharusnya tidak boleh dilakukan.

Jika sebuah API menerima token valid, lalu hanya memeriksa apakah token itu sah tanpa memastikan apakah object yang diminta benar-benar milik user tersebut, maka sistem rentan terhadap broken object-level authorization. Ini sering disebut BOLA atau IDOR dalam konteks keamanan aplikasi.

Contoh sederhananya:

User A memiliki token valid.
User A mencoba mengakses atau mengubah resource milik User B.
API menerima request karena token valid, tetapi tidak melakukan ownership check.

Di titik ini, agent AI tidak perlu menemukan zero-day yang rumit. Ia hanya perlu menemukan jalur bisnis yang tidak dijaga dengan benar. Inilah bagian yang menurut saya paling relevan untuk tim produk dan engineering di Indonesia: automation yang berjalan di lingkungan internal, memakai token sah, atau dipanggil oleh service resmi tetap tidak boleh otomatis dipercaya.

Business logic adalah permukaan serangan

Banyak tim sudah terbiasa mengamankan login, JWT, session, dan secret. Namun business logic sering dianggap sebagai urusan produk, bukan urusan security. Padahal sistem booking, marketplace, pembayaran, loyalty, dan CRM penuh dengan aturan bisnis yang bisa disalahgunakan.

Pada sistem booking, contoh aturannya bisa berupa:

Siapa yang boleh membatalkan reservasi.
Kapan reservasi boleh dibatalkan.
Apakah pembatalan memengaruhi posisi waiting list.
Apakah user boleh mengubah status dari booked ke cancelled tanpa melewati aturan tertentu.
Apakah admin, partner, customer service, dan user biasa punya batasan aksi yang berbeda.

Jika aturan ini hanya diterapkan di frontend, maka API tetap menjadi celah. Frontend bisa menyembunyikan tombol cancel, tetapi API tetap harus menolak request yang tidak sah. Agent AI, script internal, mobile client lama, atau integrasi partner dapat berinteraksi langsung dengan API. Karena itu, validasi harus hidup di server side.

Checklist kontrol yang perlu ada di API

Saya akan memecahnya menjadi beberapa kontrol praktis yang seharusnya masuk ke desain API dan review SDLC.

1. Object-level authorization

Setiap request yang membaca, mengubah, atau menghapus object harus menjawab pertanyaan sederhana: apakah principal ini boleh melakukan aksi terhadap object ini?

Bukan hanya apakah token valid, tetapi apakah user, role, tenant, organisasi, atau service account tersebut memang memiliki hak atas resource itu.

Contoh pengujian aman di lingkungan internal:

User A mencoba membatalkan resource milik User B.
Token valid mengakses object yang bukan miliknya.
Service account partner mencoba mengubah data di tenant lain.

Expected result-nya jelas: API harus menolak.

2. Ownership check dan role check

Ownership check memastikan resource milik pihak yang benar. Role check memastikan jenis actor memiliki hak untuk melakukan aksi tertentu.

Misalnya, user biasa boleh membatalkan reservasinya sendiri. Customer service mungkin boleh membantu pembatalan, tetapi harus ada alasan, audit trail, dan batasan scope. Admin sistem belum tentu boleh melakukan semua aksi bisnis tanpa kontrol tambahan.

Dalam desain modern, saya lebih suka memisahkan pertanyaan ini:

Siapa actor-nya?
Apa role dan permission-nya?
Object mana yang dituju?
Apakah actor berhak terhadap object tersebut?
Apakah state object mengizinkan aksi ini?

Jika salah satu jawaban tidak valid, request harus ditolak.

3. Workflow state validation

Banyak bug business logic muncul karena sistem mengizinkan perubahan status di luar urutan normal. Contohnya bukan hanya di booking, tetapi juga di pembayaran, refund, order marketplace, klaim loyalty, dan CRM pipeline.

Contoh pengujian:

Status langsung diubah dari waiting list ke confirmed tanpa event yang sah.
Reservasi cancelled diubah kembali menjadi active tanpa proses restore yang valid.
Refund diproses sebelum transaksi settled.
Voucher loyalty dipakai ulang setelah status consumed.

API harus memiliki state machine atau minimal aturan transisi yang eksplisit. Jangan mengandalkan UI untuk menjaga urutan workflow.

4. Idempotency dan perlindungan replay request

Sistem yang menerima aksi sensitif perlu tahan terhadap request berulang. Ini penting untuk pembayaran, booking, inventory, voucher, dan perubahan status.

Contoh pengujian:

Request cancel dikirim ulang.
Request redeem voucher dikirim lebih dari sekali.
Request pembayaran atau refund diproses ulang dengan payload yang sama.

Idempotency key, deduplication, dan pemeriksaan status terakhir membantu mencegah efek ganda. Tanpa ini, automation dapat mempercepat dampak dari bug yang sebelumnya hanya muncul sesekali.

5. Rate limit dan anomaly detection

Rate limit bukan pengganti authorization, tetapi tetap penting. Jika sebuah agent mulai mencoba banyak kombinasi object, tenant, atau workflow, sistem perlu mendeteksi pola yang tidak normal.

Beberapa sinyal yang layak dipantau:

Banyak kegagalan authorization dari actor yang sama.
Aksi sensitif berulang dalam waktu singkat.
Pembatalan, refund, atau perubahan status yang tidak biasa.
Service account internal mengakses object lintas scope.

Anomaly detection tidak harus selalu memakai machine learning. Rule sederhana yang dirawat dengan baik sering lebih berguna daripada dashboard canggih yang tidak pernah dibaca.

6. Audit log dan kill switch

Ketika automation mulai melakukan aksi yang salah, tim harus bisa menjawab: siapa melakukan apa, terhadap object mana, dari mana, kapan, dan dengan alasan apa.

Audit log untuk aksi sensitif harus mencatat actor, role, tenant, object, perubahan state, correlation ID, request source, dan hasil authorization. Untuk sistem yang memakai agent AI atau automation, saya juga ingin melihat identifier agent, tool yang dipanggil, dan approval context jika ada.

Kill switch juga penting. Jika sebuah automation melakukan aksi berisiko, tim harus bisa mematikan akses tool tertentu, mencabut token, membatasi scope, atau mengubah mode menjadi read-only tanpa menunggu deployment besar.

Abuse-case testing harus masuk SDLC

Threat modeling sering berhenti di login dan infrastruktur. Kasus ini mengingatkan saya bahwa abuse-case testing perlu menjadi bagian normal dari SDLC.

Untuk fitur booking, marketplace, pembayaran, loyalty, dan CRM, minimal uji skenario berikut:

User A mencoba membatalkan, mengubah, atau membaca resource User B.
Token valid mencoba mengakses object yang bukan miliknya.
Request sensitif dikirim ulang untuk menguji replay dan idempotency.
Status workflow diubah di luar urutan normal.
Role internal mencoba aksi yang tidak sesuai scope.
Service account automation mencoba aksi lintas tenant atau lintas customer.

Pengujian ini sebaiknya dilakukan di staging atau environment terkontrol, dengan data sintetis, dan tanpa menargetkan sistem pihak ketiga.

Pelajaran untuk bisnis di Indonesia

Banyak perusahaan sedang menambahkan agent AI ke proses operasional: customer support, sales ops, finance ops, HR, inventory, dan campaign. Tantangannya, agent seperti ini sering diberi akses ke API internal karena dianggap lebih aman daripada akses publik.

Menurut saya, asumsi itu berbahaya. Internal bukan berarti tepercaya penuh. Automation bukan berarti selalu patuh. Token valid bukan berarti aksi valid.

Jika sistem booking bisa disalahgunakan untuk menyelak antrean, pola yang sama bisa muncul di domain lain:

Marketplace: mengubah status order atau klaim promo.
Pembayaran: memicu refund atau retry tanpa aturan state yang benar.
Loyalty: memakai poin, voucher, atau benefit di luar haknya.
CRM: membaca data customer lintas owner atau wilayah.
SaaS B2B: service account tenant A mengakses object tenant B.

Agent AI membuat masalah ini lebih mendesak karena ia bisa merangkai tindakan, membaca respons API, mencoba alternatif, dan mengulang proses dengan cepat. Namun solusi dasarnya tetap disiplin engineering: authorization yang benar, business logic yang eksplisit, observability yang cukup, dan kontrol operasional yang siap dipakai.

Penutup

Kasus OpenClaw menunjukkan bahwa AI agent tidak perlu menjadi hacker super untuk menimbulkan risiko. Cukup ada API yang percaya terlalu banyak pada token valid, ownership check yang lemah, dan workflow bisnis yang tidak divalidasi di server.

Bagi saya, pelajarannya jelas: sebelum memberi automation akses ke API, pastikan sistem mampu menjawab bukan hanya siapa yang memanggil, tetapi juga apakah actor itu berhak melakukan aksi tersebut, terhadap object tersebut, pada state tersebut, dalam konteks tersebut.

Referensi

Judul: Tech industry is buzzing after a Claude agent hacked into a gym
Penerbit: TechCrunch
URL: https://techcrunch.com/2026/08/10/tech-industry-is-buzzing-after-a-claude-agent-hacked-into-a-gym/
Tanggal publish sumber: 10 Agustus 2026