Dua sistem dapat terintegrasi tanpa satu pun error. Schema sesuai, tipe data benar, versioning terkendali, dan setiap request berhasil diproses. Dari sisi teknis, integrasi tersebut terlihat matang.

Namun, ada pertanyaan lain yang sering tidak diajukan: apakah seluruh data yang dikirim memang perlu diterima oleh sistem tujuan?

Sebuah API mungkin hanya membutuhkan customer_id, status transaksi, dan nilai pembayaran. Namun karena objek pelanggan sudah tersedia, developer memilih mengirim nama lengkap, email, nomor telepon, alamat, bahkan sejumlah informasi internal sekaligus.

Tidak ada schema yang rusak. Tidak ada parsing error. Contract berjalan sebagaimana dirancang.

Justru di situlah masalahnya.

Data contract yang hanya memastikan kesamaan format belum tentu memastikan keamanan data. Dalam integrasi modern, contract juga perlu menentukan batas: data apa yang boleh berpindah, siapa yang boleh menerimanya, dan informasi apa yang tidak boleh melewati sebuah sistem.

API yang Konsisten Masih Bisa Mengirim Terlalu Banyak Data

Ketika membangun integrasi API, konsistensi sangat penting. Producer dan consumer perlu memahami field yang sama agar sistem tidak gagal ketika data dipertukarkan.

Masalahnya, keberhasilan schema validation hanya membuktikan bahwa struktur data sesuai dengan aturan.

Ia tidak membuktikan bahwa data tersebut memang pantas diberikan kepada consumer.

Misalnya, sebuah objek pelanggan memiliki struktur:

customer_id

name

email

phone

address

account_status

internal_notes

Sebuah aplikasi operasional mungkin hanya membutuhkan customer_id, name, dan account_status.

Jika seluruh objek tetap dikirim, secara teknis response tersebut valid. Namun dari sisi API security, sistem memberikan informasi lebih banyak daripada kebutuhan bisnisnya.

Prinsip serupa menjadi perhatian dalam OWASP API Security Top 10 melalui risiko Broken Object Property Level Authorization. Masalah tidak selalu muncul karena pengguna berhasil mengakses objek milik orang lain. Risiko juga dapat terjadi ketika pengguna yang memiliki akses terhadap sebuah objek menerima properti yang sebenarnya tidak boleh dilihatnya.

Dengan kata lain, authorization tidak cukup berhenti pada pertanyaan:

“Apakah pengguna boleh mengakses customer ini?”

Masih ada pertanyaan kedua:

“Field apa saja dari customer tersebut yang boleh dilihat?”

Authorization yang Berhenti pada Endpoint Terlalu Kasar untuk API Modern

Banyak kontrol akses dirancang pada tingkat endpoint.

Role tertentu boleh memanggil /customer.

Role lain boleh memanggil /transaction.

Pendekatan tersebut diperlukan, tetapi belum tentu cukup.

Dalam satu objek dapat terdapat berbagai tingkat sensitivitas data.

Tim customer service mungkin membutuhkan nama dan nomor kontak pelanggan. Tim keuangan membutuhkan status pembayaran. Tim risk management mungkin memiliki akses terhadap informasi tambahan yang tidak diperlukan oleh dua tim sebelumnya.

Jika seluruh role memperoleh objek yang sama hanya karena mereka boleh mengakses endpoint yang sama, batas keamanan menjadi terlalu luas.

Di sinilah data contract seharusnya berperan lebih jauh.

Contract bukan hanya menyatakan:

email: string

Tetapi secara konseptual juga dapat menetapkan bahwa:

email

classification: PII

allowed_consumer: CustomerService

Sementara field lain dapat memiliki klasifikasi berbeda.

internal_risk_score

classification: confidential

allowed_consumer: RiskManagement

Implementasinya dapat berbeda pada setiap arsitektur. Namun prinsipnya sama: struktur data dan izin penggunaan data perlu dibicarakan dalam kontrak yang sama.

Data Contract Seharusnya Menjawab “Siapa Boleh Menerima Apa?”

Data contract sering dipandang sebagai kesepakatan antara producer dan consumer mengenai bentuk data.

Pandangan tersebut tidak salah, tetapi terlalu sempit untuk sistem perusahaan yang semakin saling terhubung.

Contract yang matang setidaknya perlu memberikan konteks mengenai struktur, aturan validasi, ownership, classification, serta policy tertentu terhadap data.

Contohnya, sebuah field dapat diberi penanda bahwa informasi tersebut merupakan PII, data finansial, informasi internal, atau data yang membutuhkan perlindungan khusus.

