Cara Mengamankan API — Jangan Sampai Backend Kamu Jadi Pintu Masuk Hacker

Jujur, gue malu cerita ini. Tapi ya sudahlah. Anggep aja gue lagi confess dosa. Jadi sekitar tahun 2023, gue lagi ngerjain sebuah aplikasi internal buat satu klien di Jakarta — semacam dashboard reporting gitu, simple aja. Ada frontend React, ada backend Node.js/Express, database PostgreSQL. Standar. Salah satu fiturnya adalah API buat nampilin data laporan penjualan per bulan. Endpoint-nya: GET /api/v1/reports?month=01&year=2023.

Singkat cerita, aplikasi udah jalan. Klien seneng. Gue dibayar. Selesai.

Tiga bulan kemudian, iseng-iseng gue coba akses API itu dari Postman. Tanpa token. Tanpa header Authorization. Tanpa apa-apa. Dan lo tau apa yang terjadi? Data keluar. Lengkap. Nama customer, alamat, nomor telepon, detail transaksi, bahkan catatan internal yang harusnya cuma diliat sama manager. Semua data itu keluar sebagai JSON mentah. Tinggal GET doang. Gak ada autentikasi. Gak ada authorization. Gak ada rate limiting. Gak ada apa-apa.

Untungnya… gak ada yang tau. Untungnya endpoint itu gak pernah dipublikasikan kemana-mana. Untungnya cuma dipake internal via VPN. TAPI — itu gak ngebuat gue ngerasa lebih baik. Karena kalo ada satu aja orang yang iseng — atau bot yang scanning random IP ranges — mereka bisa dapet seluruh data customer dalam hitungan menit.

Dan dari situ gue sadar: cara mengamankan API itu bukan cuma soal “pasang authentication.” It’s way deeper than that. Banyak developer — termasuk gue dulu — mikir kalo API itu aman secara default karena “kan cuma komunikasi antar server” atau “kan gak ada UI-nya.” Padahal justru karena gak ada UI-nya, API lebih gampang di-scan dan di-exploitasi secara otomatis.

Di sini gue mau breakdown apa aja yang salah dari API gue dulu, dan apa yang sekarang gue terapin buat ngehindarin kejadian serupa. Ini technical banget — tapi gue usahain jelasin pake bahasa yang gak bikin lo ketiduran.

Kenapa API Security Itu Beda Dari Website Security?

Pertanyaan bagus. Gue dulu juga mikirnya sama aja. Website = harus aman. API = harus aman. Done.

Tapi ternyata beda. Di website tradisional, lo punya browser sebagai intermediary. Browser enforce same-origin policy. Browser punya cookie security (HttpOnly, Secure, SameSite). Browser punya built-in proteksi terhadap banyak hal. Di API murni — REST API atau GraphQL — gak ada browser. Semua request dikirim langsung dari client (bisa aplikasi mobile, script, atau tools kayak curl/Postman). Gak ada same-origin policy yang melindungi. Gak ada cookie yang terproteksi browser.

Artinya: kalo lo exposure API tanpa proteksi — siapapun bisa akses. Dari manapun. Pake alat apapun. Dan mereka bisa otomatisasi prosesnya. Bikin script yang nge-loop semua endpoint lo. Ngecek mana yang terbuka.

Dan percaya deh — skrip kayak gitu udah ada. Bot penyerang nge-scan IP public, nemu port yang terbuka, coba berbagai path API (/api/v1/users, /api/v1/orders, /graphql, /swagger.json), dan kalo dapet respons yang menarik — mereka lanjut eksploitasi.

API Adalah Window Langsung Ke Database Lo

Ini yang paling fundamental. Di arsitektur modern (SPA + API), frontend lo cuma display data. Backend API lo yang akses database. Jadi kalo API lo gak aman — penyerang langsung akses database lo. Gak perlu nge-hack frontend. Gak perlu phish admin panel. Cukup kirim HTTP request yang dibikin pake Python 12 baris.

Gue inget waktu itu gue nemuin endpoint /api/v1/users di aplikasi sendiri. Tanpa filter. Tanpa pagination. Kirim GET request — balikannya 12,000 baris data user. Lengkap. Dalam 3 detik. Bayangin berapa lama waktu yang dibutuhin buat nguras database kalo gak ada rate limiting.

Common API Vulnerabilities Yang Sering Gue Temuin

