262-000177-001 OWASP 10 Teratas Untuk Keamanan API
“
Informasi Produk
Spesifikasi
- Nama Produk: Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk API
Keamanan - Isi: Lembar contekan keamanan API, Definisi, dan detail
panduan untuk OWASP Top 2023 tahun 10 untuk Keamanan API
Petunjuk Penggunaan Produk
Pengantar Keamanan API
Panduan Pengembang menyediakan informasi lengkap tentang
OWASP Top 2023 10 untuk Keamanan API, menyoroti keamanan umum
risiko saat mengembangkan aplikasi dengan API.
Lembar contekan keamanan API
Lembar contekan mencantumkan kategori keamanan API berikut ini
Risiko:
- Otorisasi Tingkat Objek Rusak
- Otentikasi Rusak
- Otorisasi Tingkat Properti Objek Rusak
- Konsumsi Sumber Daya Tanpa Batas
- Otorisasi Tingkat Fungsi Rusak
- Akses Tanpa Batas ke Arus Bisnis yang Sensitif
- Pemalsuan Permintaan Sisi Server
- Kesalahan Konfigurasi Keamanan
- Manajemen Inventaris yang Tidak Tepat
- Konsumsi API yang Tidak Aman
Panduan Pengembang Selesaiview
Panduan ini membahas setiap kategori risiko keamanan API, menyediakan
penjelasan dan panduan terperinci tentang cara mengatasi dan mengurangi
risiko ini secara efektif.
Pertanyaan yang Sering Diajukan (FAQ)
T: Mengapa keamanan API penting?
A: Keamanan API sangat penting karena API sering kali mengekspos data sensitif
dan logika aplikasi, menjadikannya target utama penyerang.
Mengamankan API sangat penting untuk mencegah pelanggaran data dan
memastikan keamanan sistem secara keseluruhan.
T: Bagaimana cara menerapkan API yang aman?
A: Untuk menerapkan API yang aman, ikuti praktik terbaik seperti
otentikasi yang tepat, mekanisme otorisasi, validasi input,
enkripsi data sensitif, dan penilaian keamanan rutin dan
pembaruan.
“
LAPORAN RESMI
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
Isi
Lembar contekan keamanan API
5
Definisi
5
API1:2023–Otorisasi Tingkat Objek Rusak
7
API2:2023–Autentikasi Rusak
8
API3:2023–Otorisasi Tingkat Properti Objek Rusak
9
API4:2023–Konsumsi Sumber Daya Tak Terbatas
11
API5:2023–Otorisasi Tingkat Fungsi Rusak
13
API6:2023–Akses Tanpa Batas ke Aliran Bisnis Sensitif
14
API7:2023–Pemalsuan Permintaan Sisi Server
16
API8:2023–Kesalahan Konfigurasi Keamanan
18
API9:2023–Manajemen Inventaris yang Tidak Tepat
19
API10:2023–Konsumsi API yang Tidak Aman
21
10 Keamanan API Teratas tidak cukup!
23
Kesimpulan
23
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
2/23
Seiring dengan semakin banyaknya perusahaan yang mengadopsi infrastruktur berbasis cloud dan metodologi bergaya DevOp, web antarmuka pemrograman aplikasi, atau API, telah berkembang pesat. Beberapa API publik yang paling populer mencakup API yang memungkinkan pengembang mengakses Google Search, mengambil data dari TikTok, melacak kendaraan, mengumpulkan skor olahraga, dan mengumpulkan data tentang unduhan gambar dari situs populer.1 Pada tahun 2023, lalu lintas terkait API mencakup 58 persen dari semua lalu lintas dinamis yang didefinisikan sebagai tidak dapat di-cache, naik dari 54 persen pada akhir tahun 2021.2
API telah menjadi cara bagi aplikasi perusahaan untuk berkomunikasi dan berintegrasi satu sama lain. Perusahaan menggunakan sekitar dua pertiga API mereka (64%) untuk menghubungkan aplikasi mereka ke mitra, sementara sekitar setengahnya (51%) merupakan titik akses ke layanan mikro. Secara keseluruhan, lebih dari tiga perempat perusahaan menggunakan rata-rata sedikitnya 25 API per aplikasi.3
Penerapan infrastruktur aplikasi berbasis API seharusnya tidak mengejutkan: Perusahaan yang menerapkan API untuk menarik pengembang pihak ketiga dan menciptakan ekosistem mengalami peningkatan pertumbuhan. "Perusahaan terbalik" ini—disebut demikian karena mereka membalik konsep tradisional tentang menciptakan hambatan di sekitar teknologi dan memungkinkan akses terbuka ke beberapa kapabilitas dan data—tumbuh hampir 13 persen selama dua tahun, dan 39 persen selama 16 tahun, dibandingkan dengan perusahaan yang tidak menerapkan API, menurut sebuah makalah tahun 2022 oleh para peneliti di Chapman University dan Boston University.4
Namun, dengan diadopsinya layanan mikro, kontainerisasi, dan API, muncul berbagai risiko, seperti komponen perangkat lunak yang tidak aman, logika bisnis yang buruk, dan keamanan data yang cacat. Sembilan dari sepuluh organisasi (92%) telah mengalami setidaknya satu insiden keamanan yang terkait dengan API yang tidak aman.5 Perusahaan besar biasanya memiliki ribuan API dan serangan terhadap sistem tersebut menyumbang sekitar 20 persen dari insiden keamanan, sementara perusahaan yang lebih kecil memiliki ratusan API yang permukaan serangannya yang lebih kecil menyumbang lima persen dari insiden keamanan.6 Kerugian tahunan akibat pelanggaran yang disebabkan oleh kerentanan API melebihi $40 miliar secara global, menurut perkiraan oleh Marsh McLennan.7
1 Arellano, Kelly. 50 API Paling Populer. Blog RapidAPI. RapidAPI. Web Halaman. 16 Maret 2023.
2 Tremante, Michael, dkk. Laporan Keamanan Aplikasi: Q2 2023. Blog Cloudflare. Cloudflare. Entri blog. 21 Agustus 2023.
3 Marks, Melinda. Mengamankan Permukaan Serangan API. Enterprise Strategy Group. Disponsori oleh Palo Alto Networks. Laporan PDF, hlm. 10. 23 Mei 2023.
4 Benzell, Seth G., dkk. Bagaimana API Menciptakan Pertumbuhan dengan Membalikkan Perusahaan. Jaringan Penelitian Ilmu Sosial. Makalah Penelitian. Direvisi: 30 Desember 2022.
5 Mengamankan Permukaan Serangan API. Enterprise Strategy Group, hlm. 14. 6 Lemos, Robert. Kerugian Keamanan API Totalnya Miliaran, Namun Rumit. Dark Reading.
Artikel Berita. 30 Juni 2022. 7 Marsh McLennan. Mengukur Biaya Ketidakamanan API. Disponsori oleh Imperva.
Laporan PDF. 22 Juni 2022.
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
3/23
Daftar 2023 Teratas Keamanan API 10 menyoroti sepuluh risiko keamanan paling umum dan serius yang muncul saat mengembangkan aplikasi yang mengekspos atau menggunakan API.
Masalah ini sangat serius sehingga Badan Keamanan Nasional AS bekerja sama dengan Pusat Keamanan Siber Australia (ACSC) dan Badan Keamanan Siber dan Infrastruktur AS (CISA) untuk menawarkan panduan mengenai masalah keamanan API, terutama yang paling umum, yang dikenal sebagai kerentanan referensi objek langsung (IDOR) yang tidak aman.8
Tidak mengherankan, dengan latar belakang masalah keamanan yang berkembang pesat ini, Open Worldwide Application Security Project (OWASP) merilis pembaruan untuk daftar API Security Top-10. Menyegarkan daftar perdana tahun 2019, daftar API Security Top-2023 tahun 10 menyoroti sepuluh risiko keamanan paling umum dan serius yang muncul saat mengembangkan aplikasi yang mengekspos atau menggunakan API. Masalah seperti Broken Object-Level Authorization, superset yang mencakup kerentanan IDOR, tetap sama dari daftar sebelumnya. Namun, kategori baru–atau kategori yang ditata ulang–sekarang menyoroti masalah yang diabaikan di masa lalu, seperti Server-Side Request Forgery (API7:2023) dan Unrestricted Access to Sensitive Business Flows (API6:2023).
“By nature, APIs expose application logic and sensitive data such as Personally Identifiable Information (PII) and because of this, APIs have increasingly become a target for attackers,” the OWASP group stated in its announcement.9 “Without secure APIs, rapid innovation would be impossible.”
8 Peringatan Keamanan Siber Baru Tentang Web Kerentanan Aplikasi. Badan Keamanan Nasional. Siaran Pers. 27 Juli 2023.
9. Proyek Keamanan Aplikasi Terbuka Seluruh Dunia. 10 Keamanan API OWASP Teratas: Teruskan. OWASP.org. Web Halaman. 3 Juli 2023.
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
4/23
Lembar contekan keamanan API
Kategori OWASP Top 10 1. Otorisasi Tingkat Objek yang Rusak 2. Autentikasi Rusak 3. Otorisasi Tingkat Properti Objek yang Rusak 4. Konsumsi Sumber Daya yang Tidak Terbatas 5. Otorisasi Tingkat Fungsi yang Rusak 6. Akses Tidak Terbatas ke Aliran Bisnis yang Sensitif 7. Pemalsuan Permintaan Sisi Server 8. Kesalahan Konfigurasi Keamanan 9. Manajemen Inventaris yang Tidak Tepat 10. Konsumsi API yang Tidak Aman
Solusi keamanan siber SAST SAST, DAST SAST, DAST SAST, DAST, Manajer API Aman SAST DAST DAST SAST, DAST Manajer API Aman SCA, SAST
Definisi
Titik Akhir API–Titik komunikasi antara dua sistem, biasanya URL dari kontainer atau server yang menjalankan layanan mikro. Menggunakan URL, aplikasi atau pengembang dapat meminta informasi dari server atau menjalankan tindakan pada server API atau layanan mikro.
Lalu Lintas Terkait API–Lalu lintas internet yang terdiri dari permintaan HTTP atau HTTPS dan memiliki konten respons XML atau JSON, yang menunjukkan bahwa data sedang diteruskan ke aplikasi, biasanya melalui SOAP, WSDL, REST API, atau gRPC (lihat di bawah).
Pengujian Keamanan Aplikasi Dinamis (DAST)–Proses menganalisis aplikasi atau server API dengan menggunakan antarmuka, baik antarmuka pengguna untuk aplikasi, web ujung depan untuk web aplikasi, atau URLs untuk titik akhir API. Pada jenis pengujian kotak hitam, pendekatan ini mengevaluasi aplikasi dari "luar ke dalam" dengan menyerang aplikasi dengan cara yang sama seperti penyerang, biasanya tanpa pengetahuan tentang proses internal.
Pengujian Keamanan Aplikasi Statis (SAST)–Sebuah pendekatan terhadap keamanan aplikasi yang memindai kode sumber, biner, atau byte untuk pola kesalahan atau kerentanan yang dikenali. Terkadang disebut sebagai pengujian kotak putih, SAST menggunakan pendekatan “dari dalam ke luar” yang mengidentifikasi potensi kerentanan dan kesalahan yang mungkin dapat atau tidak dapat dieksploitasi oleh penyerang eksternal. Alat statis yang ringan dapat memberikan umpan balik waktu nyata kepada pengembang dalam IDE mereka.
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
5/23
Otorisasi Tingkat Objek Rusak merupakan masalah yang tersebar luas dan mudah dieksploitasi di web aplikasi karena panggilan API membawa informasi status. Aplikasi rentan jika memungkinkan pengguna mengambil tindakan dengan menentukan pengenal dalam API tanpa memeriksa apakah mereka memiliki otorisasi untuk mengambil tindakan tersebut.
SOAP/WSDL–Protokol berbasis XML untuk membuat Web API. SOAP adalah protokol itu sendiri dan WSDL (Web Bahasa Definisi Layanan) adalah format yang digunakan untuk menjelaskan layanan secara formal. Karena beban yang besar, gaya API ini menjadi tidak populer untuk pengembangan baru.
ISTIRAHAT–A Web Gaya API yang melibatkan pertukaran pesan langsung melalui HTTP, menggunakan semantik HTTP URLs dan kata kerja, tanpa menggunakan "amplop" tambahan. Konten biasanya dikodekan sebagai JSON, meskipun dalam beberapa kasus berupa XML.
GraphQL–Bahasa kueri yang dirancang untuk digunakan dalam API (dengan permintaan dan respons dalam JSON), bersama dengan runtime sisi server untuk menjalankan kueri ini. Bahasa ini memungkinkan klien untuk menentukan struktur data yang mereka butuhkan dan kemudian menerimanya dari server dalam format tersebut.
gRPC–Protokol API yang berkinerja lebih tinggi daripada REST. Protokol ini menggunakan HTTP/2 dan keunggulan kinerjatagyang menawarkan HTTP/1.1. Format pesan individual biasanya biner dan berdasarkan ProtoBuf, yang lagi-lagi menciptakan keunggulan kinerjataglebih dari REST dan SOAP.
2023 Keamanan API Teratas Tahun 10
Entri Keamanan API Analog 2019
API1:2023–Otorisasi Tingkat Objek Rusak
API1:2019–Otorisasi Tingkat Objek Rusak
API2:2023–Autentikasi Rusak
API2:2019–Autentikasi Pengguna Rusak
API3:2023–Otorisasi Tingkat Properti Objek Rusak
API3:2019–Pengungkapan Data Berlebihan, API6:2019–Penugasan Massal
API4:2023–Konsumsi Sumber Daya Tak Terbatas
API4:2019–Kurangnya Sumber Daya & Pembatasan Kecepatan
API5:2023–Otorisasi Tingkat Fungsi Rusak
API5:2019–Otorisasi Tingkat Fungsi Rusak
API6:2023–Akses Tanpa Batas ke Aliran Bisnis Sensitif
API7:2023–Pemalsuan Permintaan Sisi Server
API8:2023–Kesalahan Konfigurasi Keamanan API7:2019–Kesalahan Konfigurasi Keamanan
API9:2023–Manajemen Inventaris yang Tidak Tepat
API9:2019–Manajemen Aset yang Tidak Tepat
API10:2023–Konsumsi API yang Tidak Aman
API8:2019–Injeksi, API10:2019–Pencatatan & Pemantauan Tidak Memadai
Source: https://owasp.org/API-Security/editions/2023/en/0x11-t10/ Source: https://owasp.org/API-Security/editions/2019/en/0x11-t10/
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
6/23
Pengembang dan tim keamanan aplikasi juga harus menerapkan kemampuan untuk memeriksa identitas pengguna melalui autentikasi dengan benar.
API1:2023–Otorisasi Tingkat Objek Rusak
Apa itu?
API memungkinkan akses ke layanan dan data menggunakan standar web permintaan. Perusahaan mengekspos infrastruktur dan data mereka ke akses langsung yang tidak aman ketika aset tersebut tidak terlindungi dengan baik atau ketika kontrol otorisasi diterapkan dengan buruk atau tidak ada. Otorisasi Tingkat Objek yang Rusak–juga disebut Referensi Objek Langsung yang Tidak Aman (IDOR)–dapat menyebabkan berbagai risiko, mulai dari pengungkapan data hingga pengambilalihan akun secara penuh.
Apa yang membuat aplikasi rentan?
Ini adalah masalah yang tersebar luas dan mudah dieksploitasi di web Aplikasi. Aplikasi rentan jika memungkinkan pengguna mengambil tindakan dengan menentukan pengenal dalam API tanpa memeriksa apakah mereka memiliki otorisasi untuk melakukan tindakan tersebut.
Di mantanampSeperti yang dijelaskan secara rinci oleh OWASP, sebuah platform untuk toko daring dapat memungkinkan akses ke data toko menggunakan panggilan sederhana:
/toko/{namaToko}/pendapatan _ data.json
Hal ini tidak aman karena pengguna mana pun dapat mengganti shopName dengan nama toko pengguna lain, sehingga memperoleh akses ke data yang seharusnya tidak mereka miliki.
Serangan exampsedikit
Pada tahun 2021, seorang peneliti keamanan menemukan bahwa web-server aplikasi dan back-end yang menyediakan data ke sepeda statis Peloton memiliki beberapa titik akhir API yang memungkinkan pengguna yang tidak diautentikasi untuk mengakses data pribadi. Pada bulan Februari 2021, Peloton menerapkan perbaikan sebagian untuk masalah tersebut, membatasi akses API ke pengguna yang diautentikasi, tetapi tetap memungkinkan pengguna tersebut untuk mengakses data pribadi apa pun untuk anggota lain. Perbaikan penuh dilakukan pada bulan Mei 2021.10
Bagaimana cara mencegahnya sebagai pengembang?
Pengembang mencegah akses tidak aman ke objek dengan menerapkan kontrol ketat, menetapkan pengenal pengguna yang tidak dapat diprediksi untuk mencegah pencacahan akun, dan memeriksa otorisasi tingkat objek untuk setiap fungsi yang mengakses sumber data. Pengembang harus merangkum pemeriksaan tersebut, terutama jika berdasarkan masukan pengguna, untuk menghilangkan kemungkinan bahwa kesalahan yang tidak disengaja dapat merusak keamanan. Profesional keamanan aplikasi dan operasi harus memerlukan pemeriksaan otorisasi untuk setiap permintaan ke data backend.
Bagaimana OpenText dapat membantu?
Pengujian Keamanan Aplikasi Statis OpenTextTM (SAST) dan Pengujian Keamanan Aplikasi Dinamis OpenTextTM (DAST) dapat mendeteksi berbagai kerentanan dalam kategori Referensi Objek Langsung Tidak Aman (IDOR). IDOR dapat mencakup kerentanan seperti Penelusuran Direktori, File Unggah, dan File Inklusi. Secara lebih umum, IDOR juga mencakup kelas kerentanan di mana pengidentifikasi
10 Masters, Jan. Tour de Peloton: Data pengguna yang terekspos. Blog Pen Test Partners. Pen Test Partners. Web Halaman. 5 Mei 2021.
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
7/23
Pengembang dan tim keamanan aplikasi juga harus menerapkan kemampuan untuk memeriksa identitas pengguna melalui autentikasi dengan benar.
dapat dimodifikasi melalui URL, Body, atau Header. Sistem akan memberi tahu pengembang tentang kasus-kasus di mana pengguna dapat langsung memilih kunci utama dalam permintaan API untuk database atau kontainer penyimpanan, masalah yang sering kali menyebabkan kelas kerentanan ini. Sistem juga akan memberi peringatan ketika pemeriksaan otorisasi yang diharapkan tidak ada.
API2:2023–Autentikasi Rusak
Apa itu?
Pemeriksaan otorisasi membatasi akses ke data berdasarkan peran atau pengguna tertentu, tetapi batasan tersebut tidak cukup untuk melindungi sistem, data, dan layanan. Pengembang dan tim keamanan aplikasi juga harus menerapkan kemampuan untuk memeriksa identitas pengguna melalui autentikasi dengan benar. Meskipun autentikasi bersifat kritis, komponen-komponennya sering kali diterapkan dengan buruk atau tidak digunakan dengan benar–yang merupakan akar penyebab Autentikasi Pengguna yang Rusak. Autentikasi Pengguna yang Rusak memungkinkan penyerang untuk mengambil alih identitas pengguna lain untuk sementara atau selamanya dengan mengeksploitasi token autentikasi yang tidak aman atau membahayakan kelemahan implementasi.
Apa yang membuat aplikasi rentan?
Masalah umum dan mudah dieksploitasi ini terjadi karena autentikasi merupakan proses rumit yang dapat membingungkan dan, menurut definisinya, terekspos ke publik. Kesalahan pengembang dan kesalahan konfigurasi aplikasi dapat mengakibatkan kurangnya pemeriksaan yang diperlukan yang memungkinkan penyerang menghindari autentikasi. Pengembang yang gagal menerapkan autentikasi untuk titik akhir tertentu atau mengizinkan mekanisme autentikasi yang lemah membuat aplikasi rentan terhadap berbagai serangan, seperti credential stuffing, token replay, atau password sniffing.
Serangan exampsedikit
Antara Februari dan Juni 2023, serangan pencurian kredensial menargetkan pengecer pakaian Hot Topic, yang memberi tahu pelanggannya bahwa sejumlah akun yang tidak diketahui telah dibobol. Para penyerang–dengan menggunakan kredensial yang diambil dari sumber yang tidak diketahui–dapat mengakses data pribadi yang sensitif, seperti nama pelanggan, alamat email, riwayat pesanan, nomor telepon, serta bulan dan tanggal lahir.11
Pada bulan Februari 2022, wadah penyimpanan cloud yang dikonfigurasi secara salah meninggalkan 1 GB data sensitif dari layanan pemasaran email Beetle Eye tanpa perlindungan kata sandi atau enkripsi. Data tersebut mencakup informasi kontak dan informasi terkait pariwisata yang dikumpulkan oleh berbagai agen pariwisata dan negara bagian AS.12 Mekanisme autentikasi yang dikonfigurasi secara salah dianggap sebagai varian dari kategori Autentikasi Pengguna yang Rusak.
Bagaimana cara mencegahnya sebagai pengembang?
11 Toulas, Bill. Jaringan ritel Hot Topic mengungkap gelombang serangan pencurian kredensial. BleepingComputer. Artikel berita. 1 Agustus 2023.
12 Nair, Prajeet. Data 7 Juta Orang Terungkap Melalui Platform Pemasaran AS. Pelanggaran Data Hari Ini. Jaringan ISMG. 11 Februari 2022.
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
8/23
Standardisasi adalah sahabat Anda untuk autentikasi. Tim DevSecOps harus membuat satu– atau sejumlah terbatas– metode autentikasi untuk aplikasi dan memastikan bahwa pengembang menerapkan mekanisme secara seragam di semua layanan mikro dan API.
Standardisasi adalah teman Anda untuk autentikasi. Tim DevSecOps harus membuat satu–atau sejumlah terbatas–metode autentikasi untuk aplikasi dan memastikan bahwa pengembang menerapkan mekanisme secara seragam di semua layanan mikro dan API. Setiap implementasi autentikasi harus disesuaikanviewdiimplementasikan dalam konteks Standar Verifikasi Keamanan Aplikasi (ASVS) OWASP, yang saat ini berada pada versi 4,13 untuk memastikan kebenaran implementasi dan kontrol keamanan terkait. Setiap penyimpangan dari standar–terutama setiap paparan titik akhir yang tidak diautentikasi–harus dievaluasi oleh tim keamanan dan hanya diperbolehkan untuk memenuhi persyaratan bisnis yang kuat.
Bagaimana OpenText dapat membantu?
OAuth dan JWT adalah dua jenis autentikasi yang paling umum digunakan untuk mengimplementasikan API, dan OpenText Dynamic Application Security Testing telah memeriksa implementasi yang lemah dari kedua standar tersebut dalam aplikasi, serta kesalahan konfigurasi dan pola yang rentan, seperti CSRF dan Session Fixation, yang muncul dalam implementasi autentikasi kustom. Pemindaian Dynamic Application Security Tool (DAST) oleh OpenText adalah cara yang bagus untuk mendeteksi kerentanan autentikasi, terutama dalam API.
Pengujian Keamanan Aplikasi Statis OpenText memungkinkan berbagai pemeriksaan yang berkaitan dengan autentikasi yang buruk. Alat analisis statis mencakup deteksi untuk masalah umum–seperti kebocoran kredensial–serta masalah yang sangat spesifik pada API seperti klaim perlindungan yang hilang dalam token JWT, atau klaim yang terjadi di header JWT.
API3:2023–Otorisasi Tingkat Properti Objek Rusak
Apa itu?
Broken Object Property Level Authorization merupakan kategori baru dalam daftar OWASP 2023 yang menggabungkan dua kategori dari daftar sebelumnya: Excessive Data Exposure (API3:2019) dan Mass Assignment (API6:2019). Masalah ini disebabkan oleh kurangnya validasi otorisasi pengguna–atau otorisasi pengguna yang tidak tepat–di tingkat properti objek. Titik akhir API harus memvalidasi bahwa setiap pengguna memiliki otorisasi untuk setiap properti yang mereka coba akses atau ubah. Memanfaatkan masalah ini dapat menyebabkan informasi terekspos atau manipulasi data oleh pihak yang tidak berwenang.
Apa yang membuat aplikasi rentan?
Masalah yang umum dan mudah dieksploitasi terjadi saat pengguna mungkin diizinkan mengakses beberapa properti objek tertentu, seperti memesan kamar di aplikasi perjalanan, tetapi tidak untuk properti lain, seperti harga kamar. Saat pengguna mengakses properti objek melalui API, aplikasi harus memeriksa apakah pengguna:
· Harus dapat memperoleh akses ke properti spesifik objek
13 Standar Verifikasi Keamanan Aplikasi OWASP. OWASP. Halaman GitHub. Terakhir diakses: 17 November 2023.
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
9/23
Otorisasi Tingkat Properti Objek Rusak adalah kategori baru dalam daftar OWASP 2023 yang menggabungkan dua kategori dari daftar sebelumnya: Pemaparan Data Berlebihan (API3:2019) dan Penugasan Massal (API6:2019).
Pengujian Keamanan Aplikasi Statis OpenTextTM membantu mencegah paparan data berlebihan dan penugasan massal melalui analisis aliran data. Sistem akan menyoroti banyak sumber data pribadi, seperti yang berdasarkan nama variabel atau panggilan API tertentu, dan mengidentifikasi objek yang memungkinkan penugasan massal.
(pelanggaran sebelumnya dikenal sebagai Paparan Data Berlebihan), dan/atau
· Diperbolehkan untuk mengubah properti spesifik dari objek (beberapa aplikasi gagal untuk memeriksa ini karena mereka menggunakan kerangka kerja untuk memetakan secara otomatis web meminta parameter ke bidang objek, masalah yang dikenal sebagai Penugasan Massal).
Dalam contoh OWASPample, platform video daring memungkinkan pengguna mengubah deskripsi video, bahkan video yang diblokir, tetapi tidak mengizinkan pengguna mengubah properti `diblokir'.
TARUH /api/video/perbarui _ video
{
“description”: “video lucu tentang kucing”,
“diblokir”: salah
}
Serangan exampsedikit
Pada bulan Januari 2022, sebuah program bug bounty menemukan kelemahan di Twitter yang memungkinkan pengguna mengirimkan alamat email atau nomor telepon ke sistem Twitter, yang kemudian akan mengembalikan nama akun yang berisi informasi tersebut.14 Seorang penyerang tak dikenal menggunakan kelemahan tersebut untuk menyusun daftar jutaan akun pengguna yang ditautkan ke nomor telepon dan alamat email. Dengan mengizinkan siapa pun untuk menautkan dua properti, Twitter secara tidak sengaja memungkinkan pengguna anonim untuk diidentifikasi secara lebih spesifik.
Bagaimana cara mencegahnya sebagai pengembang?
Pengembang harus selalu menerapkan kontrol yang tepat pada kemampuan untuk mengakses atau mengubah properti objek tertentu. Daripada mengembalikan struktur data umum dengan setiap properti–yang sering terjadi dengan metode generik, seperti to_json() dan to_string()–programmer harus sangat spesifik dalam informasi apa yang mereka kembalikan. Sebagai langkah keamanan tambahan, aplikasi harus menerapkan validasi respons berbasis skema yang memberlakukan kontrol keamanan pada semua data yang dikembalikan oleh metode API. Akses harus mengikuti prinsip hak istimewa paling rendah, hanya mengizinkan akses jika benar-benar diperlukan.
Bagaimana OpenText dapat membantu?
Pengujian Keamanan Aplikasi Statis OpenTextTM membantu mencegah paparan data yang berlebihan dan penugasan massal melalui analisis aliran data. Sistem akan menyoroti banyak sumber data pribadi, seperti yang berdasarkan nama variabel atau panggilan API tertentu, dan mengidentifikasi objek yang memungkinkan penugasan massal. Pengguna juga dapat menentukan sumber mereka sendiri, melacak data melalui program, dan jika berakhir di tempat yang tidak tepat, memberi tahu pengembang atau operator tentang risiko tersebut.
14 Insiden yang memengaruhi beberapa akun dan informasi pribadi di Twitter. Pusat Privasi Twitter. Twitter. Web Halaman. 5 Agustus 2022.
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
10/23
Aplikasi yang tidak membatasi sumber daya yang ditetapkan untuk memenuhi permintaan bisa rentan, termasuk aplikasi yang gagal membatasi memori yang dapat dialokasikan, jumlah memori yang dapat dialokasikan, dan sebagainya. fileatau proses yang diakses, atau tingkat permintaan yang diizinkan, di antara atribut lainnya.
Selain itu, OpenText SAST memiliki pengetahuan tentang mekanisme serialisasi dan deserialisasi JSON dan XML yang paling penting. Dengan menggunakan ini, alat tersebut dapat mendeteksi kode yang tidak melakukan deserialisasi objek transfer domain (DTO) dengan benar, yang dapat memungkinkan penugasan massal atributnya. Beberapa kasus paparan informasi dan penugasan massal juga dapat dideteksi menggunakan Pengujian Keamanan Aplikasi Dinamis OpenText. Akhirnya, beberapa tindakan pencegahan dapat diterapkan melalui penambahan aturan ke web firewall aplikasi (WAF).
API4:2023–Konsumsi Sumber Daya Tak Terbatas
Apa itu?
API memaparkan banyak fungsi bisnis yang berguna. Untuk melakukannya, API menggunakan sumber daya komputasi seperti server basis data atau mungkin memiliki akses ke komponen fisik melalui teknologi operasional. Karena sistem memiliki sekumpulan sumber daya yang terbatas untuk menanggapi panggilan API, penyerang dapat secara khusus menyusun permintaan untuk membuat skenario yang mengakibatkan habisnya sumber daya, penolakan layanan, atau peningkatan biaya bisnis. Dalam banyak kasus, penyerang dapat mengirim permintaan API yang mengikat sumber daya yang signifikan, sehingga membebani sumber daya mesin atau bandwidth dan mengakibatkan serangan penolakan layanan. Dengan mengirim permintaan berulang dari alamat IP atau instans cloud yang berbeda, penyerang dapat melewati pertahanan yang dirancang untuk mendeteksi lonjakan penggunaan yang mencurigakan.
Apa yang membuat aplikasi rentan?
API requests trigger responses. Whether those responses involve accessing a database, performing I/O, running calculations, or (increasingly) generating the output from a machine-learning model, APIs use computing, network, and memory resources. An attacker can send API requests to an endpoint as part of a denial-of-service (DoS) attack that, rather than overwhelm bandwidth–the goal of a volumetric DoS attack–instead exhaust CPU, memory, and cloud resources. Applications that do not limit the resources assigned to satisfy a request can be vulnerable, including those that fail to restrict allocable memory, number of fileatau proses yang diakses, atau tingkat permintaan yang diizinkan, di antara atribut lainnya.
API pemrosesan server perlu memiliki batasan untuk mencegah alokasi memori dan beban kerja yang berlebihan, permintaan berlebihan untuk operasi yang dipicu API, atau biaya berlebihan untuk layanan pihak ketiga tanpa batas pengeluaran.
A common attack is to modify the arguments passed to the API endpoint, such as increasing the size of the response and requesting millions of database entries, rather than, say, the first ten:
/api/pengguna?halaman=1&ukuran=1000000
Selain itu, jika penyerang dapat mengakses layanan backend yang mengenakan biaya untuk penggunaan, serangan konsumsi sumber daya dapat digunakan untuk menaikkan biaya bagi pemilik aplikasi. Contoh OWASP lainnyaample menunjuk pada fitur pengaturan ulang kata sandi yang menggunakan pesan teks SMS untuk memverifikasi identitas dan yang dapat dipanggil ribuan kali untuk menambah biaya bagi korban.
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
11/23
Penyaringan di tepi jaringan menggunakan jaringan pengiriman konten (CDN) yang dipasangkan dengan web firewall aplikasi (WAF) dapat mengurangi banjir lalu lintas sambil meminimalkan dampak bagi pengguna individu.
POST /sms/kirim _ setel ulang _ sandi _ kode
Tuan rumah: willyo.net {
“nomor telepon”: “6501113434” }
Serangan exampsedikit
Karena serangan yang menghabiskan sumber daya sering kali disamakan dengan masalah kinerja dan ketersediaan, perusahaan yang menjadi target cenderung memperlakukannya sebagai bagian dari biaya menjalankan bisnis, bukan insiden yang perlu dilaporkan, sehingga mengurangi visibilitas terhadap ancaman tersebut. Pada tahun 2022, serangan distributed-denialof-service (DDoS) lapisan aplikasi, yang merupakan bagian dari serangan yang menghabiskan sumber daya API, menurun sebagai bagian dari semua serangan, tetapi Q4 2022 masih mencatat 79% lebih banyak serangan daripada kuartal yang sama tahun sebelumnya.15
Dalam satu serangan yang diuraikan pada tahun 2015, seorang pengembang mendeteksi klien Android yang berulang kali menghubungi situs mereka Web API dengan kunci API yang dibuat secara acak, yang mengakibatkan serangan penolakan layanan. Pengembang berhipotesis bahwa aplikasi berbahaya yang diinstal pada perangkat Android mencoba menebak kunci API 64-bit.16
Bagaimana cara mencegahnya sebagai pengembang?
Dengan menggunakan batas kecepatan dan ambang batas, sebagian besar serangan terhadap penggunaan sumber daya dapat diredam, meskipun lalu lintas yang sah juga dapat terpengaruh oleh pertahanan yang dibangun dengan buruk. Batasan khusus harus ditetapkan pada:
· Alokasi memori
· Proses
· Contoh awan
· Diunggah file deskriptor dan file ukuran
· Catatan dikembalikan
· Jumlah transaksi berbayar ke layanan pihak ketiga
· Semua parameter yang masuk (misalnya, panjang string, panjang array, dll.)
· Jumlah interaksi API per klien dalam jangka waktu tertentu
Penyaringan di tepi jaringan menggunakan jaringan pengiriman konten (CDN) yang dipasangkan dengan web firewall aplikasi (WAF) dapat mengurangi banjir lalu lintas sekaligus meminimalkan dampaknya terhadap pengguna perorangan. Platform pengiriman aplikasi memungkinkan penyaringan yang mudah, termasuk pembatasan memori, CPU, dan proses.
15 Yoachimik, Omer. Laporan ancaman DDoS Cloudflare untuk Q2022 4. Blog Cloudflare. Web Halaman. 10 Januari 2023.
16 Cara menghentikan serangan hack/DOS di web API. StackOverflow. Web Halaman. 15 Sep 2015.
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
12/23
Pengujian Keamanan Aplikasi Dinamis OpenText dapat menguji server dan fungsi API untuk mengetahui kerentanan terhadap serangan penolakan layanan tanpa memengaruhi layanan. Selain itu, tindakan menjalankan pemindaian DAST dapat menguji lingkungan secara cukup untuk menunjukkan potensi kelemahan dalam penggunaan sumber daya.
Bagaimana OpenText dapat membantu?
Dengan OpenText SAST dan OpenText Dynamic Application Security Testing, tim DevSecOps dapat menguji kode dan infrastruktur mereka untuk ketahanan terhadap serangan yang menguras sumber daya. OpenText SAST dapat menemukan banyak area di mana penyerang dapat menyalahgunakan logika aplikasi untuk menciptakan konsumsi sumber daya yang ekstrem.
Keamanan tingkat kode tidak cukup untuk mengatasi masalah ini dalam aplikasi. Penipisan sumber daya dan pembatasan kecepatan adalah sub-segmen khusus dari serangan penolakan layanan yang harus dikurangi saat dijalankan. Pengujian Keamanan Aplikasi Dinamis OpenText dapat menguji server dan fungsi API untuk mengetahui kerentanan terhadap serangan penolakan layanan tanpa memengaruhi layanan. Selain itu, tindakan menjalankan pemindaian DAST dapat menguji lingkungan secara cukup untuk menunjukkan potensi kelemahan dalam penggunaan sumber daya.
API5:2023–Otorisasi Tingkat Fungsi Rusak
Apa itu?
Aplikasi modern memiliki banyak fungsi berbeda yang mengakses, membuat, memanipulasi, menghapus, dan mengelola data. Tidak setiap pengguna aplikasi memerlukan akses ke setiap fungsi atau semua data, dan tidak boleh diizinkan berdasarkan prinsip hak istimewa paling rendah. Setiap titik akhir API memiliki audiens yang dituju yang dapat mencakup pengguna anonim, pengguna biasa yang tidak memiliki hak istimewa, dan pengguna yang memiliki hak istimewa. Fungsi administratif dan manajemen harus memerlukan otorisasi istimewa, tetapi terkadang dapat diakses melalui panggilan API yang sah dari pengguna yang tidak memiliki otorisasi–asal dari Otorisasi Tingkat Fungsi yang Rusak. Karena hierarki, grup, dan peran yang berbeda menciptakan kompleksitas dalam kontrol akses, fungsi aplikasi mungkin tidak memiliki batasan yang sesuai tentang siapa yang dapat memanggilnya.
Apa yang membuat aplikasi rentan?
Aplikasi yang memungkinkan fungsi tertentu untuk menjalankan tugas administratif mungkin tidak membatasi akses ke fungsi tersebut dengan cara yang aman. API yang secara langsung memetakan ke fungsi tersebut akan mengekspos kelemahan tersebut terhadap eksploitasi. Fungsi yang tidak menggunakan mekanisme autentikasi dan otorisasi aplikasi harus dianggap sebagai potensi kelemahan keamanan.
Di mantanampSeperti yang dikutip oleh OWASP, seorang penyerang memperoleh akses ke permintaan API untuk menambahkan pengguna yang diundang ke aplikasi seluler baru, dengan memperhatikan bahwa undangan tersebut menyertakan informasi tentang peran orang yang diundang. Dengan memanfaatkan kelemahan tersebut, penyerang mengirimkan undangan baru:
POST /api/undangan/baru
{
“email”: “penyerang@somehost.com”,
“peran”:”admin”
} Hal ini memungkinkan mereka memperoleh hak istimewa administratif pada sistem.
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
13/23
Tim DevSecOps harus merancang pendekatan standar terhadap otorisasi dan autentikasi yang mencegah akses ke permintaan secara default, dengan menerapkan default “tolak semua”.
Kontrol aplikasi dan alur logika merupakan inti dari semua bisnis daring, dan seiring dengan semakin banyaknya perusahaan yang memindahkan operasinya ke cloud, alur tersebut dapat terekspos dan dieksploitasi. Akses yang berlebihan ini dapat merugikan bisnis.
Serangan exampsedikit
Pada tahun 2022, Departemen Asuransi Texas memberi tahu publik bahwa informasi hampir dua juta warga Texas telah terekspos melalui bagian dari aplikasi kompensasi pekerja yang secara tidak sengaja memungkinkan anggota masyarakat mengakses data yang dilindungi.17 Dalam insiden kedua pada tahun 2022, perusahaan telekomunikasi Australia Optus mengakui bahwa informasi pribadi dan akun sebanyak 10 juta warga Australia telah terekspos oleh API yang tidak memerlukan autentikasi atau otorisasi apa pun. Sementara Optus menyebut serangan itu "canggih", seorang peneliti keamanan yang mengetahui detail serangan itu menggambarkannya sebagai "sepele".18
Bagaimana cara mencegahnya sebagai pengembang?
Tim DevSecOps harus merancang pendekatan standar untuk autentikasi dan otorisasi yang mencegah akses ke permintaan secara default, dengan memberlakukan default "tolak semua". Dari default ini, selalu terapkan prinsip hak istimewa paling rendah saat menentukan akses untuk peran/grup/pengguna. Pengembang harus memastikan bahwa autentikasi dan otorisasi tersedia untuk semua kata kerja/metode HTTP yang relevan (misalnya, POST, GET, PUT, PATCH, DELETE) yang terkait dengan setiap titik akhir API. Kata kerja yang tidak relevan harus ditolak. Selain itu, pengembang harus mengimplementasikan kelas dasar untuk akses dan manajemen administratif, menggunakan pewarisan kelas untuk memastikan bahwa kontrol otorisasi memeriksa peran pengguna sebelum memberikan akses. Semua fungsi administratif penting harus menggunakan mekanisme otorisasi untuk mencegah peningkatan hak istimewa.
Bagaimana OpenText dapat membantu?
Dengan menggabungkan fitur analisis kode statis dan API dari Pengujian Keamanan Aplikasi Statis OpenTextTM dengan pemeriksaan runtime dari rangkaian Pengujian Keamanan Aplikasi Dinamis (DAST) OpenText, tim DevSecOps dapat mengevaluasi aplikasi mereka untuk masalah otorisasi tingkat fungsi yang rusak dan terus menguji kode produksi untuk kelemahan keamanan sebelum menerapkannya. Untuk mendeteksi masalah Otorisasi Fungsi Objek yang Rusak, Pengujian Keamanan Aplikasi Statis OpenTextTM menggunakan aturan yang menentukan kapan pemeriksaan otorisasi diharapkan dalam bahasa pemrograman dan kerangka kerja tertentu, dan tidak adanya pemeriksaan tersebut dilaporkan.
API6:2023–Akses Tanpa Batas ke Aliran Bisnis Sensitif
Apa itu?
Mulai dari bot sneaker hingga bot tiket, serangan terhadap inventaris pengecer daring melalui API mereka telah menjadi masalah yang signifikan bagi situs e-commerce. Dengan memahami model bisnis dan logika aplikasi, penyerang dapat membuat serangkaian panggilan API yang dapat secara otomatis memesan atau membeli
17 Beeferman, Jason. Informasi pribadi 1.8 juta warga Texas yang memiliki klaim dari Departemen Asuransi telah terekspos selama bertahun-tahun, menurut hasil audit. The Texas Tribune. 17 Mei 2022.
18 Taylor, Josh. Pelanggaran data Optus: semua yang kita ketahui sejauh ini tentang apa yang terjadi. The Guardian. 28 Sep 2022.
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
14/23
Mencegah Akses Tidak Terbatas ke Arus Bisnis yang Sensitif lebih mengenai pendekatan holistik terhadap keamanan aplikasi dan bukan tentang menemukan teknologi tertentu.
inventaris, sehingga mencegah konsumen sah lainnya memperoleh akses ke produk atau layanan bisnis. Setiap API yang memungkinkan akses ke proses bisnis dapat digunakan oleh penyerang untuk memengaruhi bisnis dan termasuk dalam definisi Akses Tak Terbatas ke Alur Bisnis Sensitif.
Apa yang membuat aplikasi rentan?
Kontrol aplikasi dan alur logika merupakan jantung dari semua bisnis daring, dan seiring dengan semakin banyaknya perusahaan yang memindahkan operasinya ke cloud, alur tersebut dapat terekspos dan dieksploitasi. Akses yang berlebihan ini dapat merugikan bisnis, ketika penyerang mengotomatiskan pembelian produk, membuat bot untuk meninggalkan komentar, dan mengirim ulangviews, atau mengotomatiskan reservasi barang atau jasa.
Jika suatu aplikasi menawarkan titik akhir yang memiliki akses ke alur bisnis perusahaan tanpa membatasi akses ke operasi bisnis di balik titik akhir tersebut, maka aplikasi tersebut akan rentan. Perlindungan yang diberikan meliputi pembatasan jumlah upaya akses dari satu perangkat melalui sidik jari, pendeteksian apakah aktivitas tersebut berasal dari pelaku manusia, dan pendeteksian apakah ada otomatisasi yang terlibat.
Serangan exampsedikit
Ketika tiket Taylor Swift mulai dijual di Ticketmaster pada bulan November 2022, 1.5 juta pelanggan telah melakukan pra-registrasi, tetapi lebih dari 14 juta permintaan–termasuk tiga kali lipat lalu lintas bot–berpindah ke lebih dari XNUMX juta pelanggan baru.amped the purchasing links and APIs as soon as ticket sales opened. The site crashed, preventing many customers from purchasing tickets.19
Serangan bot penjual kembali mirip dengan yang merusak peluncuran PlayStation 5 pada November 2020. Masalah rantai pasokan telah membatasi pasokan sebelum peluncuran konsol game Sony terbaru, tetapi bot otomatis membuat pencarian unit yang tersedia menjadi lebih sulit dan menyebabkan harga jual kembali yang sangat tinggi. Dalam kasus salah satu situs e-commerce, jumlah transaksi "tambahkan ke keranjang" meningkat dari rata-rata 15,000 permintaan per jam menjadi lebih dari 27 juta, menggunakan API toko untuk langsung meminta produk berdasarkan nomor SKU.20
Bagaimana cara mencegahnya sebagai pengembang?
Pengembang harus bekerja sama dengan tim operasi bisnis dan tim teknik untuk mengatasi masalah potensi akses berbahaya ke alur bisnis. Tim bisnis dapat mengidentifikasi alur mana yang terekspos melalui API dan melakukan analisis ancaman untuk menentukan bagaimana penyerang dapat menyalahgunakan titik akhir tersebut. Sementara itu, pengembang harus bekerja sama dengan tim teknik sebagai bagian dari tim DevOps untuk menetapkan langkah-langkah pertahanan teknis tambahan, seperti menggunakan sidik jari perangkat untuk mencegah instans browser otomatis membanjiri dan mengidentifikasi pola dalam perilaku yang membedakan antara pelaku manusia dan mesin.
19 Steele, Billy. Ticketmaster tahu ada masalah bot, tetapi ingin Kongres memperbaikinya. Engadget. Artikel Berita. 24 Jan 2023.
20 Muwandi, Tafara dan Warburton, David. Bagaimana Bot Merusak Peluncuran PlayStation 5 bagi Jutaan Gamer. Blog F5 Labs. F5. Web Halaman. 18 Maret 2023.
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
15/23
Mantan paling terkenalampsalah satu serangan SSRF melibatkan mantan anggota Amazon Web Teknisi Layanan (AWS) yang mengeksploitasi kesalahan konfigurasi web firewall aplikasi (WAF) untuk kemudian menggunakan kelemahan SSRF guna mengumpulkan data dari instans server milik raksasa keuangan Capital One.
Tim operasi juga harus meninjauview API apa pun yang dirancang untuk digunakan oleh mesin lain, seperti untuk kasus penggunaan B2B, dan memastikan bahwa beberapa pertahanan diterapkan untuk mencegah penyerang mengeksploitasi interaksi mesin-ke-mesin.
Bagaimana OpenText dapat membantu?
Menangkap arus bisnis yang rentan dan sensitif sering kali bergantung pada melakukan hal-hal mendasar. Perusahaan perlu mendokumentasikan dan melacak semua API yang berfungsi dan menentukan API mana yang mengekspos proses dan data sensitif ke penyerang potensial. Logika aplikasi juga perlu dianalisis untuk menemukan kelemahan logika yang dapat dimanfaatkan oleh penyerang.
Secara keseluruhan, mencegah Akses Tidak Terbatas ke Arus Bisnis Sensitif lebih mengenai pendekatan holistik terhadap keamanan aplikasi dan bukan tentang menemukan teknologi tertentu.
API7:2023–Pemalsuan Permintaan Sisi Server
Apa itu?
Server backend menangani permintaan yang dibuat melalui titik akhir API. Server-Side Request Forgery (SSRF) adalah kerentanan yang memungkinkan penyerang untuk mendorong server agar mengirim permintaan atas nama mereka dan dengan tingkat hak istimewa server. Sering kali serangan menggunakan server untuk menjembatani celah antara penyerang eksternal dan jaringan internal. Serangan SSRF dasar menghasilkan respons yang dikembalikan ke penyerang, skenario yang jauh lebih mudah daripada serangan SSRF buta, di mana tidak ada respons yang dikembalikan, sehingga penyerang tidak memiliki konfirmasi apakah serangan itu berhasil.
Apa yang membuat aplikasi rentan?
Cacat Server-Side Request Forgery (SSRF) pada dasarnya merupakan hasil dari kurangnya validasi masukan yang diberikan pengguna. Penyerang dapat menyusun permintaan dan menyertakan URI yang menyediakan akses ke aplikasi yang menjadi target.
Konsep modern dalam pengembangan aplikasi, seperti webkaitan dan kerangka kerja aplikasi terstandar, membuat SSRF lebih umum dan lebih berbahaya, menurut OWASP.
Di mantanampdikutip oleh OWASP, sebuah jaringan sosial yang memungkinkan pengguna mengunggah fotofile gambar bisa rentan terhadap SSRF, jika server tidak memvalidasi argumen yang dikirim ke aplikasi. Daripada URL menunjuk ke suatu gambar, seperti:
POST /api/profile/upload _ gambar
{
"gambar _ url”: “http://contohample.com/profile _ gambar.jpg”
}
Seorang penyerang dapat mengirim URI yang dapat menentukan apakah port tertentu terbuka menggunakan panggilan API berikut:
{ "gambar _ url”: “host lokal:8080”
}
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
16/23
Kesalahan Konfigurasi Keamanan termasuk menyiapkan aplikasi dengan konfigurasi default yang rentan, memungkinkan akses yang terlalu permisif ke fungsi dan data sensitif, dan mengungkapkan informasi aplikasi ke publik melalui pesan kesalahan terperinci.
Bahkan dalam kasus SSRF Buta, penyerang dapat mengetahui apakah port terbuka dengan mengukur waktu yang dibutuhkan untuk mendapatkan respons.
Serangan exampsedikit
Mantan paling terkenalampsalah satu serangan SSRF melibatkan mantan anggota Amazon Web Teknisi Layanan (AWS) yang mengeksploitasi kesalahan konfigurasi web application firewall (WAF) untuk kemudian menggunakan kelemahan SSRF guna mengumpulkan data dari server milik raksasa keuangan Capital One. Insiden yang terjadi pada bulan Juli 2019 tersebut mengakibatkan data dari sekitar 100 juta warga AS dan enam juta warga Kanada dicuri.21 Amazon menganggap kesalahan konfigurasi sebagai sumber penyusupan, bukan kelemahan SSRF.22
Pada bulan Oktober 2022, sebuah perusahaan keamanan cloud memberi tahu Microsoft tentang empat kerentanan SSRF di platform cloud andalan perusahaan, Azure. Setiap kerentanan memengaruhi layanan Azure yang berbeda, termasuk layanan Azure Machine Learning dan layanan Azure API Management.23
Bagaimana cara mencegahnya sebagai pengembang?
Pengembang harus merangkum mekanisme pengambilan sumber daya dalam kode mereka, mengisolasi fitur dan melapisi perlindungan tambahan untuk memverifikasi setiap permintaan. Karena fitur tersebut biasanya digunakan untuk mengambil sumber daya jarak jauh dan bukan sumber daya internal, pengembang harus mengonfigurasi fitur yang dienkapsulasi untuk menggunakan daftar sumber daya jarak jauh yang diizinkan dan memblokir upaya untuk mengakses sumber daya internal. Pengalihan HTTP harus dinonaktifkan untuk fungsi pengambilan sumber daya dan setiap permintaan yang diurai untuk kode berbahaya.
Risiko kelemahan SSRF tidak selalu dapat dihilangkan sepenuhnya, jadi perusahaan harus mempertimbangkan dengan cermat risiko penggunaan panggilan ke sumber daya eksternal.
Bagaimana OpenText dapat membantu?
Pengujian Keamanan Aplikasi Dinamis OpenText memungkinkan tim DevSecOps untuk menguji Server-Side Request Forgery secara berkala. Pengujian Keamanan Aplikasi Dinamis OpenTextTM memindai server aplikasi dalam lingkungan yang dikonfigurasi sehingga semua komponen–aplikasi, server, dan jaringan–dapat diuji, memberikan platform analisis dinamis sebuah analisis yang komprehensif. view dampak permintaan server.
OpenText SAST dapat mendeteksi banyak kasus SSRF melalui analisis noda–misalnyaample, jika aplikasi menggunakan input pengguna yang tidak divalidasi untuk membangun URL yang kemudian akan diambil. Alat tersebut akan menandai penggunaan masukan pengguna yang tidak dibatasi.
21 Informasi tentang insiden cyber Capital One. Pemberitahuan Capitol One. Web Halaman. Diperbarui 22 Apr 2022.
22 Ng, Alfred. Amazon memberi tahu para senator bahwa mereka tidak bersalah atas pelanggaran Capital One. CNET News. com. Artikel berita. 21 Nov 2019.
23 Shitrit, Lidor Ben. Bagaimana Orca Menemukan Kerentanan Server-Side Request Forgery (SSRF) di Empat Layanan Azure yang Berbeda. Blog Keamanan Orca. Web Halaman. 17 Januari 2023.
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
17/23
Keamanan-sebagai-kode dapat membantu dengan membuat konfigurasi dapat diulang dan memberikan tim keamanan aplikasi kemampuan untuk menetapkan set konfigurasi standar untuk komponen aplikasi tertentu.
API8:2023–Kesalahan Konfigurasi Keamanan
Apa itu?
Pengembang sering salah mengonfigurasi aplikasi mereka, gagal memisahkan aset pengembangan dari aset produksi, mengekspor data sensitif filekonfigurasi s–seperti itu files–ke repositori publik mereka, dan gagal mengubah konfigurasi default. Kesalahan Konfigurasi Keamanan mencakup pengaturan aplikasi dengan konfigurasi default yang rentan, memungkinkan akses yang terlalu permisif ke fungsi dan data sensitif, dan mengungkapkan informasi aplikasi secara publik melalui pesan kesalahan terperinci.
Apa yang membuat aplikasi rentan?
Konfigurasi aplikasi default sering kali terlalu permisif, kurang memiliki pengamanan yang ketat, dan membiarkan instans penyimpanan cloud terbuka untuk umum. Sering kali, web Kerangka kerja yang menjadi dasar aplikasi mencakup sejumlah fitur aplikasi yang tidak diperlukan dan penyertaannya mengurangi keamanan.
Di mantanampdirinci oleh OWASP, sebuah jejaring sosial yang menawarkan fitur pesan langsung harus melindungi privasi pengguna, namun menawarkan permintaan API untuk mengambil percakapan tertentu menggunakan contoh berikutamppermintaan API:
DAPATKAN /dm/pengguna _ updates.json?percakapan _ id=1234567&cursor=GRlFp7LCUAAAA
Titik akhir API tidak membatasi data yang disimpan dalam cache, sehingga percakapan pribadi di-cache oleh web peramban. Penyerang dapat mengambil informasi dari peramban, sehingga pesan pribadi korban terungkap.
Serangan exampsedikit
Pada bulan Mei 2021, sebuah firma keamanan cloud memberi tahu Microsoft bahwa setidaknya 47 pelanggan yang berbeda gagal mengubah konfigurasi default instans Microsoft Power Apps mereka. Organisasi yang terpengaruh termasuk perusahaan, seperti American Airlines dan Microsoft, dan pemerintah negara bagian, seperti Indiana dan Maryland, dan mengekspos 38 juta catatan terhadap potensi kompromi di seluruh portal Power Apps.24
Pada tahun 2022, sebuah perusahaan manajemen kerentanan menemukan bahwa 12,000 instans cloud yang dihosting di Amazon Web Layanan dan 10,500 yang dihosting di Azure terus mengekspos Telnet, protokol akses jarak jauh yang dianggap "tidak sesuai untuk penggunaan berbasis internet apa pun saat ini," menurut laporan tahun 2022 Dimasukkannya fitur yang tidak perlu dan tidak aman merusak keamanan API dan aplikasi ini.
24 Upguard Research. Berdasarkan Desain: Bagaimana Izin Default pada Microsoft Power Apps Mengekspos Jutaan Orang. Blog Upgard Research. Web Halaman. 23 Agustus 2021.
25 Beardsley, Todd. Laporan Kesalahan Konfigurasi Cloud Tahun 2022. Rapid7. Laporan PDF. hlm. 12. 20 April 2022.
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
18/23
Titik buta dokumentasi terjadi ketika rincian tujuan, fungsi, dan versi API tidak jelas karena kurangnya dokumentasi yang merinci atribut penting ini.
Bagaimana cara mencegahnya sebagai pengembang?
Tim DevSecOps perlu memahami langkah-langkah yang diperlukan untuk membuat konfigurasi aman untuk aplikasi mereka dan menggunakan jalur pengembangan otomatis untuk memeriksa konfigurasi filesebelum penerapan, termasuk pengujian unit dan pemeriksaan waktu proses secara berkala untuk terus memeriksa perangkat lunak guna mengetahui kesalahan konfigurasi atau masalah keamanan. Keamanan sebagai kode dapat membantu, dengan membuat konfigurasi dapat diulang dan memberi tim keamanan aplikasi kemampuan untuk menetapkan set konfigurasi standar untuk komponen aplikasi tertentu.
Sebagai bagian dari siklus pengembangan yang aman, pengembang dan tim operasi harus:
· Menetapkan proses penguatan yang menyederhanakan pembuatan dan pemeliharaan berulang dari lingkungan aplikasi yang aman,
· Ulangview dan memperbarui semua konfigurasi di seluruh tumpukan API untuk menggabungkan standar baru secara konsisten, dan
· Mengotomatiskan penilaian efektivitas pengaturan konfigurasi di semua lingkungan.
Bagaimana OpenText dapat membantu?
Pengujian Keamanan Aplikasi Statis OpenText dapat memeriksa konfigurasi selama proses pengembangan dan menemukan berbagai jenis kelemahan. Karena Kesalahan Konfigurasi Keamanan terjadi pada tingkat kode aplikasi dan tingkat infrastruktur, berbagai produk OpenText dapat digunakan untuk mendeteksi kesalahan konfigurasi.
Pemindaian Pengujian Keamanan Aplikasi Statis OpenText dapat memeriksa kode aplikasi untuk masalah kesalahan konfigurasi. Selama pemeriksaan analisis statis, OpenText SAST dapat mengevaluasi konfigurasi files untuk kesalahan keamanan, termasuk yang terjadi pada Docker, Kubernetes, Ansible, Amazon Web Layanan, CloudFormation, Terraform, dan templat Azure Resource Manager.
Kesalahan konfigurasi juga dapat terdeteksi selama runtime. Pengujian Keamanan Aplikasi Dinamis OpenText memungkinkan tim DevSecOps untuk menguji secara berkala kesalahan konfigurasi keamanan yang umum. Salah satu kekuatan terbesar pemindaian DAST adalah ia berjalan pada server aplikasi dalam lingkungan yang dikonfigurasi, yang berarti bahwa seluruh lingkungan–aplikasi, server, dan jaringan–diuji sekaligus, memberikan platform analisis dinamis yang komprehensif view lingkungan produksi dikonfigurasi.
API9:2023–Manajemen Inventaris yang Tidak Tepat
Apa itu?
Like most software assets, APIs have a lifecycle, with older versions replaced by more secure and efficient APIs or, increasingly, using API connected to third-party services. DevSecOps teams who do not maintain their API versions and documentation can introduce vulnerabilities when older, flawed API versions continue to be used–a weakness known as Improper Inventory Management. Best practices for inventory management require the tracking of
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
19/23
Versi API, penilaian dan inventarisasi rutin layanan terpadu, dan penghentian versi lama secara berkala untuk mencegah penyebaran kerentanan keamanan.
Apa yang membuat aplikasi rentan?
Arsitektur perangkat lunak yang bergantung pada API–terutama yang menggunakan arsitektur layanan mikro–cenderung mengekspos lebih banyak titik akhir daripada arsitektur tradisional web aplikasi. Banyaknya titik akhir API, bersama dengan kemungkinan beberapa versi API yang ada pada saat yang sama, memerlukan sumber daya manajemen tambahan dari penyedia API untuk mencegah meluasnya permukaan serangan. OWASP mengidentifikasi dua titik buta utama yang mungkin dimiliki tim DevSecOps terkait infrastruktur API mereka.
Pertama, titik buta dokumentasi terjadi ketika rincian tujuan, fungsi, dan versi API tidak jelas karena kurangnya dokumentasi yang merinci atribut penting ini.
Kedua, titik buta aliran data terjadi saat API digunakan dengan cara yang kurang jelas, sehingga menghasilkan kapabilitas yang seharusnya tidak diizinkan tanpa justifikasi bisnis yang kuat. Berbagi data sensitif dengan pihak ketiga tanpa jaminan keamanan, kurangnya visibilitas hasil akhir aliran data, dan kegagalan memetakan semua aliran data dalam API berantai merupakan titik buta.
Sebagai mantanampLaporan OWASP mengutip jaringan sosial fiktif yang memungkinkan integrasi dengan aplikasi independen pihak ketiga. Meskipun persetujuan diperlukan dari pengguna akhir, jaringan sosial tersebut tidak memiliki visibilitas yang cukup terhadap aliran data untuk mencegah pihak hilir mengakses data, seperti memantau aktivitas bukan hanya pengguna, tetapi juga teman-teman mereka.
Serangan exampsedikit
Pada tahun 2013 dan 2014, sebanyak 300,000 orang mengikuti kuis psikologi daring di platform Facebook. Perusahaan di balik kuis tersebut, Cambridge Analytica, tidak hanya mengumpulkan informasi tentang para pengguna tersebut, tetapi juga teman-teman mereka yang terhubung–populasi yang jumlahnya mencapai 87 juta orang, yang sebagian besar tidak memberikan izin untuk pengumpulan informasi mereka. Perusahaan tersebut kemudian menggunakan informasi tersebut untuk menyesuaikan iklan dan pesan kepada orang-orang tersebut atas nama klien mereka, termasuk mengirimkan iklan politik yang mendukung kampanye Trump.ampKurangnya visibilitas Facebook terhadap bagaimana pihak ketiga menggunakan informasi yang diperoleh dari platformnya merupakan salah satu faktorampContoh Manajemen Inventaris yang Tidak Tepat.
Bagaimana cara mencegahnya sebagai pengembang?
Tim DevSecOps harus mendokumentasikan semua host API dan fokus pada upaya menjaga visibilitas aliran data antara API dan layanan pihak ketiga. Cara utama untuk mencegah Manajemen Inventaris yang Tidak Tepat adalah dokumentasi terperinci dari aspek-aspek penting dari semua layanan dan host API, termasuk informasi tentang data apa yang mereka tangani, siapa yang memiliki akses ke host dan data,
26 Rosenberg, Matthew dan Dance, Gabriel. `You Are the Product': Menjadi Sasaran Cambridge Analytica di Facebook. The New York Times. Artikel berita. 8 April 2018.
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
20/23
Organisasi dapat mengelola, memantau, mengamankan, dan mendokumentasikan penggunaan API mereka menggunakan OpenText Secure API Manager oleh OpenText, yang memungkinkan tim keamanan aplikasi untuk memelihara inventaris aset API terkini.
dan versi API spesifik dari setiap host. Rincian teknis yang harus didokumentasikan meliputi implementasi autentikasi, penanganan kesalahan, pertahanan pembatasan kecepatan, kebijakan berbagi sumber daya lintas asal (CORS), dan rincian setiap titik akhir.
Volume dokumentasi yang signifikan sulit dikelola secara manual, sehingga pembuatan dokumentasi melalui proses integrasi berkelanjutan dan penggunaan standar terbuka sangat disarankan. Akses ke dokumentasi API juga harus dibatasi pada pengembang yang berwenang menggunakan API.
Selama fase pembangunan dan pengujian aplikasi, pengembang harus menghindari penggunaan data produksi pada pengembangan atau stagversi aplikasi yang diperbarui untuk mencegah kebocoran data. Saat versi API baru dirilis, tim DevSecOps harus melakukan analisis risiko untuk menentukan pendekatan terbaik dalam meningkatkan aplikasi agar dapat mengambil keuntungantage peningkatan keamanan.
Bagaimana OpenText dapat membantu?
Organisasi dapat mengelola, memantau, mengamankan, dan mendokumentasikan penggunaan API mereka menggunakan OpenTextTM Secure API Manager, yang memungkinkan tim keamanan aplikasi untuk memelihara inventaris aset API terkini. OpenText Secure API Manager menyediakan repositori resmi tempat tim DevSecOps Anda dapat menyimpan dan mengelola semua API yang digunakan oleh organisasi, sehingga memungkinkan siklus hidup yang mudah dikelola mulai dari pengembangan API hingga penghentiannya. Perangkat lunak ini membantu meningkatkan kepatuhan terhadap peraturan dan perizinan dengan memungkinkan analisis terperinci.
API10:2023–Konsumsi API yang Tidak Aman
Apa itu?
With the increasing use of native cloud infrastructure to create applications, APIs have become the point of integration between application components. However, the security posture of third-party services accessed through APIs is rarely clear, allowing attackers to determine on which services an application relies and whether any of those services have security weaknesses. Developers tend to trust the endpoints that their application interacts without verifying the external or third-party APIs. This Unsafe Consumption of APIs often leads to the application’s reliance on services that have weaker security requirements or lack fundamental security hardening, such as input validation.
Apa yang membuat aplikasi rentan?
Pengembang cenderung lebih memercayai data yang diterima dari API pihak ketiga daripada masukan pengguna, meskipun kedua sumber tersebut pada dasarnya setara bagi penyerang yang termotivasi. Karena kepercayaan yang salah tempat ini, pengembang pada dasarnya bergantung pada standar keamanan yang lebih lemah karena kurangnya validasi dan sanitasi masukan.
Konsumsi API yang Tidak Aman dapat terjadi jika aplikasi:
· Menggunakan atau mengonsumsi API lain menggunakan komunikasi yang tidak terenkripsi,
· Gagal memvalidasi dan membersihkan data dari API atau layanan lain,
· Memungkinkan pengalihan tanpa pemeriksaan keamanan apa pun, atau
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
21/23
Jika pengembang tidak membuat kode pemeriksaan keamanan dalam aplikasi mereka untuk memverifikasi data apa pun yang dikembalikan oleh titik akhir API, aplikasi mereka akan mengikuti pengalihan dan mengirimkan informasi medis sensitif kepada penyerang.
OWASP API Security Top-10 sangat penting bagi pengembang berbasis cloud yang membangun API. Namun, mengatasi kerentanan aplikasi umum seperti injeksi SQL, paparan data, dan kesalahan konfigurasi keamanan harus menjadi prioritas, karena kerentanan tersebut sering dieksploitasi oleh ancaman siber. API Security Top-10 merupakan bagian penting dari pengembangan perangkat lunak yang aman, tetapi harus menjadi prioritas kedua setelah mengatasi kerentanan aplikasi umum.
· Gagal membatasi konsumsi sumber daya menggunakan ambang batas dan batas waktu.
Di mantanampBerdasarkan laporan OWASP, API yang terintegrasi dengan penyedia layanan pihak ketiga untuk menyimpan informasi medis sensitif pengguna dapat mengirimkan data pribadi melalui titik akhir API. Penyerang dapat membahayakan host API pihak ketiga untuk menanggapi permintaan mendatang dengan Pengalihan Permanen 308: HTTP/1.1 Pengalihan Permanen 308
Lokasi: https://attacker.com/
Jika pengembang tidak membuat kode pemeriksaan keamanan dalam aplikasi mereka untuk memverifikasi data apa pun yang dikembalikan oleh titik akhir API, aplikasi mereka akan mengikuti pengalihan dan mengirimkan informasi medis sensitif kepada penyerang.
Serangan exampsedikit
Pada bulan Desember 2021, serangkaian kerentanan dalam komponen perangkat lunak sumber terbuka yang umum digunakan, Log4J, memungkinkan penyerang untuk memberikan masukan yang tidak disanitasi, seperti skrip yang dikodekan, dan menggunakan versi Log4J yang rentan untuk menjalankan skrip tersebut di server. Masalah di balik kerentanan Log4J berawal dari kurangnya validasi masukan, khususnya kegagalan untuk melakukan pemeriksaan keamanan pada data yang disediakan pengguna yang dideserialisasi. Dengan mengirimkan kode berbahaya yang diserialisasi, penyerang dapat mengeksploitasi kerentanan tersebut dan menjalankan serangan pada server yang memiliki kerentanan tersebut. Pengembang harus memeriksa semua masukan yang diberikan oleh API pihak ketiga dan sumber eksternal lainnya.27
Bagaimana cara mencegahnya sebagai pengembang?
Pengembang harus melakukan uji tuntas saat mengevaluasi penyedia layanan, menilai postur keamanan API mereka, dan menerapkan kontrol keamanan yang ketat. Selain itu, pengembang harus memastikan bahwa semua komunikasi ke API pihak ketiga dan dari pihak ketiga ke API organisasi menggunakan saluran komunikasi yang aman untuk mencegah serangan pengintaian dan serangan replay.
Saat menerima data dari pengguna dan mesin eksternal, input harus selalu disanitasi untuk mencegah eksekusi kode yang tidak disengaja. Terakhir, untuk layanan cloud yang terintegrasi melalui API, daftar izin harus digunakan untuk mengunci alamat solusi terintegrasi, daripada mengizinkan alamat IP mana pun untuk memanggil API aplikasi secara membabi buta.
Bagaimana OpenText dapat membantu?
Dengan menggabungkan fitur analisis kode statis dan API dari OpenText Static Application Security Testing dengan pemeriksaan runtime dari rangkaian OpenText Dynamic Application Security Testing (DAST), tim DevSecOps dapat memeriksa penggunaan API pihak ketiga oleh aplikasi mereka dan menguji jenis serangan umum. Untuk menemukan API yang tidak aman, OpenText Secure API Manager dapat membangun repositori semua API yang dipanggil oleh sistem serta aplikasi eksternal mana yang dapat menggunakan API aplikasi Anda.
27 Microsoft Threat Intelligence. Panduan untuk mencegah, mendeteksi, dan mencari eksploitasi kerentanan Log4j 2. Microsoft. Web halaman. Diperbarui: 10 Januari 2022.
Panduan Pengembang untuk OWASP Top 2023 tahun 10 untuk Keamanan API
22/23
Ke mana selanjutnya?
Berikut adalah produk yang disebutkan dalam dokumen ini: OpenText Application Security >
Pengujian Keamanan Aplikasi Statis OpenText >
Pengujian Keamanan Aplikasi Dinamis OpenText >
Manajer API Aman OpenText >
Sumber daya tambahan 10 Risiko Keamanan API Teratas OWASP–2023 >
Gartner Magic Quadrant untuk Pengujian Keamanan Aplikasi >
Keamanan Aplikasi OpenText WebSeri inar >
10 Keamanan API Teratas tidak cukup!
Bagi pengembang cloud-native yang secara khusus berfokus pada pembuatan API untuk menawarkan layanan ke bagian lain dari suatu aplikasi, pengguna internal, atau untuk konsumsi global, daftar OWASP API Security Top 10 merupakan dokumen penting untuk dibaca dan dipahami.
Akan tetapi, OWASP API Security Top 10 bukanlah dokumen yang berdiri sendiri. Pengembang juga perlu memastikan bahwa mereka memanfaatkan sumber praktik terbaik lainnya, seperti OWASP Top 10, yang relevan dengan aplikasi dan arsitektur mereka saat ini. Kerentanan aplikasi umum -injeksi SQL, paparan data, dan kesalahan konfigurasi keamanan- terus menjadi cara umum yang dapat dilakukan kelompok ancaman siber untuk membahayakan infrastruktur perusahaan dan harus segera diatasi. Selain itu, beberapa aplikasi berbasis API, seperti aplikasi seluler, memerlukan langkah-langkah pengamanan aplikasi yang berbeda dari aplikasi yang berdiri sendiri. web-app, dan berbeda dari apa yang mungkin diperlukan untuk menghubungkan dan perangkat IoT. Secara keseluruhan, daftar 10 Keamanan API Teratas penting, tetapi tetap hanya merupakan aspek dari siklus pengembangan perangkat lunak yang aman secara keseluruhan. Daftar tersebut, dan daftar 10 Keamanan OWASP Teratas, harus digunakan bersama dengan standar dan praktik terbaik relevan lainnya yang diperlukan untuk solusi yang sedang dianalisis.
Kesimpulan
As applications increasingly rely on cloud infrastructure, web application programming interfaces (APIs) have become the foundation of the Internet. Companies typically have hundreds, if not thousands, of API endpoints in their environment, dramatically increasing their attack surface and exposing applications to a variety of weaknesses.
Rilis daftar OWASP API Security Top 2023 tahun 10 merupakan titik awal yang baik bagi perusahaan dan pengembang untuk mendidik diri mereka sendiri tentang risiko infrastruktur berbasis API dan menilai aplikasi mereka sendiri. Bersama dengan daftar Application Security Top-10 yang lebih terkenal, kedua peringkat tersebut dapat membantu tim DevSecOps mengembangkan pendekatan holistik terhadap keamanan aplikasi mereka secara keseluruhan.
Tim DevSecOps perlu menyadari implikasi keamanan dari API, cara mengurangi kerentanan dan kelemahan keamanan implementasi, serta cara memperkuat jalur pengembangan dan server API yang dihasilkan agar lebih sulit bagi penyerang untuk membahayakan aplikasi melalui API-nya.
Hak Cipta © 2025 Open Text · 04.25 | 262-000177-001
Dokumen / Sumber Daya
 |
OpenText 262-000177-001 OWASP 10 Teratas Untuk Keamanan API [Bahasa Indonesia:] Panduan Pengguna 262-000177-001, 262-000177-001 OWASP Top 10 Untuk Keamanan API, 262-000177-001, OWASP Top 10 Untuk Keamanan API, Untuk Keamanan API, Keamanan API, Keamanan |