Dengan begitu, developer tidak hanya mengetahui tipe datanya.

Mereka juga memahami konsekuensi ketika field tersebut diteruskan ke sistem lain.

Perbedaannya cukup mendasar.

Schema menjelaskan seperti apa data tersebut. Security boundary menentukan kepada siapa data tersebut boleh diberikan.

Dua hal ini seharusnya tidak berjalan secara terpisah.

“API Internal” Tidak Berarti Seluruh Data Boleh Dipercaya untuk Berpindah

Salah satu alasan yang sering membuat data dikirim terlalu luas adalah asumsi bahwa integrasi hanya terjadi di lingkungan internal.

Karena Service A dan Service B berada dalam perusahaan yang sama, seluruh objek dianggap aman untuk dipertukarkan.

Pendekatan tersebut semakin sulit dipertahankan.

Lingkungan teknologi perusahaan saat ini dapat terdiri dari microservices, aplikasi internal, cloud workload, SaaS, data platform, API gateway, serta berbagai layanan pihak ketiga.

Sebuah service yang hari ini sepenuhnya internal dapat menjadi sumber data bagi integrasi baru pada masa mendatang.

Prinsip Zero Trust memberikan perspektif yang relevan dalam kondisi tersebut: lokasi jaringan atau kepemilikan sistem tidak seharusnya otomatis menjadi dasar kepercayaan.

Service tetap membutuhkan identitas.

Permintaan tetap membutuhkan authorization.

Data tetap membutuhkan pembatasan.

Dengan demikian, kalimat “ini hanya internal API” seharusnya tidak menjadi alasan untuk mengirim seluruh informasi yang tersedia.

Satu Field yang Tidak Perlu Dapat Menghasilkan Banyak Salinan Baru

Risiko keamanan data antar sistem tidak berhenti ketika API response berhasil diterima consumer.

Data tersebut dapat menjalani perjalanan yang jauh lebih panjang.

Bayangkan alur berikut:

Database → Service A → API → Service B → Cache → Log → Analytics

Sebuah field sensitif yang sebenarnya tidak diperlukan oleh Service B dapat ikut masuk ke cache.

Kemudian data muncul di application logging.

Selanjutnya data dikirim ke sistem analytics.

Mungkin pula data ikut masuk ke backup atau data warehouse.

Akibatnya, keputusan sederhana untuk mengirim seluruh object dapat menciptakan beberapa lokasi penyimpanan baru.

Semakin banyak salinan yang dibuat, semakin besar pula area yang harus dilindungi.

Karena itu, data minimization bukan hanya konsep privasi. Dalam arsitektur API, prinsip tersebut juga merupakan strategi untuk mengurangi attack surface.

Data Minimization Harus Menjadi Bagian dari API Contract

API yang baik tidak harus memberikan seluruh informasi yang dimiliki sistem.

API seharusnya memberikan informasi yang memang dibutuhkan consumer.

Jika sebuah service hanya membutuhkan tiga field untuk menjalankan fungsi bisnis, mengirim dua puluh field bukanlah bentuk fleksibilitas tanpa konsekuensi.

Setiap field tambahan membawa tanggung jawab tambahan.

Data harus diamankan ketika transit.

Aksesnya perlu dikendalikan.

Log yang menyimpan data tersebut juga perlu dilindungi.

Retention perlu dipertimbangkan.

Integrasi lanjutan perlu diawasi.

Dengan menerapkan data minimization pada API, organisasi dapat mengurangi jumlah data yang berpindah tanpa mengurangi fungsi sistem.

Pendekatan tersebut juga mendorong desain API yang lebih jelas. Consumer tidak bergantung pada property yang sebenarnya tidak relevan dengan kebutuhan bisnisnya.

Klasifikasi Data Tidak Boleh Hilang Ketika Masuk JSON

Banyak perusahaan sudah memiliki kebijakan klasifikasi informasi.

Data dapat dikategorikan sebagai public, internal, confidential, restricted, atau kategori lain sesuai kebutuhan organisasi.

Namun klasifikasi tersebut sering melekat pada dokumen, database, atau kebijakan perusahaan.

Ketika informasi keluar melalui API, konteks tersebut dapat hilang.

Contohnya:

"employee_id": "12345"

dan:

"national_identity_number": "..."

bagi schema validator, keduanya mungkin hanya berupa string.

Namun dari sudut keamanan, keduanya memiliki konsekuensi yang sangat berbeda.

Karena itu, data classification dalam API perlu dibawa lebih dekat ke schema dan data contract.