Dari pengalaman ngereview API orang lain (dan API gue sendiri, yang paling parah), ini vulnerability yang paling umum:

Broken Authentication — Si Raja Bug API

Banyak API yang implementasi authentication-nya setengah-setengah. Contoh klasik:

• Ada endpoint yang perlu auth, ada yang enggak. Dan gak konsisten.
• Token JWT tapi secret key-nya “secret” atau “supersecret” — gampang di-bruteforce.
• JWT gak ada expiration time (exp claim) — token berlaku selamanya.
• Login pake HTTP (bukan HTTPS) — token dikirim plain text, bisa di-intercept.
• Gak ada mekanisme blacklist token — jadi kalo token lo ke-curi, penyerang bisa pake selamanya.

Gue pernah nemu API production yang JWT secret key-nya literally “mysecret”. Gue coba masukin token dari API itu ke jwt.io — dan berhasil di-decode. Dari situ gue bisa bikin token palsu buat user manapun. Admin. CEO. Siapapun. Cuma modal secret key yang gampang banget ditebak.

Excessive Data Exposure — Ngasih Lebih Dari Yang Diminta

Ini yang terjadi di endpoint /api/v1/users yang gue sebutin tadi. API ngasih SEMUA data user, padahal frontend cuma butuh nama dan email doang. Alih-alih nge-filter di backend, developer-nya (ya, gue) nyerahin semua dan ngandelin frontend buat nampilin yang relevan aja.

Tapi penyerang gak peduli sama frontend lo. Mereka langsung akses API. Dan API lo ngasih segalanya: password hash, nomor telepon, alamat, data kartu kredit (harusnya gak disimpen di situ!), role, permission, dll.

Prinsipnya: API harus cuma ngasih data yang bener-bener dibutuhin. Gak lebih. Ini namanya “principle of least privilege pada level data.” Atau di OWASP disebut “Excessive Data Exposure.” Implementasinya sederhana: lo explicit pilih kolom yang dikirim. Jangan pake SELECT *.

Lack of Rate Limiting — Door Wide Open Untuk Brute Force

Rate limiting itu pertahanan basic yang sering dilupain. Tanpa rate limiting, penyerang bisa:

• Brute force password (kirim ribuan percobaan login)
• Enumerasi user (coba berbagai ID user di endpoint /api/v1/users/{id})
• Scraping semua data lo (kirim request terus-menerus sampe semua data ke-download)
• DoS (kirim banyak request sampe server lo overload)

Gue install rate limiter Express (express-rate-limit) setelah gue ngeliat sendiri betapa gampangnya nge-scrape data dari API tanpa rate limit. Dengan script sederhana Python (requests + concurrent.futures), gue bisa ngirim 50 request per detik. Tanpa rate limit, database lo habis dalam semenit.

Mass Assignment — Ngasih User Kekuasaan Terlalu Besar

Ini bug yang lucu tapi berbahaya. Framework modern kayak Laravel, Rails, atau Express (dengan ORM) punya fitur mass assignment — lo kirim JSON body, langsung di-map ke model database. Praktis. Tapi kalo lo gak nge-filter field mana yang boleh di-update, user bisa ngirim field tambahan yang ngubah data sensitif.

Contoh: endpoint PUT /api/v1/users/profile buat update profile. Lo harusnya cuma bisa update name, bio, avatar. Tapi karena mass assignment unfiltered, user bisa tambahin "role": "admin" di body request. Dan aplikasi lo akan nurut — ngubah role user jadi admin.

Fix-nya: pake whitelist. Explicitly define field apa aja yang boleh di-fill. Jangan pake blacklist. Karena blacklist gampang bolong.

Injection — SQL, NoSQL, Command Injection

Ini udah jadul sih. Tapi masih ada. Terutama di API yang dibangun sama developer yang gak familiar dengan prepared statements atau parameterized queries. SQL injection di API itu sama bahayanya dengan di website. Malah lebih gampang karena lo bisa otomatisasi.

Dan dengan munculnya NoSQL database (MongoDB, etc.), ada jenis injection baru: NoSQL injection. Mirip SQL injection — tapi query-nya pake JSON. Contoh: lo kirim {"$gt": ""} di parameter password di endpoint login — dan MongoDB nge-compare password dengan string kosong, yang bisa return true dan bikin lo login tanpa password.

Gak mau detail di sini — intinya: injection masih jadi ancaman serius di API. Prepared statements. Parameterized queries. Input validation. Always.

