GraphQL telah menjadi alternatif populer untuk REST API dalam beberapa tahun terakhir. Dikembangkan oleh Facebook pada 2012 dan dirilis sebagai open-source pada 2015, GraphQL kini digunakan oleh perusahaan besar seperti GitHub, Shopify, Twitter, dan Airbnb. Fleksibilitasnya yang memungkinkan client meminta data secara presisi menjadi daya tarik utama. Namun, di balik kemudahan itu, ada risiko keamanan yang signifikan.
Berdasarkan laporan OWASP API Security Top 10, kerentanan pada API – termasuk GraphQL – terus meningkat seiring adopsi arsitektur microservices. Serangan seperti injection, broken authorization, dan denial of service tidak hanya relevan untuk REST, tetapi juga muncul dalam bentuk yang lebih kompleks di GraphQL. Artikel ini akan membahas secara mendalam apa itu GraphQL security, kerentanan utamanya, strategi mitigasi, dan tools yang bisa digunakan developer untuk mengamankan GraphQL API.
Baca juga: Apa Itu API Security? Panduan Lengkap Mengamankan Application Programming Interface untuk Pemula untuk fondasi keamanan API secara umum.
Apa Itu GraphQL dan Mengapa Keamanannya Berbeda dari REST?
GraphQL adalah query language untuk API yang memungkinkan client menentukan struktur data yang diinginkan dalam satu permintaan. Tidak seperti REST yang memiliki banyak endpoint (misalnya /users, /users/1/posts), GraphQL menggunakan single endpoint untuk semua operasi. Client mengirimkan query yang mendeskripsikan data apa yang dibutuhkan, dan server mengembalikan respons dengan struktur yang persis sama.
Perbedaan arsitektur ini menciptakan tantangan keamanan yang unik. Pada REST API, rate limiting dan WAF (Web Application Firewall) dapat bekerja berdasarkan jumlah HTTP request. Namun pada GraphQL, satu HTTP request bisa berisi query yang sangat kompleks atau bahkan puluhan operasi sekaligus melalui batching. Firewall tradisional tidak bisa membedakan query normal dengan query berbahaya karena semua melewati satu endpoint yang sama.
Selain itu, GraphQL memiliki fitur introspection yang memungkinkan client menjelajahi seluruh skema API – termasuk tipe data, field, query, dan mutation yang tersedia. Fitur ini berguna untuk development tetapi menjadi senjata bagi penyerang untuk memetakan seluruh permukaan serangan API.
Apa Saja Kerentanan Utama pada GraphQL API?
Berdasarkan panduan OWASP GraphQL Cheat Sheet dan berbagai laporan keamanan, ada empat kategori utama kerentanan yang paling sering muncul pada implementasi GraphQL. Memahami kategori ini adalah langkah pertama untuk membangun GraphQL API yang aman.
Injection Attack pada GraphQL
Injection attack terjadi ketika penyerang menyisipkan kode berbahaya melalui input yang kemudian dieksekusi oleh server. Pada GraphQL, injection bisa terjadi di berbagai level: SQL injection melalui argumen query yang diteruskan ke database tanpa sanitasi, NoSQL injection pada database seperti MongoDB, atau bahkan OS command injection jika input digunakan untuk menjalankan perintah sistem.
Yang membedakan injection di GraphQL adalah fleksibilitas inputnya. Sebuah query GraphQL bisa menerima argumen dalam berbagai tipe data – string, integer, array, atau nested object. Jika developer tidak melakukan validasi input secara ketat, penyerang bisa mengeksploitasi celah ini untuk mengakses data yang tidak seharusnya atau bahkan mengambil alih server. Prinsip utama pencegahannya adalah parameterized queries dan validasi tipe data yang ketat pada setiap resolver.
Denial of Service (DoS) melalui Batching dan Alias Overloading
Ini adalah kerentanan paling khas GraphQL. Karena GraphQL mendukung query batching dan alias, penyerang bisa mengirim puluhan atau ratusan operasi mahal dalam satu HTTP request. Misalnya, penyerang bisa membuat query yang memanggil field yang sama berulang kali dengan parameter berbeda menggunakan alias. Satu request bisa berisi ratusan login attempt, yang secara efektif menjadi brute-force attack yang tidak terdeteksi rate limiter tradisional.
Selain itu, circular queries juga menjadi ancaman serius. Jika skema GraphQL memiliki relasi rekursif (misalnya User memiliki field friends yang juga bertipe User), penyerang bisa membuat query bertingkat tak terbatas yang menghabiskan resource server. Deep nesting queries bisa mencapai kedalaman puluhan atau ratusan level, menyebabkan server kehabisan memori atau CPU.
Baca juga: Kebocoran Data dari API: Studi Kasus Insiden Terbesar dan Pelajaran Penting untuk Developer melihat bagaimana serangan API bisa berdampak besar pada organisasi.
Information Disclosure via Introspection
Introspection adalah fitur bawaan GraphQL yang memungkinkan client menanyakan struktur skema API secara lengkap – termasuk semua tipe data, field, query, mutation, dan subscription yang tersedia. Fitur ini sangat berguna saat development untuk eksplorasi dan dokumentasi otomatis. Namun jika tetap aktif di production, penyerang bisa mendapatkan peta lengkap API tanpa perlu melakukan reverse engineering.
Berdasarkan panduan OWASP, risiko ini diperparah oleh dua hal: GraphiQL – IDE interaktif untuk GraphQL yang sering terpasang di path seperti /graphiql atau /playground – dan excessive error messages. Error message GraphQL sering menyarankan field yang valid (“Did you mean ‘firstName’?”), memberikan informasi berharga bagi penyerang untuk memetakan skema meskipun introspection dimatikan.
Broken Authorization: BOLA dan BFLA di GraphQL
Broken Object Level Authorization (BOLA) dan Broken Function Level Authorization (BFLA) adalah kerentanan di mana penyerang bisa mengakses data atau menjalankan fungsi yang tidak seharusnya. Di GraphQL, ini sering terjadi karena resolver tidak memeriksa otorisasi secara konsisten. Seorang user biasa mungkin bisa mengirim query dengan ID user lain dan mendapatkan data pribadi mereka – ini adalah serangan Insecure Direct Object Reference (IDOR) klasik.
Kasus nyata dari kerentanan ini terjadi pada aplikasi kencan Feeld yang dipresentasikan di DEF CON 33. Peneliti keamanan menemukan bahwa GraphQL API Feeld memiliki kelemahan pada kontrol akses, memungkinkan penyerang mengakses data sensitif pengguna lain termasuk pesan pribadi dan foto. Insiden ini menunjukkan bahwa model otorisasi GraphQL harus diimplementasikan di level business logic, bukan hanya di API gateway.
Bagaimana Cara Mencegah Serangan pada GraphQL API?
Setelah memahami kerentanannya, langkah selanjutnya adalah menerapkan mitigasi yang efektif. Berikut adalah strategi bertahan yang direkomendasikan oleh OWASP dan praktisi keamanan GraphQL.
Query Depth Limiting dan Cost Analysis
Depth limiting adalah teknik paling fundamental untuk mencegah deep nesting dan circular queries. Server GraphQL harus membatasi kedalaman maksimum query yang diterima – umumnya 5-10 level sudah cukup untuk kebutuhan bisnis normal. Library seperti graphql-depth-limit (JavaScript) atau MaxQueryDepthInstrumentation (Java dari GraphQL Java) bisa langsung diintegrasikan.
Namun depth limiting saja tidak cukup. Query dangkal dengan ribuan field di level yang sama tetap bisa membebani server. Oleh karena itu, perlu ditambahkan query cost analysis. Setiap field dalam skema diberi nilai “biaya” (cost), dan server menghitung total biaya setiap query sebelum mengeksekusinya. Jika melebihi threshold, query ditolak. Tools seperti graphql-cost-analysis atau graphql-validation-complexity menyediakan implementasi siap pakai.
Amount limiting juga penting – batasi jumlah maksimum item yang bisa diminta melalui argumen pagination seperti first atau last. Tanpa batasan ini, penyerang bisa meminta first: 99999999 dan menyebabkan database overload.
Rate Limiting dan Batching Control
Rate limiting tradisional (berdasarkan jumlah HTTP request) tidak efektif untuk GraphQL. Sebagai gantinya, gunakan query-based rate limiting yang menghitung kompleksitas kumulatif query dalam periode waktu tertentu. Beberapa GraphQL gateway seperti Apollo Studio dan Hasura menyediakan fitur ini secara built-in.
Untuk mencegah batching attack dan alias overloading, terapkan alias limiting. Konfigurasikan server untuk membatasi jumlah alias per query – nilai default yang aman adalah 1-3 alias. Jika aplikasi membutuhkan lebih banyak, naikkan limit hanya untuk field tertentu yang memang memerlukannya. Pendekatan deny-by-default ini direkomendasikan oleh para ahli keamanan GraphQL.
Baca juga: Cara Mengamankan REST API: Panduan Lengkap Berdasarkan OWASP API Security Top 10 untuk pendekatan keamanan API yang komprehensif.
Disable Introspection dan GraphiQL di Production
Aturan ini sederhana tetapi sering diabaikan. Nonaktifkan introspection di environment production. Jika tim development tetap membutuhkannya untuk debugging, aktifkan dengan mekanisme otentikasi khusus atau hanya untuk IP tertentu. Sebagian besar framework GraphQL (Apollo, Yoga, Hot Chocolate) memiliki flag konfigurasi untuk ini. Pastikan juga GraphiQL dan GraphQL Playground tidak bisa diakses publik.
Selain itu, konfigurasikan server untuk mengembalikan generic error messages di production. Jangan pernah menampilkan stack trace, field suggestions, atau detail skema dalam error response. Gunakan error masking middleware yang hanya mengembalikan pesan sederhana seperti “Invalid request” tanpa memberikan informasi tambahan ke client.
Input Validation dan Parameterized Queries
Setiap input yang masuk melalui query atau mutation GraphQL harus divalidasi secara ketat. Gunakan custom scalar types untuk membatasi format data yang diterima. Misalnya, buat scalar type khusus untuk email, URL, atau nomor telepon yang otomatis memvalidasi format sebelum data mencapai resolver. Skema GraphQL yang ketat adalah lapisan pertahanan pertama terhadap injection.
Untuk operasi database, selalu gunakan parameterized queries atau ORM/ODM yang aman. Jangan pernah menyusun query database dengan string concatenation dari input user. Referensi OWASP SQL Injection Prevention Cheat Sheet memberikan panduan lengkap untuk berbagai jenis database dan bahasa pemrograman.
Apa Tools Terbaik untuk Mengamankan GraphQL API?
Ada sejumlah tools yang bisa membantu developer mengamankan GraphQL API, baik dari sisi pencegahan maupun deteksi. Berikut adalah yang paling banyak digunakan di industri.
- GraphQL Armor – Plugin open-source dari Escape Tech yang menerapkan security best practices secara otomatis. Fitur utamanya meliputi alias limiting, depth limiting, dan character limit untuk mencegah eksploitasi. Bekerja sebagai middleware yang bisa langsung dipasang di Apollo Server, Yoga, dan implementasi GraphQL lainnya.
- Escape GraphQL Security Scanner – Tool DAST (Dynamic Application Security Testing) khusus GraphQL yang bisa menemukan kerentanan dalam hitungan menit. Mampu mendeteksi batching attack, injection, IDOR, dan information disclosure secara otomatis.
- Apollo Studio – Platform GraphQL dari Apollo yang menyediakan monitoring, tracing, dan schema validation. Fitur operation usage reporting-nya membantu developer mengidentifikasi query mana yang mencurigakan berdasarkan kompleksitas dan frekuensi.
- GraphQL Inspector – Tool open-source untuk membandingkan skema GraphQL, mendeteksi breaking changes, dan menemukan field yang sudah tidak digunakan (dead fields) yang bisa menjadi permukaan serangan yang terlupakan.
- InQL Scanner – Plugin Burp Suite khusus untuk GraphQL security testing. Bisa generate query berdasarkan introspection result dan membantu pentester menemukan celah keamanan.
Pertanyaan yang Sering Diajukan tentang GraphQL Security
Apakah GraphQL lebih aman daripada REST API?
Tidak secara inheren. Masing-masing memiliki tantangan keamanan yang berbeda. REST API memiliki permukaan serangan yang lebih terdistribusi (banyak endpoint) sementara GraphQL memiliki risiko pada query complexity dan information disclosure. Keamanan lebih ditentukan oleh bagaimana API tersebut diimplementasikan dan dikonfigurasi, bukan protokolnya. Keduanya membutuhkan pendekatan keamanan berlapis yang mencakup otentikasi, otorisasi, validasi input, dan rate limiting.
Apakah GraphQL introspection selalu harus dimatikan?
Di production, sangat direkomendasikan untuk menonaktifkan introspection. Namun beberapa organisasi memilih untuk tetap mengaktifkannya dengan akses terbatas (authenticated atau IP whitelist) karena introspection digunakan oleh tools monitoring dan API explorer internal. Kuncinya adalah jangan biarkan introspection bisa diakses secara publik tanpa otentikasi.
Bagaimana cara mendeteksi GraphQL injection attack?
Deteksi bisa dilakukan melalui beberapa layer: query validation di sisi server untuk menolak query dengan karakter mencurigakan, WAF yang dikonfigurasi untuk memahami payload GraphQL, logging dan monitoring untuk mendeteksi pola query yang tidak normal, serta regular security testing menggunakan tool seperti Escape Scanner atau InQL. Defense in depth adalah kuncinya.
Apakah WAF tradisional bisa melindungi GraphQL API?
WAF tradisional umumnya kurang efektif untuk GraphQL karena mereka bekerja di level HTTP request dan tidak memahami struktur query GraphQL. Batching attack dan alias overloading terlihat seperti satu request normal bagi WAF. Untuk perlindungan optimal, gunakan WAF khusus GraphQL atau kombinasikan WAF tradisional dengan GraphQL-specific middleware seperti GraphQL Armor dan query cost analysis.
Kesimpulan
GraphQL menawarkan fleksibilitas luar biasa untuk pengembangan API modern, tetapi fleksibilitas ini datang dengan tanggung jawab keamanan yang lebih besar. Kerentanan seperti injection, DoS melalui batching, information disclosure via introspection, dan broken authorization adalah ancaman nyata yang harus diantisipasi oleh setiap developer yang menggunakan GraphQL.
Pendekatan keamanan GraphQL yang efektif adalah defense in depth: validasi input di level skema, depth limiting dan cost analysis untuk mencegah DoS, otorisasi di level resolver, disable introspection di production, serta monitoring query yang mencurigakan. Tools seperti GraphQL Armor, Escape Scanner, dan Apollo Studio bisa membantu mengotomatiskan banyak aspek keamanan ini.
Berdasarkan OWASP API Security Top 10 dan laporan industri, jumlah serangan terhadap API terus meningkat setiap tahun. Organisasi yang mengabaikan keamanan GraphQL akan menghadapi risiko kebocoran data, pencurian kredensial, dan gangguan layanan. Mulailah dengan langkah sederhana: audit skema GraphQL yang ada, terapkan query depth limiting, dan nonaktifkan introspection di production.