Ketika developer menambahkan sebuah field, mereka seharusnya tidak hanya menentukan tipe datanya.

Perlu pula ditanyakan:

Apakah field ini mengandung data pribadi?

Apakah field ini termasuk data rahasia perusahaan?

Consumer mana yang boleh menerimanya?

Apakah field perlu di-masking?

Apakah field dapat dicatat di log?

Apakah data boleh disimpan oleh downstream system?

Pertanyaan seperti ini membuat data contract berfungsi sebagai bagian dari tata kelola keamanan, bukan sekadar dokumentasi developer.

Schema Validation Tidak Sama dengan Security Validation

Sebuah field dapat sepenuhnya valid menurut schema tetapi tetap tidak aman.

Contohnya:

email: string

salary: number

access_token: string

Ketiganya dapat lolos pemeriksaan tipe data.

Namun keberhasilan tersebut tidak menjelaskan apakah informasi salary boleh diterima oleh aplikasi tertentu atau apakah access token seharusnya ada di response sejak awal.

Inilah salah satu kelemahan apabila perusahaan memperlakukan schema compatibility sebagai jaminan keamanan.

Data yang valid secara struktur belum tentu valid untuk dibagikan.

Karena itu, validation dalam API perlu dilihat dalam beberapa lapisan.

Pertama, apakah formatnya benar?

Kedua, apakah nilainya sesuai aturan bisnis?

Ketiga, apakah consumer memiliki hak untuk menerima field tersebut?

Lapisan ketiga inilah yang sering tidak tercermin dengan jelas dalam data contract tradisional.

Data Contract Juga Perlu Menentukan Apa yang Tidak Boleh Keluar

Sebagian dokumentasi API berfokus pada daftar field yang tersedia.

Namun dari perspektif keamanan, daftar informasi yang tidak boleh dipertukarkan juga sama pentingnya.

Sebagai contoh, contract dapat menetapkan bahwa consumer tertentu tidak pernah boleh menerima:

• password atau password hash;
• access token;
• session identifier;
• secret key;
• internal security notes;
• data identitas tertentu;
• informasi pembayaran mentah.

Pendekatan tersebut mengubah fungsi contract.

Data contract tidak lagi hanya mengatakan:

“Berikut bentuk data yang dapat digunakan.”

Contract juga menetapkan:

“Informasi berikut tidak diperbolehkan melewati boundary ini.”

Batas eksplisit seperti ini sangat membantu ketika jumlah integration point semakin bertambah.

Perubahan Schema Dapat Menjadi Security Regression

Schema evolution biasanya dibahas dalam konteks compatibility.

Apakah perubahan baru masih dapat dibaca consumer lama?

Apakah penambahan field akan merusak integrasi?

Apakah perubahan tipe data membutuhkan version baru?

Namun ada dimensi lain yang perlu diperhatikan.

Misalnya, sebuah objek awalnya hanya memiliki:

customer_id

name

Kemudian versi berikutnya menambahkan:

email

phone

identity_number

Consumer lama mungkin tetap bekerja.

Tidak terjadi error.

Schema tetap backward compatible.

Namun profil risikonya sudah berubah.

Response sekarang membawa data yang jauh lebih sensitif.

Artinya, perubahan yang kompatibel secara teknis belum tentu kompatibel dari sudut keamanan.

Karena itu, penambahan sensitive field seharusnya menjadi salah satu pemicu security review.

Pertanyaan yang perlu diajukan bukan hanya “apakah consumer masih berjalan?”, tetapi juga “apakah consumer lama sekarang menerima informasi yang sebelumnya tidak pernah diberikan?”

Contract Harus Terhubung dengan Kontrol yang Benar-Benar Dijalankan

Data contract yang hanya tersimpan sebagai dokumentasi memiliki nilai terbatas.

Ketentuan di dalam contract perlu diterjemahkan menjadi kontrol teknis.

Implementasinya dapat melibatkan:

• API gateway policy;
• field filtering;
• response transformation;
• data masking;
• Role-Based Access Control;
• Attribute-Based Access Control;
• service identity;
• schema validation;
• consumer allowlist;
• logging policy.

Misalnya, sebuah Finance Service diperbolehkan menerima:

customer_id

invoice_number

payment_status

Namun tidak boleh menerima informasi authentication atau internal notes pelanggan.

Batas tersebut sebaiknya bukan hanya menjadi kesepakatan verbal antara tim.

Jika memungkinkan, policy perlu ditegakkan secara teknis sehingga perubahan aplikasi tidak dengan mudah memperluas data yang diberikan.

