Bagikan melalui

Rekomendasi untuk mengurangi ancaman 10 Teratas Keamanan API OWASP menggunakan API Management

  • Artikel

BERLAKU UNTUK: Semua tingkatAN API Management

Catatan

Artikel ini telah diperbarui untuk mencerminkan daftar OWASP API Security Top 10 terbaru untuk 2023.

Open Web Application Security Project (OWASP) Foundation bekerja untuk meningkatkan keamanan perangkat lunak melalui proyek perangkat lunak sumber terbuka yang dipimpin komunitas, ratusan bab di seluruh dunia, puluhan ribu anggota, dan dengan menyelenggarakan konferensi lokal dan global.

Proyek Keamanan API OWASP berfokus pada strategi dan solusi untuk memahami dan mengurangi kerentanan dan risiko keamanan API yang unik. Dalam artikel ini, kami membahas rekomendasi terbaru untuk mengurangi 10 ancaman API teratas yang diidentifikasi oleh OWASP dalam daftar 2023 mereka menggunakan Azure API Management.

Meskipun API Management menyediakan kontrol komprehensif untuk keamanan API, layanan Microsoft lain menyediakan fungsionalitas pelengkap untuk mendeteksi atau melindungi dari ancaman OWASP API:

Otorisasi tingkat objek rusak

Objek API yang tidak dilindungi dengan tingkat otorisasi yang sesuai mungkin rentan terhadap kebocoran data dan manipulasi data yang tidak sah melalui pengidentifikasi akses objek yang lemah. Misalnya, penyerang dapat mengeksploitasi pengidentifikasi objek bilangan bulat, yang dapat diulang.

Informasi selengkapnya tentang ancaman ini: Otorisasi Tingkat Objek Rusak API1:2023

Rekomendasi

  • Tempat terbaik untuk menerapkan otorisasi tingkat objek adalah dalam API backend itu sendiri. Di backend, keputusan otorisasi yang tepat dapat dibuat pada tingkat permintaan (atau objek), jika berlaku, menggunakan logika yang berlaku untuk domain dan API. Pertimbangkan skenario saat permintaan tertentu dapat menghasilkan tingkat detail yang berbeda dalam respons, tergantung izin dan otorisasi pemohon.

  • Jika API yang rentan saat ini tidak dapat diubah di backend, maka API Management dapat digunakan sebagai fallback. Contohnya:

    • Gunakan kebijakan kustom untuk menerapkan otorisasi tingkat objek, jika tidak diterapkan di backend.

    • Terapkan kebijakan kustom untuk memetakan pengidentifikasi dari permintaan ke backend dan dari backend ke klien, sehingga pengidentifikasi internal tidak terekspos.

      Dalam kasus ini, kebijakan kustom bisa menjadi ekspresi kebijakan dengan pencarian (misalnya, kamus) atau integrasi dengan layanan lain melalui kebijakan kirim permintaan .

  • Untuk skenario GraphQL, terapkan otorisasi tingkat objek melalui kebijakan validate-graphql-request , menggunakan authorize elemen .

Autentikasi rusak

Mekanisme autentikasi untuk situs atau API sangat rentan karena terbuka untuk pengguna anonim. Aset dan titik akhir yang diperlukan untuk autentikasi, termasuk kata sandi yang terlupakan atau atur ulang alur kata sandi, harus dilindungi untuk mencegah eksploitasi.

Informasi selengkapnya tentang ancaman ini: Autentikasi RUSAK API2:2023

Rekomendasi

  • Gunakan Microsoft Entra untuk menerapkan autentikasi API. Microsoft Entra secara otomatis menyediakan titik akhir masuk yang dilindungi, tangguh, dan didistribusikan secara geografis. Gunakan kebijakan validate-azure-ad-token untuk memvalidasi token Microsoft Entra dalam permintaan API masuk.
  • Jika autentikasi diperlukan, API Management mendukung validasi token OAuth 2, autentikasi dasar, sertifikat klien, dan kunci API.
    • Pastikan konfigurasi metode autentikasi yang tepat. Misalnya, atur require-expiration-time dan require-signed-tokens ke true saat memvalidasi token OAuth2 menggunakan kebijakan validasi-jwt .
  • Pembatasan laju dapat digunakan untuk mengurangi efektivitas serangan brute force.
  • Pemfilteran IP klien dapat digunakan untuk mengurangi area permukaan serangan. Kelompok keamanan jaringan dapat diterapkan ke jaringan virtual yang terintegrasi dengan API Management.
  • Jika memungkinkan, autentikasi ke backend dari API Management melalui protokol aman dan identitas terkelola atau manajer kredensial untuk mengautentikasi ke backend.
  • Pastikan token atau kunci diteruskan di header dan bukan URL untuk permintaan masuk ke API Management dan permintaan keluar ke backend.
  • Gunakan Microsoft Entra untuk mengamankan akses ke portal pengembang API Management.

