DEV Community

Cover image for Cara Aman Lindungi API Key dari Ekstensi VS Code Berbahaya
Walse
Walse

Posted on • Originally published at apidog.com

Cara Aman Lindungi API Key dari Ekstensi VS Code Berbahaya

Pada 20 Mei 2026, GitHub mengonfirmasi bahwa penyerang mencuri data dari sekitar 3.800 repositori kode internalnya. Titik masuknya bukan zero-day di server GitHub, melainkan ekstensi VS Code terinfeksi yang diinstal di laptop karyawan. Setelah ekstensi berjalan dengan izin sistem file yang sama seperti pengembang, ia dapat membaca kode sumber, file konfigurasi, dan kredensial di ruang kerja. Jika Anda ingin melindungi kunci API dari pola serangan yang sama, pelajarannya jelas: titik terlemah sering kali bukan cloud, tetapi mesin pengembang dan alat yang berjalan di atasnya.

Coba Apidog hari ini

TL;DR

Untuk melindungi kunci API dari ekstensi IDE yang disusupi atau repositori yang bocor:

  • Jangan simpan kredensial aktif di kode sumber.
  • Jangan commit file .env.
  • Perlakukan .gitignore sebagai alat kebersihan, bukan kontrol keamanan.
  • Pisahkan kunci per lingkungan: dev, staging, production.
  • Gunakan kredensial berumur pendek dan berhak akses paling rendah.
  • Rotasi kunci secara terjadwal.
  • Simpan kredensial API di tempat yang tidak tersebar sebagai teks biasa di repo atau workspace.

Apidog dapat membantu dengan menyimpan kredensial API sebagai variabel lingkungan dengan nilai lokal, bukan hardcoded di request, script, atau file .env.

Mengapa Pembobolan GitHub Relevan untuk Developer

Insiden GitHub ini adalah contoh serangan supply chain pada lingkungan developer. Kelompok ancaman yang dilacak sebagai TeamPCP sebelumnya menanam trojan di paket npm, PyPI, dan PHP. Dalam kasus ini, payload masuk melalui ekstensi VS Code.

Menurut laporan TechCrunch, penyerang mengeksfiltrasi data dari sekitar 3.800 repositori internal dan menjual dataset tersebut dengan harga lebih dari $50.000 di forum bawah tanah. GitHub mengatakan tidak ada bukti bahwa data pelanggan di luar repositori internal tersebut terdampak, dan investigasi masih berjalan.

Masalah utamanya: ekstensi VS Code adalah kode yang berjalan dengan izin user Anda. Secara normal, ekstensi dapat:

  • membaca file di workspace,
  • memantau perubahan file,
  • membuka file konfigurasi,
  • membuat request jaringan keluar.

Itu bukan bug. Itu model ekstensi yang memang diperlukan banyak alat developer. Risikonya muncul ketika ekstensi berbahaya memakai akses yang sama untuk mencari rahasia.

Di proyek umum, targetnya biasanya mudah ditemukan:

.env
config/secrets.yml
.npmrc
~/.aws/credentials
SSH keys
script uji cepat
file konfigurasi lokal
Enter fullscreen mode Exit fullscreen mode

Pola ini sejalan dengan insiden lain yang kami bahas di pelajaran keamanan API dari pelanggaran Vercel dan panduan keamanan supply chain npm.

Pertanyaan praktisnya: jika ekstensi berbahaya berjalan di editor Anda sekarang, file apa saja yang bisa ia baca?

Kunci Hardcoded dan File .env yang Ter-commit Adalah Risiko Jangka Panjang

Sebagian besar kebocoran kredensial tidak canggih. Biasanya dimulai dari hal kecil:

  • kunci ditempel ke kode “sementara”,
  • file .env ikut ter-commit,
  • token tersimpan di script lokal,
  • credential test berubah menjadi credential production.

Contoh buruk:

import requests

# Quick test of the payments endpoint
STRIPE_KEY = "sk_live_51Qk2mNExampleKeyDoNotShipThis"

response = requests.post(
    "https://api.stripe.com/v1/charges",
    auth=(STRIPE_KEY, ""),
    data={"amount": 2000, "currency": "usd", "source": "tok_visa"},
)