Data Contract Harus Menjadi Bagian dari Secure SDLC

Security sering diperiksa ketika aplikasi hampir selesai.

Pada tahap tersebut, banyak keputusan mengenai API dan pertukaran data sudah telanjur dibuat.

Padahal, batas keamanan seharusnya dibicarakan ketika contract pertama kali dirancang.

Security review dapat dilakukan ketika:

• API baru dibuat;
• consumer baru ditambahkan;
• sensitive field diperkenalkan;
• schema mengalami perubahan;
• integrasi pihak ketiga dibuka;
• klasifikasi data berubah;
• service memperoleh akses baru.

Pendekatan seperti ini membuat API security menjadi bagian dari proses pengembangan, bukan pemeriksaan tambahan di akhir proyek.

Data contract kemudian berfungsi sebagai titik pertemuan antara kebutuhan developer, kebutuhan bisnis, dan kebijakan keamanan.

Penetration Testing Perlu Melihat Data yang Keluar, Bukan Hanya Endpoint yang Bisa Diakses

Pengujian keamanan API sering kali berfokus pada authentication, authorization, injection, business logic, rate limiting, serta kemungkinan akses terhadap objek milik pengguna lain.

Semua area tersebut penting.

Namun pengujian juga perlu memperhatikan isi response.

Apakah role ini seharusnya menerima seluruh property tersebut?

Apakah API mengembalikan field internal yang tidak digunakan frontend?

Apakah terdapat hidden attributes?

Apakah user biasa dapat melihat field yang hanya diperlukan administrator?

Apakah response memiliki informasi sensitif yang sebenarnya tidak diperlukan oleh proses bisnis?

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Dalam sejumlah kondisi, endpoint memang sudah memiliki authentication dan authorization. Masalah justru berada pada granularity akses: pengguna sah dapat memanggil API, tetapi response masih memberikan informasi yang terlalu luas.

Pengujian seperti ini membantu organisasi membandingkan intended data contract dengan perilaku sistem yang benar-benar berjalan di production.

API yang Aman Tidak Cukup Hanya Memiliki Schema yang Rapi

Ketika integration landscape masih kecil, contract yang hanya mengatur struktur mungkin terasa cukup.

Namun ketika aplikasi mulai terhubung dengan banyak service, cloud platform, vendor, dan sistem internal, setiap pertukaran data menciptakan trust boundary baru.

Karena itu, organisasi perlu mengajukan pertanyaan yang lebih jauh.

Apakah setiap consumer benar-benar membutuhkan seluruh field yang diberikan?

Apakah sensitive data sudah diklasifikasikan?

Apakah authorization bekerja hingga tingkat property?

Apakah penambahan field baru memerlukan security review?

Apakah internal service otomatis dianggap dapat dipercaya?

Apakah contract menentukan informasi yang dilarang keluar?

Dan yang paling penting, apakah aturan tersebut benar-benar diterapkan oleh aplikasi?

Data contract yang matang bukan hanya membuat dua sistem memahami format yang sama. Data contract juga memastikan keduanya memahami batas keamanan yang sama.

Dalam arsitektur API modern, kegagalan tidak selalu terjadi ketika format data salah.

Risiko justru dapat muncul ketika data dikirim dengan format yang sepenuhnya benar kepada aplikasi yang seharusnya tidak pernah menerima informasi tersebut.

Perkuat Keamanan API dan Integrasi Sistem Bersama Fourtrezz

Ketika API menjadi penghubung berbagai sistem bisnis, keamanan perlu diperhatikan sejak tahap arsitektur, pengembangan, hingga pengujian.

Fourtrezz menyediakan layanan Penetration Testing untuk Web Application, API, Android, iOS, Desktop Application, serta jaringan dan server. Pengujian tersedia melalui pendekatan Greybox maupun Blackbox untuk membantu perusahaan menemukan kerentanan dan mengevaluasi keamanan sistem dari perspektif serangan yang relevan.

Bagi perusahaan yang sedang membangun atau memodernisasi sistem, Fourtrezz juga menyediakan layanan IT Development, meliputi Custom Enterprise Solution, System & API Integration, Legacy System Transformation, dan IT Architecture Design.

Kombinasi pengembangan sistem dan pengujian keamanan dapat membantu perusahaan memastikan integrasi tidak hanya berjalan secara fungsional, tetapi juga memiliki batas akses dan perlindungan data yang sesuai dengan kebutuhan bisnis.

Hubungi Fourtrezz:
Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]