Otorisasi tingkat properti objek rusak

Desain antarmuka API yang bagus sangat menantang. Seringkali, terutama dengan API warisan yang telah berevolusi dari waktu ke waktu, antarmuka permintaan dan respons berisi lebih banyak bidang data daripada yang dibutuhkan aplikasi yang menggunakan, memungkinkan serangan injeksi data. Penyerang juga dapat menemukan antarmuka yang tidak terdokumentasi. Kerentanan ini dapat menghasilkan data sensitif kepada penyerang.

Informasi selengkapnya tentang ancaman ini: Otorisasi Tingkat Properti Objek Rusak API3:2023

Rekomendasi

  • Pendekatan terbaik untuk mengurangi kerentanan ini adalah memastikan antarmuka eksternal yang ditentukan di API backend dirancang dengan hati-hati dan, idealnya, secara independen dari persistensi data. Antarmuka tersebut hanya boleh berisi bidang yang diperlukan oleh konsumen API. API harus sering ditinjau, dan bidang lama tidak digunakan lagi, lalu dihapus.
  • Di API Management, gunakan revisi untuk mengontrol perubahan yang tidak melanggar dengan baik, misalnya, penambahan bidang ke antarmuka, dan versi untuk menerapkan perubahan yang melanggar. Anda juga harus membuat versi antarmuka backend, yang biasanya memiliki siklus hidup yang berbeda dari API yang menghadap konsumen.
  • Memisahkan antarmuka API eksternal dari implementasi data internal. Hindari mengikat kontrak API langsung ke kontrak data di layanan backend.
  • Jika tidak dapat mengubah desain antarmuka backend dan data yang berlebihan menjadi perhatian, gunakan kebijakan transformasi API Management untuk menulis ulang payload respons dan menutupi atau memfilter data. Validasi konten dalam API Management dapat digunakan dengan skema XML atau JSON untuk memblokir respons dengan properti yang tidak terdokumentasi atau nilai yang tidak tepat. Misalnya, hapus properti JSON yang tidak diperlukan dari isi respons. Memblokir permintaan dengan properti yang tidak terdokumentasi mengurangi serangan, sementara memblokir respons dengan properti yang tidak terdokumentasi membuatnya lebih sulit merekayasa ulang vektor serangan potensial. Kebijakan validasi konten juga mendukung respons pemblokiran yang melebihi ukuran tertentu.
  • Gunakan kebijakan validasi-status-code untuk memblokir respons dengan kesalahan yang tidak ditentukan dalam skema API.
  • Gunakan kebijakan validasi-header untuk memblokir respons dengan header yang tidak ditentukan dalam skema atau tidak mematuhi definisinya dalam skema. Hapus header yang tidak diinginkan dengan kebijakan set-header .
  • Untuk skenario GraphQL, gunakan kebijakan validate-graphql-request untuk memvalidasi permintaan GraphQL, mengotorisasi akses ke jalur kueri tertentu, dan membatasi ukuran respons.

Konsumsi sumber daya tidak terbatas

API memerlukan sumber daya untuk dijalankan, seperti memori atau CPU, dan dapat mencakup integrasi hilir yang mewakili biaya operasi (misalnya, layanan bayar per permintaan). Menerapkan batas dapat membantu melindungi API dari konsumsi sumber daya yang berlebihan.

Informasi selengkapnya tentang ancaman ini: API4:2023 Konsumsi Sumber Daya Tidak Terbatas