print(response.json())
Enter fullscreen mode Exit fullscreen mode

Masalahnya bukan hanya baris itu terlihat buruk. Masalahnya:

  1. Kunci ada di file yang bisa dibaca ekstensi lokal.
  2. Jika file di-commit, kunci masuk ke riwayat Git.
  3. Menghapus baris tersebut di commit berikutnya tidak menghapusnya dari history.

File .env sering dianggap solusi:

# .env  (loaded at runtime, never meant to ship)
DATABASE_URL=postgres://app_user:Zk7%2BqN9wLx@db.internal:5432/payments
STRIPE_SECRET_KEY=sk_live_51Qk2mNExampleKeyDoNotShipThis
OPENAI_API_KEY=sk-proj-aB3dEf9hKlMnOpQrStUvWxYz1234567890
AWS_ACCESS_KEY_ID=AKIA4EXAMPLE7QRSTUVW
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
JWT_SIGNING_SECRET=8f2a91c4e7b6d3508f2a91c4e7b6d350
Enter fullscreen mode Exit fullscreen mode

Ini lebih baik daripada hardcoding, tetapi belum menyelesaikan semua masalah. File .env tetap:

  • berada di workspace,
  • berbentuk teks biasa,
  • dapat dibaca proses lokal,
  • mudah ter-commit jika workflow tidak disiplin.

Ekstensi berbahaya tidak peduli apakah rahasia ada di app.py atau .env. Keduanya tetap file.

Untuk pembahasan terkait risiko repo, lihat juga dokumentasi API dan keamanan repositori Git.

.gitignore Bukan Kontrol Keamanan

Menambahkan .env ke .gitignore itu perlu, tetapi jangan anggap sebagai perlindungan penuh.

.gitignore hanya memberi tahu Git agar melewati file tidak terlacak ketika Anda menjalankan git add. Ia tidak:

  • menghapus file yang sudah pernah di-commit,
  • melindungi file dari ekstensi lokal,
  • mencegah git add -f .env,
  • mencegah kesalahan lewat UI source control editor.

Contoh audit cepat:

# Lihat apakah .env pernah disentuh di history
git log --all --full-history --oneline -- .env

# Cari pola rahasia di history .env
git log -p --all -- .env | grep -iE "key|secret|token|password"
Enter fullscreen mode Exit fullscreen mode

Jika perintah tersebut menemukan nilai sensitif, perlakukan kredensial sebagai bocor.

Langkah perbaikan:

# 1. Rotasi kredensial di provider terkait terlebih dahulu.
# 2. Hapus file dari tracking Git saat ini.
git rm --cached .env
git commit -m "Remove .env from repository"

# 3. Bersihkan history dengan tool seperti git filter-repo.
# Contoh umum:
git filter-repo --path .env --invert-paths
Enter fullscreen mode Exit fullscreen mode

Setelah history dibersihkan, koordinasikan force-push dengan tim. Namun ingat: membersihkan Git history tidak membatalkan kredensial yang sudah bocor. Rotasi tetap wajib.

Empat Kebiasaan untuk Mengecilkan Dampak Kebocoran

Anda tidak bisa menjamin kredensial tidak pernah bocor. Yang bisa Anda lakukan adalah membuat kredensial yang bocor sulit dipakai dan berdampak kecil.

1. Batasi Kunci per Lingkungan

Jangan gunakan satu kunci API untuk semua lingkungan.

Gunakan pola seperti ini:

dev        -> kunci sandbox, data palsu
staging    -> kunci staging, mode test
production -> kunci produksi, akses minimal
Enter fullscreen mode Exit fullscreen mode

Jika kunci dev bocor, penyerang hanya mencapai sandbox. Itu jauh lebih baik daripada kunci yang sama membuka produksi.

2. Pisahkan Lingkungan Secara Nyata

Pemisahan lingkungan bukan hanya mengganti nilai variabel. Pastikan lingkungan benar-benar tidak saling menjangkau.