Cara Ngebenerin: Yang Gue Terapin Sekarang

Oke. Sekarang bagian solusinya. Ini praktik yang gue terapin di semua API yang gue bangun atau kelola.

Authentication Yang Bener: JWT + Refresh Token

Untuk REST API, JWT masih jadi standar de facto. Tapi implementasinya harus bener:

1. Secret key harus kuat. Minimal 256-bit random string. Hasilkan dari password manager atau terminal: openssl rand -base64 64. Jangan bikin sendiri. Jangan character dari keyboard.

2. Access token short-lived. 15-30 menit. Kalo token ke-curi, penyerang cuma punya 15 menit buat abuse.

3. Refresh token lebih tahan lama. 7-30 hari. Disimpen di HttpOnly cookie (buat web) atau secure storage (buat mobile). Refresh token bisa di-revoke server-side (blacklist di Redis atau database).

4. Wajib HTTPS. Gak ada excuse buat gak pake HTTPS di 2026. Sertifikat SSL gratis bertebaran dimana-mana. Kalo API lo masih jalan di HTTP — lo practically inviting attackers.

5. Blacklist token. Simpen token yang udah di-logout atau di-revoke di Redis atau database. Cek setiap request. Biar token yang udah di-logout gak bisa dipake.

OAuth2 itu bagus kalo lo punya third-party integration. Tapi buat API internal atau first-party client (aplikasi lo sendiri), JWT udah cukup. Jangan over-engineer pake OAuth2 kalo gak perlu — itu nambah kompleksitas tanpa alasan.

Input Validation: Jangan Percaya Siapapun

Prinsip nomor satu di cybersecurity: never trust user input. Validasi SEMUA input yang masuk ke API lo. Dan validasi di BACKEND, bukan di frontend. Validasi frontend itu cuma UX — gak ada nilai keamanannya karena penyerang bisa skip frontend entirely.

Untuk setiap parameter:

• Type check: apakah ini string, number, boolean?
• Format check: kalo email, pastiin format email. Kalo UUID, pastiin format UUID.
• Length check: jangan terima string 10,000 karakter di field nama.
• Range check: kalo number, pastiin di range yang logis.
• Whitelist values: kalo cuma ada beberapa pilihan, explicit check.

Pake library validasi: Joi (untuk Node.js), Pydantic (untuk Python FastAPI), DataAnnotations (untuk .NET). Jangan validasi manual pake regex recehan — lo pasti ada yang kelewat.

Rate Limiting: Bikin Barrier

Implementasi rate limiting itu gampang. Gak perlu third-party service mahal. Contoh basic pake Express:

const rateLimit = require('express-rate-limit');

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 menit
  max: 100, // maksimal 100 request per IP per 15 menit
  message: 'Too many requests, please try again later.'
});

app.use('/api/', limiter);

Tapi ini terlalu generik. Lo perlu rate limit yang lebih granular:

• /api/login: 5 request per menit per IP (anti brute force)
• /api/users: 20 request per menit per authenticated user
• /api/public: lebih generous (100/jam) tapi tetep ada limit-nya

Kalo lo pake cloud provider, load balancer mereka biasanya udah ada built-in rate limiting. AWS WAF, Cloudflare Rate Limiting, GCP Cloud Armor. Pake aja.

CORS: Jangan Wildcard *, Please

Gue ngeliat banyak API production yang CORS-nya di-set ke wildcard:

Access-Control-Allow-Origin: *

Ini artinya: website manapun di internet bisa akses API lo dari browser pengunjungnya. Kalo pengunjung website jahat itu lagi login ke aplikasi lo — browser mereka bisa ngirim request ke API lo dengan kredensial mereka. Itu bahaya.

Yang bener: explicit whitelist origin yang diizinkan. Kalo API lo cuma dipake sama app.lo.com dan admin.lo.com — cuma itu yang lo allow. Bukan *.

Don’t get me wrong — CORS bukan mekanisme keamanan yang kuat (penyerang bisa bikin request dari server, bukan browser). Tapi ini lapisan pertahanan tambahan dan gampang banget implementasinya. Gak ada alasan pake * di production.

API Gateway: Your Friend

Kalo lo punya banyak microservices (atau bakal punya), pertimbangin pake API Gateway. Kong, KrakenD, AWS API Gateway, atau bahkan Nginx yang dikonfigurasi sebagai reverse proxy.

Keuntungan API Gateway:

• Rate limiting terpusat (gak perlu implement di setiap service)
• Authentication terpusat (semua request lewat gateway, cek auth di satu tempat)
• Request/response transformation
• Logging dan monitoring terpusat
• IP whitelisting (kalo API internal)

Gue pake Kong buat salah satu project. Gak murah (ada enterprise fee), tapi worth it buat arsitektur microservices. Kalo project kecil, Nginx dengan custom rules udah cukup.

HTTPS Everywhere: No Exception

Sekali lagi karena ini penting: jangan ada satupun endpoint yang jalan di HTTP. Kalopun internal. Kalopun “cuma development.” HTTPS everywhere. Sertifikat SSL gratis. Gak ada alasan.

HTTP artinya semua data lo terkirim plain text. Token. Password. Data user. Semua bisa di-intercept sama siapapun yang ada di jaringan yang sama — ISP, admin WiFi kantor, penyerang di jaringan publik.

HSTS (HTTP Strict Transport Security) juga penting. Header ini ngasih tau browser: “Jangan pernah akses domain ini via HTTP.” Jadi walaupun user ngetik http://api.lo.com, browser otomatis redirect ke HTTPS.

Logging: Mata-Mata Lo Di Server

Logging itu bukan cuma buat debugging. Ini buat deteksi dan forensik. Yang harus lo log:

• Setiap authentication attempt (sukses maupun gagal)
• Setiap request dengan response code >= 400
• Perubahan data sensitif (role change, permission change, data deletion)
• Rate limit hit

Tapi HATI-HATI: jangan log data sensitif. Jangan log password. Jangan log token. Jangan log full request body yang isinya PII (personally identifiable information). Log secukupnya — IP, timestamp, endpoint, user ID (kalo authenticated), response code.

Gue pernah liat kode yang nge-log SELURUH request body, termasuk password dalam plain text. Itu bencana menunggu terjadi. Karena log biasanya rotasi, diarsip, kadang dikirim ke third-party logging service. Dan sekarang password user lo berserakan dimana-mana.

Tools Buat Ngetes Keamanan API Lo

Lo gak perlu alat enterprise mahal. Tools gratis udah cukup powerful:

OWASP ZAP: Ini web application scanner yang juga bisa scan API. Support REST dan GraphQL. Bisa otomatis atau manual. Open source. Gue pake ZAP buat quick scan setelah develop API baru. Dia bakal flag masalah basic: missing security headers, cookie tanpa Secure flag, parameter tanpa validasi.

Postman: Selain buat testing API, Postman bisa lo pake buat manual security test. Tambahin script pre-request buat generate random payload. Tes endpoint lo dengan berbagai input aneh. Liat responsenya.

SQLMap: Kalo lo curiga API lo vulnerable SQL injection, SQLMap bisa otomatis ngetes. Tapi pake ini cuma di API lo sendiri ya — jangan di API orang lain tanpa izin.

Burp Suite Community Edition: Versi gratis Burp Suite bisa intercept dan modify HTTP(S) request. Berguna banget buat manual testing — lo bisa liat exactly apa yang dikirim dan diterima, terus lo modifikasi parameter-parameter buat liat apakah API lo bisa di-manipulasi.

Yang Bikin Gue Masih Paranoid

Walaupun gue udah terapin semua yang di atas, gue masih gak ngerasa 100% aman. Karena keamanan itu proses, bukan status. Lo gak pernah “selesai” mengamankan sesuatu. Selalu ada kemungkinan vulnerability baru, misconfiguration, atau skenario yang gak kepikiran.

Dan jujur aja, pengalaman nemuin endpoint API sendiri yang terbuka tanpa autentikasi — itu trauma kecil yang gue bawa terus. Setiap kali ngerjain API baru, gue selalu keinget momen itu. Dan gue selalu double-check, triple-check: “Apa semua endpoint udah authenticated? Apa rate limiting udah jalan? Apa data yang dikirim cuma yang perlu?”

It’s exhausting. Tapi itu bagian dari pekerjaan.

Cara mengamankan API itu bukan list checklist yang lo centang satu-satu terus selesai. Itu mindset. Sikap skeptis terhadap kode lo sendiri. Anggep aja ada seseorang yang terus-terusan nyoba bobol API lo — dan lo kudu selalu satu langkah di depan. Karena pada akhirnya, lebih baik lo yang nemuin vulnerability lo sendiri daripada orang lain yang nemuin duluan.