Rekomendasi

  • Gunakan kebijakan batas demi kunci tarif atau batas tarif untuk menerapkan pembatasan pada jendela waktu yang lebih singkat. Terapkan kebijakan pembatasan laju yang lebih ketat pada titik akhir sensitif, seperti reset kata sandi, operasi masuk, atau pendaftaran, atau titik akhir yang menggunakan sumber daya yang signifikan.
  • Gunakan kebijakan kuota demi kunci atau batas kuota untuk mengontrol jumlah panggilan API atau bandwidth yang diizinkan untuk jangka waktu yang lebih lama.
  • Optimalkan performa dengan caching bawaan, sehingga mengurangi penggunaan sumber daya CPU, memori, dan jaringan untuk operasi tertentu.
  • Menerapkan kebijakan validasi.
  • Untuk API AI generatif:
    • Gunakan penembolokan semantik untuk mengurangi beban pada backend.
    • Gunakan pembatasan token untuk mengontrol konsumsi dan biaya.
    • Keluarkan metrik konsumsi token untuk memantau pemanfaatan token dan mengonfigurasi pemberitahuan.
  • Kurangi waktu yang dibutuhkan layanan backend untuk merespons. Semakin lama layanan backend merespons, semakin lama koneksi ditempati dalam API Management, sehingga mengurangi jumlah permintaan yang dapat dilayani dalam jangka waktu tertentu.
  • Terapkan kebijakan CORS untuk mengontrol situs web yang diizinkan untuk memuat sumber daya yang dilayani melalui API. Untuk menghindari konfigurasi yang terlalu permisif, jangan gunakan nilai kartubebas (*) dalam kebijakan CORS.
  • Meskipun Azure memiliki perlindungan tingkat platform dan perlindungan yang ditingkatkan terhadap serangan penolakan layanan terdistribusi (DDoS), perlindungan aplikasi (lapisan 7) untuk API dapat ditingkatkan dengan menyebarkan layanan perlindungan bot di depan API Management - misalnya, Azure Application Gateway, Azure Front Door, atau Azure DDoS Protection. Saat menggunakan kebijakan firewall aplikasi web (WAF) dengan Azure Application Gateway atau Azure Front Door, pertimbangkan untuk menggunakan Microsoft_BotManagerRuleSet_1.0.

Otorisasi tingkat fungsi rusak

Kebijakan kontrol akses yang kompleks dengan hierarki, grup, dan peran yang berbeda, dan pemisahan yang tidak jelas antara fungsi administratif dan reguler, menyebabkan kelemahan otorisasi. Dengan mengeksploitasi masalah ini, penyerang mendapatkan akses ke sumber daya pengguna lain atau fungsi administratif.

Informasi selengkapnya tentang ancaman ini: Otorisasi tingkat fungsi API5:2023 Rusak

Rekomendasi

  • Secara default, lindungi semua titik akhir API di API Management dengan kunci langganan atau kebijakan otorisasi tingkat all-API. Jika berlaku, tentukan kebijakan otorisasi lain untuk API atau operasi API tertentu.
  • Validasi token OAuth menggunakan kebijakan.
    • Gunakan kebijakan validate-azure-ad-token untuk memvalidasi token Microsoft Entra. Tentukan semua klaim yang diperlukan dan, jika berlaku, tentukan aplikasi yang diotorisasi.
    • Untuk memvalidasi token yang tidak dikeluarkan oleh Microsoft Entra, tentukan kebijakan validasi-jwt dan terapkan klaim token yang diperlukan. Jika memungkinkan, perlu waktu kedaluwarsa.
    • Jika memungkinkan, gunakan token terenkripsi atau daftar aplikasi tertentu untuk akses.
    • Memantau dan meninjau permintaan yang ditolak karena kurangnya otorisasi.
  • Gunakan jaringan virtual Azure atau Private Link untuk menyembunyikan titik akhir API dari internet. Pelajari selengkapnya tentang opsi jaringan virtual dengan API Management.
  • Jangan tentukan operasi API wildcard (yaitu, API "catch-all" dengan *  sebagai jalur). Pastikan bahwa API Management hanya melayani permintaan untuk titik akhir yang ditentukan secara eksplisit, dan permintaan ke titik akhir yang tidak ditentukan ditolak.
  • Jangan terbitkan API dengan produk terbuka yang tidak memerlukan langganan.
  • Jika IP klien diketahui, gunakan kebijakan filter ip untuk mengizinkan lalu lintas hanya dari alamat IP resmi.
  • Gunakan kebijakan validate-client-certificate untuk memberlakukan bahwa sertifikat yang disajikan oleh klien ke instans API Management cocok dengan aturan dan klaim validasi yang ditentukan.

Akses tidak terbatas ke alur bisnis sensitif

API dapat mengekspos berbagai fungsionalitas ke aplikasi yang mengonsumsi. Penting bagi penulis API untuk memahami alur bisnis yang disediakan API dan sensitivitas terkait. Ada risiko yang lebih besar bagi bisnis jika API yang mengekspos alur sensitif tidak menerapkan perlindungan yang sesuai.