Checklist:

  • Database dev bukan read replica dari production.
  • Payment staging memakai test mode provider.
  • Kunci dev tidak bisa mengakses data production.
  • Konfigurasi lokal tidak bisa diarahkan ke production hanya dengan mengganti satu variabel.
  • Production secret tidak perlu ada di laptop developer.

Jika pemisahan ini benar, Anda bisa menjawab cepat: “kunci ini milik lingkungan apa, dan apa dampaknya jika bocor?”

3. Gunakan Hak Akses Paling Rendah dan Masa Hidup Pendek

Dua hal menentukan dampak kunci yang dicuri:

Hak akses

Kunci harus hanya memiliki izin yang dibutuhkan.

Contoh:

Frontend catalog build:
- read product catalog
- no write access
- no billing access
- no admin access
Enter fullscreen mode Exit fullscreen mode

Jangan gunakan kunci admin untuk workflow yang hanya butuh read-only.

Jika Anda sedang memilih model autentikasi, lihat perbandingan kunci API versus OAuth.

Masa hidup

Kunci yang kedaluwarsa dalam satu jam jauh lebih aman daripada kunci statis yang aktif selamanya.

Prioritaskan:

  • token short-lived,
  • kredensial yang diterbitkan on demand,
  • expiry wajib untuk kunci jangka panjang,
  • rotasi otomatis jika memungkinkan.

4. Rotasi Sesuai Jadwal

Jangan menunggu insiden untuk belajar cara rotasi.

Buat jadwal:

Kunci produksi high-privilege  -> bulanan
Kunci production low-risk      -> triwulanan
Kunci dev/staging              -> sesuai kebutuhan dan risiko
Enter fullscreen mode Exit fullscreen mode

Rotasi rutin membantu karena:

  • membatasi masa hidup kredensial yang bocor tanpa terdeteksi,
  • membuat proses rotasi menjadi latihan biasa,
  • mengurangi kepanikan saat insiden nyata terjadi.

Untuk referensi tambahan, lihat alat manajemen kunci API.

Simpan Kredensial di Variabel Lingkungan Apidog, Bukan di Workspace

Apidog juga menyediakan ekstensi VS Code dan server MCP. Jadi argumennya bukan “alat client-side pasti kebal”. Tidak ada alat lokal yang kebal dari risiko supply chain.

Poin utamanya adalah tempat Anda menyimpan rahasia.

Jika Anda membangun dan menguji API setiap hari, Anda biasanya membutuhkan:

  • bearer token,
  • API key,
  • database connection string,
  • environment-specific base URL.

Cara default yang sering terjadi adalah menaruh semua itu ke .env atau script lokal. Itu membuat kredensial aktif tersedia sebagai teks biasa di workspace.

Apidog mengurangi paparan ini dengan menyimpan kredensial sebagai variabel lingkungan.

Gunakan Variabel Lingkungan, Bukan Teks Biasa

Di Apidog, request dapat merujuk variabel dengan sintaks seperti:

Authorization: Bearer {{access_token}}
Enter fullscreen mode Exit fullscreen mode

Bukan:

Authorization: Bearer sk-proj-aB3dEf9hKlMnOpQrStUvWxYz1234567890
Enter fullscreen mode Exit fullscreen mode

Dokumentasi terkait: variabel lingkungan di Apidog.

Manfaat praktisnya:

  • request tetap bisa dibagikan tanpa membagikan nilai rahasia,
  • token tidak hardcoded di definisi request,
  • kredensial tidak perlu disimpan di .env proyek API,
  • struktur variabel tetap jelas untuk tim.

Pakai Nilai Lokal untuk Token dan Password

Apidog membedakan nilai variabel yang dibagikan dan nilai lokal.

Gunakan nilai lokal untuk data sensitif seperti:

access_token
refresh_token
db_password
payment_api_key
admin_api_key
Enter fullscreen mode Exit fullscreen mode

Efeknya:

  • nama variabel bisa terlihat oleh tim,
  • nilai rahasia tetap di mesin masing-masing developer,
  • token pribadi tidak ikut tersinkronisasi ke proyek,
  • tidak ada file bersama berisi credential aktif.

Contoh struktur:

Variable name: access_token
Shared value:  <kosong atau placeholder>
Local value:   token milik developer lokal
Enter fullscreen mode Exit fullscreen mode

Dengan pola ini, rekan tim tahu bahwa request membutuhkan {{access_token}}, tetapi tidak menerima token Anda.

Pisahkan Environment di Apidog

Manajemen lingkungan Apidog dirancang untuk memisahkan konfigurasi per environment.

Contoh:

Development
- base_url = https://api-dev.example.com
- payment_api_key = sandbox key

Staging
- base_url = https://api-staging.example.com
- payment_api_key = staging test key

Production
- base_url = https://api.example.com
- payment_api_key = production key
Enter fullscreen mode Exit fullscreen mode

Request tetap sama:

POST {{base_url}}/payments
Authorization: Bearer {{access_token}}
X-API-Key: {{payment_api_key}}
Enter fullscreen mode Exit fullscreen mode

Yang berubah hanya environment aktif.

Keuntungannya:

  • tidak perlu edit manual URL dan token,
  • risiko salah pakai kunci production berkurang,
  • kunci development tidak tertukar dengan production,
  • credential production tidak perlu ada di environment lokal developer.

Untuk Batasan Lebih Ketat: Vault Secret

Jika tim Anda tidak ingin secret production menyentuh API client sama sekali, paket Enterprise Apidog menyediakan fitur Rahasia Vault.

Fitur ini mengambil secret dari:

  • HashiCorp Vault,
  • Azure Key Vault,
  • AWS Secrets Manager.

Apidog menyimpan path vault dan metadata. Nilai secret sebenarnya ditarik sesuai kebutuhan, dienkripsi di client lokal, dan tidak dibagikan ke rekan tim lewat proyek.

Ini cocok untuk secret production yang seharusnya tetap berada di secret manager khusus.

Langkah Praktis Memindahkan Kredensial ke Apidog

  1. Unduh Apidog.
  2. Buat atau buka proyek API.
  3. Buka Environment Management.
  4. Buat environment: Development, Staging, Production.
  5. Tambahkan variabel seperti:
    • base_url
    • access_token
    • payment_api_key
    • db_password
  6. Masukkan secret sebagai nilai lokal, bukan nilai bersama.
  7. Ubah request agar memakai {{variable_name}}.
  8. Hapus secret dari .env, script, atau request hardcoded.
  9. Rotasi credential lama yang pernah berada di file teks biasa.

Catatan penting: memindahkan rahasia ke Apidog mengurangi jumlah credential teks biasa di repo dan workspace. Ini tidak membuat laptop Anda kebal. Tetap audit ekstensi, gunakan least privilege, pakai token short-lived, dan rotasi sesuai jadwal.

Audit Cepat untuk Repo Anda

Jalankan audit sederhana ini di repo yang paling sering Anda pakai.

Cari pola rahasia:

grep -RniE "api[_-]?key|secret|token|password|bearer|private_key" .
Enter fullscreen mode Exit fullscreen mode

Abaikan direktori umum:

grep -RniE "api[_-]?key|secret|token|password|bearer|private_key" . \
  --exclude-dir=node_modules \
  --exclude-dir=.git \
  --exclude-dir=dist \
  --exclude-dir=build
Enter fullscreen mode Exit fullscreen mode

Cek apakah .env pernah masuk history:

git log --all --full-history --oneline -- .env
Enter fullscreen mode Exit fullscreen mode

Cari rahasia di seluruh history:

git grep -n -i -E "api[_-]?key|secret|token|password" $(git rev-list --all)
Enter fullscreen mode Exit fullscreen mode

Jika menemukan credential:

  1. Rotasi segera.
  2. Cabut credential lama.
  3. Bersihkan history jika perlu.
  4. Pindahkan nilai aktif ke secret manager atau variabel lingkungan Apidog.
  5. Tambahkan scanning secret ke CI jika tersedia.

Kesimpulan

Pembobolan GitHub menunjukkan pola yang makin umum: penyerang menargetkan mesin developer karena di sana ada alat tepercaya, file konfigurasi, dan credential teks biasa.

Mulai dari audit kecil:

  • cari key, secret, token, dan password,
  • cek apakah .env pernah masuk Git history,
  • rotasi semua credential yang pernah terekspos,
  • pisahkan kunci per environment,
  • pindahkan credential aktif dari file teks biasa.