Informasi selengkapnya tentang ancaman ini: API6:2023 Akses Tidak Terbatas ke Alur Bisnis Sensitif

Rekomendasi

  • Kurangi atau blokir akses berdasarkan sidik jari klien. Misalnya, gunakan kebijakan respons kembali dengan kebijakan pilih untuk memblokir lalu lintas dari browser headless berdasarkan header User-Agent atau konsistensi header lain.
  • Gunakan kebijakan validasi-parameter untuk memberlakukan header permintaan tersebut sesuai dengan spesifikasi API.
  • Gunakan kebijakan ip-filter untuk mengizinkan permintaan hanya dari alamat IP yang diketahui atau menolak akses dari IP tertentu.
  • Gunakan fitur jaringan privat untuk membatasi konektivitas eksternal ke API internal.
  • Gunakan kebijakan batas demi kunci tarif untuk membatasi lonjakan konsumsi API berdasarkan identitas pengguna, alamat IP, atau nilai lain.
  • Front API Management dengan Azure Application Gateway atau layanan Azure DDoS Protection untuk mendeteksi dan memblokir lalu lintas bot.

Pemalsuan permintaan sisi server

Kerentanan pemalsuan permintaan sisi server dapat terjadi ketika API mengambil sumber daya hilir berdasarkan nilai URL yang telah diteruskan oleh pemanggil API tanpa pemeriksaan validasi yang sesuai.

Informasi selengkapnya tentang ancaman ini: Pemalsuan Permintaan Sisi Server API7:2023

Rekomendasi

  • Jika memungkinkan, jangan gunakan URL yang disediakan dalam payload klien, misalnya, sebagai parameter untuk URL backend, kebijakan kirim permintaan , atau kebijakan rewrite-url .
  • Jika API Management atau layanan backend menggunakan URL yang disediakan dalam payload permintaan untuk logika bisnis, tentukan dan terpaksa daftar terbatas nama host, port, jenis media, atau atribut lain dengan kebijakan di API Management, seperti kebijakan pilihan dan ekspresi kebijakan.
  • Tentukan timeout atribut dalam kebijakan permintaan terusan dan permintaan kirim.
  • Memvalidasi dan membersihkan data permintaan dan respons dengan kebijakan validasi. Jika diperlukan, gunakan kebijakan set-body untuk memproses respons dan menghindari pengembalian data mentah.
  • Gunakan jaringan privat untuk membatasi konektivitas. Misalnya, jika API tidak perlu publik, batasi konektivitas dari internet untuk mengurangi permukaan serangan.

Kesalahan konfigurasi keamanan

Penyerang dapat mencoba mengeksploitasi kerentanan kesalahan konfigurasi keamanan seperti:

  • Pengerasan keamanan tidak ada
  • Fitur yang tidak perlu diaktifkan
  • Koneksi jaringan tidak perlu terbuka ke internet
  • Penggunaan protokol atau cipher yang lemah

Informasi selengkapnya tentang ancaman ini: Kesalahan konfigurasi keamanan API8:2023

Rekomendasi

  • Konfigurasikan gateway TLS dengan benar. Jangan gunakan protokol yang rentan (misalnya, TLS 1.0, 1.1) atau cipher.
  • Konfigurasikan API untuk menerima lalu lintas terenkripsi saja, misalnya melalui protokol HTTPS atau WSS. Anda dapat mengaudit dan menerapkan pengaturan ini menggunakan Azure Policy.
  • Pertimbangkan untuk menyebarkan API Management di belakang titik akhir privat atau dilampirkan ke jaringan virtual yang disebarkan dalam mode internal. Di jaringan internal, akses dapat dikontrol dari dalam jaringan privat (melalui firewall atau kelompok keamanan jaringan) dan dari internet (melalui proksi terbalik).
  • Gunakan kebijakan Azure API Management:
    • Selalu warisi kebijakan induk melalui tag <base>.
    • Saat menggunakan OAuth 2.0, konfigurasikan dan uji kebijakan validasi-jwt untuk memeriksa keberadaan dan validitas token sebelum mencapai backend. Periksa secara otomatis waktu kedaluwarsa token, tanda tangan token, dan pengeluar sertifikat. Terapkan klaim, audiens, kedaluwarsa token, dan tanda tangan token melalui pengaturan kebijakan. Jika Anda menggunakan Microsoft Entra, kebijakan validate-azure-ad-token menyediakan cara yang lebih komprehensif dan lebih mudah untuk memvalidasi token keamanan.
    • Konfigurasikan kebijakan CORS dan jangan gunakan wildcard * untuk opsi konfigurasi apa pun. Sebaliknya, secara eksplisit cantumkan nilai yang diizinkan.
    • Atur kebijakan validasi di lingkungan produksi untuk memvalidasi skema JSON dan XML, header, parameter kueri, dan kode status, dan untuk menerapkan ukuran maksimum untuk permintaan atau respons.
    • Jika API Management berada di luar batas jaringan, validasi IP klien tetap dapat menggunakan kebijakan batasi IP penelepon. Pastikan bahwa ia menggunakan daftar yang diizinkan, bukan daftar blokir.
    • Jika sertifikat klien digunakan antara pemanggil dan API Management, gunakan kebijakan validate-client-certificate . Pastikan atribut validate-revocation, validate-trust, validate-not-before, dan validate-not-after semuanya diatur ke true.
  • Sertifikat klien (TLS bersama) juga dapat diterapkan antara API Management dan backend. Backend harus:
    • Mengonfigurasi informasi masuk otorisasi
    • Memvalidasi rantai sertifikat jika berlaku
    • Memvalidasi nama sertifikat jika berlaku
    • Untuk skenario GraphQL, gunakan kebijakan validate-graphQL-request . Pastikan elemen authorization dan atribut max-sizemax-depth diatur.
  • Jangan menyimpan rahasia dalam file kebijakan atau di kontrol sumber. Selalu gunakan nilai bernama API Management atau ambil rahasia saat runtime menggunakan ekspresi kebijakan kustom. Nilai bernama harus diintegrasikan dengan Azure Key Vault atau dienkripsi dalam API Management dengan menandainya "rahasia". Jangan pernah menyimpan rahasia dalam nilai bernama teks biasa.
  • Terbitkan API melalui produk, yang memerlukan langganan. Jangan gunakan produk terbuka yang tidak memerlukan langganan.
  • Pastikan API Anda memerlukan kunci langganan, meskipun semua produk dikonfigurasi untuk memerlukan kunci langganan. Pelajari lebih lanjut
  • Memerlukan persetujuan langganan untuk semua produk dan tinjau semua permintaan langganan dengan cermat.
  • Gunakan integrasi Key Vault untuk mengelola semua sertifikat. Ini mempusatkan manajemen sertifikat dan dapat membantu memudahkan tugas manajemen operasi seperti perpanjangan atau pencabutan sertifikat. Gunakan identitas terkelola untuk mengautentikasi ke brankas kunci.
  • Saat menggunakan gateway yang di-hosting sendiri, pastikan ada proses untuk memperbarui gambar ke versi terbaru secara berkala.
  • Mewakili layanan backend sebagai entitas backend. Konfigurasikan informasi masuk otorisasi, validasi rantai sertifikat, dan validasi nama sertifikat jika berlaku.
  • Jika memungkinkan, gunakan manajer kredensial atau identitas terkelola untuk mengautentikasi terhadap layanan backend.
  • Saat menggunakan portal pengembang:
    • Jika Anda memilih untuk meng-hosting sendiri portal pengembang, pastikan ada proses untuk memperbarui portal yang di-hosting sendiri secara berkala ke versi terbaru. Pembaruan untuk versi terkelola default bersifat otomatis.
    • Gunakan ID Microsoft Entra atau Azure Active Directory B2C untuk pendaftaran dan masuk pengguna. Nonaktifkan autentikasi nama pengguna dan kata sandi default, yang kurang aman.
    • Tetapkan grup pengguna ke produk, untuk mengontrol visibilitas API di portal.
  • Gunakan Azure Policy untuk menerapkan konfigurasi tingkat sumber daya API Management dan izin kontrol akses berbasis peran (RBAC) untuk mengontrol akses sumber daya. Berikan hak istimewa minimum yang diperlukan untuk setiap pengguna.
  • Gunakan proses DevOps dan pendekatan infrastruktur sebagai kode di luar lingkungan pengembangan untuk memastikan konsistensi konten API Management dan perubahan konfigurasi dan untuk meminimalkan kesalahan manusia.
  • Jangan gunakan fitur yang tidak digunakan lagi.

Manajemen inventori yang tidak tepat