Jika Anda menguji API setiap hari, Unduh Apidog dan simpan credential API sebagai variabel lingkungan dengan nilai lokal, bukan di .env atau script lokal.

Untuk bacaan lanjutan, lihat alat API yang di-host sendiri setelah pembobolan GitHub dan alat manajemen kunci API.

FAQ

Bisakah Ekstensi VS Code Membaca File .env dan Kunci API Saya?

Ya. Ekstensi VS Code berjalan dengan izin akun user Anda. Ia dapat membaca file di workspace, termasuk .env, file konfigurasi, dan credential lokal seperti ~/.aws/credentials.

Itu perilaku normal untuk banyak ekstensi. Risikonya adalah ekstensi berbahaya memakai akses yang sama untuk mengumpulkan secret.

Apakah .gitignore Cukup untuk Melindungi Kunci API?

Tidak. .gitignore hanya mencegah file tidak terlacak ikut masuk saat git add. Ia tidak:

  • menghapus file yang sudah pernah di-commit,
  • melindungi file dari proses lokal,
  • mencegah git add -f,
  • menghapus secret dari Git history.

Gunakan .gitignore, tetapi jangan anggap sebagai kontrol keamanan.

Apa yang Harus Dilakukan Jika Kunci API Ada di Git History?

Anggap kunci tersebut sudah bocor.

Urutan aman:

  1. Rotasi atau cabut kunci di provider.
  2. Ganti dengan credential baru.
  3. Hapus file dari repo.
  4. Bersihkan history dengan tool seperti git filter-repo.
  5. Koordinasikan force-push dengan tim.
  6. Pindahkan credential aktif ke secret manager atau variabel lingkungan yang aman.

Bagaimana Apidog Mengurangi Paparan Kunci API?

Apidog memungkinkan Anda menyimpan credential sebagai variabel lingkungan dan merujuknya di request, misalnya {{access_token}}.

Dengan nilai lokal, secret tetap berada di mesin developer dan tidak disinkronkan ke tim. Variabel per environment juga membantu memisahkan credential development, staging, dan production.

Ini mengurangi jumlah secret aktif yang tersebar sebagai teks biasa di repo dan workspace.

Apakah Apidog Juga Memiliki Ekstensi VS Code?

Ya. Apidog menyediakan ekstensi VS Code dan server MCP. Inti artikel ini bukan bahwa alat client-side kebal. Tidak ada alat lokal yang sepenuhnya kebal.

Poinnya adalah mengurangi paparan credential. Menyimpan secret sebagai variabel lingkungan lokal atau melalui vault membuat lebih sedikit kunci teks biasa tersedia di workspace jika ada alat lokal yang disusupi.

Apa Perbedaan Pembatasan Cakupan dan Rotasi?

Pembatasan cakupan membatasi apa yang bisa dilakukan kunci.

Contoh:

Kunci dev hanya untuk sandbox.
Kunci read-only tidak bisa menulis.
Kunci billing tidak bisa mengelola user.
Enter fullscreen mode Exit fullscreen mode

Rotasi mengganti nilai kunci agar nilai lama berhenti berfungsi.

Keduanya dibutuhkan. Scope mengurangi dampak, rotasi mengurangi durasi risiko.

Seberapa Sering Kunci API Harus Dirotasi?

Gunakan jadwal tetap.

Rekomendasi umum:

Production high-privilege -> bulanan
Low-risk credentials      -> triwulanan
Dev/staging credentials   -> sesuai risiko
Enter fullscreen mode Exit fullscreen mode

Sesuaikan dengan kebutuhan compliance dan toleransi risiko tim Anda.

Haruskah Kunci Production Ada di Laptop Developer?

Idealnya tidak.

Kunci production sebaiknya hanya ada di:

  • secret manager,
  • runtime production,
  • sistem deployment yang membutuhkan.

Developer sebaiknya memakai credential development atau staging dengan data non-production. Jika laptop bocor, penyerang hanya mencapai sandbox, bukan sistem pelanggan nyata.

Top comments (0)