Kerentanan terkait manajemen aset yang tidak tepat meliputi:

  • Kurangnya dokumentasi API atau informasi kepemilikan yang tepat
  • Jumlah versi API yang lebih lama yang berlebihan, yang mungkin tidak memiliki perbaikan keamanan

Informasi selengkapnya tentang ancaman ini: API9:2023 Manajemen inventori yang tidak tepat

Rekomendasi

  • Gunakan spesifikasi OpenAPI yang ditentukan dengan baik sebagai sumber untuk mengimpor REST API. Spesifikasi ini memungkinkan enkapkulasi definisi API, termasuk metadata yang mendokumentasikan sendiri.
  • Gunakan antarmuka API dengan jalur yang tepat, skema data, header, parameter kueri, dan kode status. Hindari operasi wildcard. Berikan deskripsi untuk setiap API dan operasi serta sertakan informasi kontak dan lisensi.
  • Hindari titik akhir yang tidak secara langsung berkontribusi pada tujuan bisnis. Titik akhir ini tidak perlu meningkatkan area permukaan serangan dan membuatnya lebih sulit mengembangkan API.
  • Gunakan revisi dan versi di API Management untuk mengelola perubahan API. Memiliki strategi penerapan versi backend yang kuat dan berkomitmen untuk jumlah maksimum versi API yang didukung (misalnya, 2 atau 3 versi sebelumnya). Rencanakan untuk menghentikan dengan cepat dan pada akhirnya menghapus versi API yang lama, sering kali kurang aman. Pastikan kontrol keamanan diterapkan di semua versi API yang tersedia.
  • Lingkungan terpisah (seperti pengembangan, pengujian, dan produksi) dengan layanan API Management yang berbeda. Pastikan bahwa setiap layanan API Management terhubung ke dependensinya di lingkungan yang sama. Misalnya, di lingkungan pengujian, sumber daya API Management pengujian harus terhubung ke sumber daya Azure Key Vault pengujian dan versi pengujian layanan backend. Gunakan otomatisasi DevOps dan praktik infrastruktur sebagai kode untuk membantu menjaga konsistensi dan akurasi antara lingkungan dan mengurangi kesalahan manusia.
  • Mengisolasi izin administratif ke API dan sumber daya terkait menggunakan ruang kerja.
  • Gunakan tag untuk mengatur API dan produk lalu mengelompokkannya untuk penerbitan.
  • Terbitkan API untuk dikonsumsi melalui portal pengembang. Pastikan dokumentasi API sudah diperbarui.
  • Temukan API yang tidak terdokumentasi atau tidak terkelola dan ekspos melalui API Management untuk kontrol yang lebih baik.
  • Gunakan Azure API Center untuk mempertahankan inventarisasi API, versi, dan penyebaran terpusat yang komprehensif, meskipun API tidak dikelola di Azure API Management.

Konsumsi API yang tidak aman

Sumber daya yang diperoleh melalui integrasi hilir cenderung lebih dipercaya daripada input API dari pemanggil atau pengguna akhir. Jika standar sanitasi dan keamanan yang sesuai tidak diterapkan, API bisa rentan, bahkan jika integrasi disediakan melalui layanan tepercaya.

Informasi selengkapnya tentang ancaman ini: API10:2023 Konsumsi API Tidak Aman

Rekomendasi

  • Pertimbangkan untuk menggunakan API Management untuk bertindak sebagai fasad untuk dependensi hilir yang diintegrasikan dengan API backend.
  • Jika dependensi hilir dihadapkan dengan API Management atau jika dependensi hilir digunakan dengan kebijakan permintaan kirim di API Management, gunakan rekomendasi dari bagian lain dari dokumentasi ini untuk memastikan konsumsinya yang aman dan terkontrol, termasuk:
    • Pastikan transportasi aman diaktifkan dan menerapkan konfigurasi TLS/SSL
    • Jika memungkinkan, autentikasi dengan manajer kredensial atau identitas terkelola
    • Mengontrol konsumsi dengan kebijakan rate-limit-by-key dan quota-limit-by-key
    • Mencatat atau memblokir respons yang sesuai dengan spesifikasi API menggunakan kebijakan validasi-konten dan validasi-header
    • Mengubah respons dengan kebijakan set-body, misalnya untuk menghapus informasi yang tidak perlu atau sensitif
    • Mengonfigurasi batas waktu dan membatasi konkurensi

Konten terkait

Pelajari lebih lanjut tentang: