Thanawat Wongchai

Posted on May 21 • Originally published at apidog.com

วิธีป้องกัน API Keys จาก Extension VS Code อันตราย

เมื่อวันที่ 20 พฤษภาคม 2026 GitHub ยืนยันว่าผู้โจมตีขโมยข้อมูลจาก repository ภายในประมาณ 3,800 แห่ง จุดเริ่มต้นไม่ใช่ Zero-day บนเซิร์ฟเวอร์ GitHub แต่เป็นส่วนขยาย VS Code ที่ถูกฝังมัลแวร์และติดตั้งบนแล็ปท็อปของพนักงานหนึ่งคน เมื่อส่วนขยายรันด้วยสิทธิ์ไฟล์เดียวกับนักพัฒนา มันสามารถอ่านซอร์สโค้ด ไฟล์ config และข้อมูลรับรองใน workspace ได้ทั้งหมด บทเรียนสำคัญคือ API keys มักไม่ได้รั่วจากคลาวด์ก่อน แต่รั่วจากเครื่องนักพัฒนาและเครื่องมือที่รันอยู่บนนั้น

ลองใช้ Apidog วันนี้

สรุป

ถ้าต้องการลดความเสี่ยงจากส่วนขยาย IDE ที่ถูกบุกรุกหรือ repository ที่รั่วไหล ให้เริ่มจากหลักการนี้:

อย่าเก็บข้อมูลรับรอง production ในซอร์สโค้ด
อย่า commit ไฟล์ .env
อย่าคิดว่า .gitignore คือ security boundary
แยก key ตาม environment: development, staging, production
ใช้ key ที่มีสิทธิ์น้อยที่สุด
ใช้ token อายุสั้นเมื่อทำได้
หมุนเวียน key ตามรอบ ไม่ใช่เฉพาะตอนเกิด incident
เก็บข้อมูลรับรอง API ในระบบจัดการ environment เช่น Apidog แทนการกระจายเป็นไฟล์ข้อความธรรมดาใน repo

เครื่องมืออย่าง Apidog ช่วยลดการวาง API credentials ไว้ใน workspace โดยให้เก็บค่าไว้ใน environment variables และ local-only values แทนไฟล์ .env ที่เครื่องมือใด ๆ บนเครื่องสามารถอ่านได้

ทำไมการละเมิดของ GitHub จึงเป็นสัญญาณเตือนสำหรับนักพัฒนาทุกคน

เหตุการณ์ของ GitHub เป็นตัวอย่าง supply-chain attack ที่กระทบ developer workstation โดยตรง กลุ่มภัยคุกคาม TeamPCP มีประวัติฝังโทรจันใน package หลาย ecosystem เช่น npm, PyPI และ PHP ครั้งนี้ payload มากับส่วนขยาย VS Code ตามรายงานของ TechCrunch ผู้โจมตีขโมยข้อมูลจาก repository ภายในประมาณ 3,800 แห่ง และนำชุดข้อมูลไปขายในฟอรัมใต้ดิน GitHub ระบุว่าไม่มีหลักฐานว่าข้อมูลลูกค้านอก repository ภายในเหล่านั้นได้รับผลกระทบ และการสอบสวนยังดำเนินอยู่

สิ่งที่นักพัฒนาควรเข้าใจคือ VS Code extension คือโค้ดที่รันใน editor process ด้วยสิทธิ์ของผู้ใช้ปัจจุบัน มันสามารถ:

list directory
เปิดและอ่านไฟล์
watch file changes
ส่ง network request ออกไปภายนอก

สิ่งเหล่านี้ไม่ใช่ bug แต่เป็นพฤติกรรมปกติของ extension หลายตัว ปัญหาเกิดเมื่อ extension นั้นเป็นมัลแวร์หรือถูกบุกรุก แล้วใช้สิทธิ์เดิมเพื่อขโมยข้อมูลรับรอง

ไฟล์ที่มักตกเป็นเป้าหมาย ได้แก่:

.env
config/secrets.yml
~/.aws/credentials
.npmrc
SSH private keys
test scripts ที่มี token hardcode
ไฟล์ config ของ cloud provider

นี่คือ pattern เดียวกับแคมเปญ npm worm “Mini Shai-Hulud” ที่เก็บเกี่ยวข้อมูลรับรองของ developer, CI/CD, cloud และ AI tooling จากเครื่องที่ติดมัลแวร์

เราเคยพูดถึง pattern ใกล้เคียงกันในบทเรียนด้านความปลอดภัย API จาก กรณี Vercel ถูกโจมตี และใน คู่มือความปลอดภัยของ npm supply chain

คำถามที่ควรถามตอนนี้คือ:

ถ้ามี extension ที่เป็นอันตรายรันอยู่ใน editor ของคุณวันนี้ มันจะขโมยอะไรได้บ้าง?

คีย์ที่ hardcode และไฟล์ .env ที่ถูก commit เป็นความเสี่ยงระยะยาว

การรั่วไหลของ API key ส่วนใหญ่ไม่ได้ซับซ้อน นักพัฒนามักวาง key ไว้ในโค้ด “ชั่วคราว” แล้วลืม หรือเผลอ commit ไฟล์ .env เข้า repository ทั้งสองกรณีทำให้ secret อยู่ใน repo และอาจอยู่ใน Git history ตลอดไป

ตัวอย่าง hardcoded key:

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())

ปัญหา:

key อยู่ในไฟล์ที่ extension อ่านได้
ถ้า commit แล้ว key จะอยู่ใน Git history
การลบบรรทัดใน commit ถัดไปไม่ได้ลบ key จาก history
ใครก็ตามที่ clone repo หรือสแกน repo อาจเห็นค่าเดิมได้

ไฟล์ .env แก้ปัญหาการ hardcode ได้บางส่วน แต่ไม่ใช่ทั้งหมด:

# .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

.env ดีกว่าการ hardcode เพราะแยก secret ออกจาก source code แต่ยังมีปัญหาใหญ่:

ไฟล์ยังอยู่ใน workspace
เป็น plaintext
process ใด ๆ ที่มีสิทธิ์อ่าน workspace สามารถอ่านได้
extension ที่เป็นอันตรายไม่สนใจว่า secret อยู่ใน app.py หรือ .env

ถ้า .env ถูก commit แล้ว ผลลัพธ์ยิ่งแย่ เพราะ secret จะอยู่ใน shared Git history อาจถูก mirror, clone หรือรั่วพร้อม repository ได้ เราอธิบายมุมนี้เพิ่มเติมในบทความเกี่ยวกับ เอกสาร API และความปลอดภัยของ Git repository

.gitignore ไม่ใช่การควบคุมความปลอดภัย

การเพิ่ม .env ใน .gitignore เป็น hygiene ที่ดี แต่ไม่ใช่ security control

.gitignore ทำแค่นี้:

บอก Git ให้ข้ามไฟล์ที่ยังไม่ได้ถูก track เมื่อรัน git add

ข้อจำกัดสำคัญมี 3 ข้อ

มันไม่ช่วยกับไฟล์ที่ถูก track ไปแล้ว ถ้า .env เคยถูก commit ก่อนเพิ่ม rule Git จะยัง track ไฟล์นั้นต่อไป คุณต้องรัน:

   git rm --cached .env
   git commit -m "Remove .env from tracking"

แต่ secret เดิมยังอยู่ใน commit เก่า

มันไม่ป้องกันการอ่านไฟล์บน disk

.gitignore ไม่มีผลกับ filesystem ไฟล์ .env ยังเป็น plaintext ใน workspace และ extension ที่เป็นอันตรายสามารถอ่านได้โดยตรง
มันถูก bypass ได้ง่าย

คำสั่งนี้ยังบังคับเพิ่มไฟล์ได้:

   git add -f .env

ถ้าต้องการตรวจว่า .env เคยอยู่ใน history หรือไม่ ให้รัน:

# List every commit that ever touched the file
git log --all --full-history --oneline -- .env

# Search secret-like values in history
git log -p --all -- .env | grep -iE "key|secret|token|password"

ถ้าพบ secret ใน history ให้ถือว่าถูกเปิดเผยแล้ว ขั้นตอนที่ควรทำคือ:

rotate key ทันที
ลบ secret ออกจาก history ด้วยเครื่องมือเช่น git filter-repo
force-push หลังประสานงานกับทีม
ย้ายข้อมูลรับรอง production ออกจาก plaintext file

สรุปคือ .gitignore ช่วยลด human error แต่ไม่ใช่ boundary ที่ผู้โจมตีต้องเคารพ

กำหนดขอบเขต, แยก, ลดอายุ, หมุนเวียน

คุณไม่สามารถรับประกันได้ว่า secret จะไม่รั่ว แต่คุณทำให้ secret ที่รั่วมีค่าน้อยลงได้ด้วย 4 แนวทางนี้

1. กำหนดขอบเขต secret ตาม environment

อย่าใช้ API key เดียวกันใน development, staging และ production

ตัวอย่างที่ควรหลีกเลี่ยง:

PAYMENT_API_KEY=ใช้ค่าเดียวกันทุก environment

แนวทางที่ดีกว่า:

development -> sandbox key
staging     -> staging/test key
production  -> production key

ถ้า development key รั่ว ผู้โจมตีควรเข้าถึงได้แค่ sandbox และ test data ไม่ใช่ข้อมูลลูกค้าจริง

2. แยก environment ให้จริง

การแยก environment ไม่ใช่แค่เปลี่ยนค่า key แต่ต้องแยก resource ด้วย เช่น:

development database ต้องไม่ใช่ production replica
staging payment provider ควรอยู่ใน test mode
dev config ไม่ควรเปลี่ยนตัวแปรเดียวแล้วชี้ไป production ได้
production credential ไม่ควรอยู่บน laptop นักพัฒนาโดยไม่จำเป็น

ถ้า environment แยกจริง เมื่อ key รั่ว คุณจะตอบได้ทันทีว่า impact จำกัดอยู่ที่ไหน

3. ใช้ key ที่สิทธิ์น้อยที่สุดและอายุสั้น

ความเสียหายจาก key ที่ถูกขโมยขึ้นกับ 2 ปัจจัย

สิทธิ์

API key ควรมีสิทธิ์แค่งานที่จำเป็น เช่น frontend ที่อ่าน catalog สาธารณะไม่ควรใช้ key ที่เขียนข้อมูลหรือเข้าถึง billing ได้

เลือกใช้:

read-only key เมื่อพอ
scoped token
fine-grained personal access token
OAuth token ที่ scope ชัดเจน

ถ้ากำลังเลือกระหว่าง static key กับ token model ดูเพิ่มเติมได้ในบทความ API keys กับ OAuth

อายุการใช้งาน

token ที่หมดอายุภายใน 1 ชั่วโมงมีค่าน้อยกว่าคีย์ถาวรมาก ถ้าผู้โจมตีได้ข้อมูลไปช้า key อาจใช้ไม่ได้แล้ว

แนวทางที่ควรใช้:

ใช้ short-lived token เมื่อระบบรองรับ
หลีกเลี่ยง key แบบไม่มีวันหมดอายุ
ตั้ง expiration ให้สั้นที่สุดเท่าที่ workflow รับได้

4. หมุนเวียนตามกำหนดเวลา ไม่ใช่เฉพาะตอน panic

การ rotate key คือการเปลี่ยนค่า credential เพื่อให้ค่าเก่าใช้ไม่ได้อีก ทีมจำนวนมากทำเฉพาะหลังเกิด breach ซึ่งเป็นเวลาที่แย่ที่สุดในการค้นพบว่าไม่มี runbook

ตั้ง schedule เช่น:

high-privilege production keys -> รายเดือน
lower-risk keys                -> รายไตรมาส
development keys               -> ตามความเสี่ยงและความสะดวก

ข้อดี:

จำกัดอายุของ secret ที่รั่วแต่ยังไม่ถูกตรวจพบ
ทำให้ทีมคุ้นเคยกับขั้นตอน rotate
incident จริงจะเป็นขั้นตอนที่เคยฝึก ไม่ใช่ chaos

ดูภาพรวมเครื่องมือได้ในบทความ เครื่องมือจัดการ API key

เก็บข้อมูลรับรองไว้ในตัวแปรสภาพแวดล้อมของ Apidog

Apidog มี VS Code extension และ MCP server ของตัวเอง ประเด็นของบทความนี้ไม่ใช่การบอกว่าเครื่องมือฝั่ง client ใดปลอดภัยจาก supply-chain attack ได้ทั้งหมด เพราะไม่มีเครื่องมือใดปลอดภัยแบบสมบูรณ์

ประเด็นคือ:

ลดจำนวน secret แบบ plaintext ที่กระจายอยู่ใน repo และ workspace

ในงาน API development คุณมักต้องใช้ bearer token, API key หรือ database connection string วิธีที่พบบ่อยคือวางค่าเหล่านี้ใน .env หรือ script แต่การทำแบบนั้นทำให้ secret อยู่ในตำแหน่งที่ extension สามารถอ่านได้ง่าย

Apidog ช่วยย้ายค่าเหล่านี้ไปอยู่ใน environment variables ของ API client แทน

ใช้ environment variables แทน plaintext file

ใน Apidog คุณสามารถจัดเก็บข้อมูลรับรองเป็น ตัวแปรสภาพแวดล้อม แล้วอ้างอิงด้วยชื่อใน request

ตัวอย่าง header:

Authorization: Bearer {{access_token}}

แทนที่จะใส่ค่าจริง:

Authorization: Bearer sk-proj-aB3dEf9hKlMnOpQrStUvWxYz1234567890

ผลคือ request definition ไม่มี secret จริงอยู่ในไฟล์ plaintext ข้าง source code

ใช้ local values สำหรับ secret

Apidog แยกค่าของตัวแปรออกเป็น 2 ประเภท:

shared/default value: sync ไปยังเซิร์ฟเวอร์ Apidog และทีมเห็นได้
local/current value: อยู่บนเครื่องของคุณและไม่ถูกอัปโหลด

แนวทางที่ควรใช้:

variable name: access_token
shared value:  ว่าง หรือ placeholder
local value:   token จริงของคุณ

ผลลัพธ์คือทีมสามารถแชร์โครงสร้าง environment ได้ เช่นชื่อตัวแปร access_token, db_password, payment_api_key แต่ไม่แชร์ค่า secret จริงของแต่ละคน

แยก environment ใน Apidog

ฟีเจอร์ จัดการสภาพแวดล้อม ของ Apidog ช่วยแยก Development, Staging และ Production ได้โดยตรง แต่ละ environment มี base URL และค่าตัวแปรของตัวเอง

ตัวอย่าง:

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 key

Production
  base_url = https://api.example.com
  payment_api_key = production key

ใน request ใช้ตัวแปรเดียวกัน:

POST {{base_url}}/payments
Authorization: Bearer {{payment_api_key}}

เมื่อสลับ environment ชุด credential จะเปลี่ยนตาม ไม่ต้องแก้ request เอง และลดโอกาสนำ dev key ไปใช้ผิดที่หรือเก็บ production key ไว้ใน dev workspace

ใช้ Vault Secret สำหรับทีมที่ต้องการขอบเขตแข็งขึ้น

ถ้าทีมต้องการให้ production secret ไม่สัมผัส API client โดยตรง แผน Enterprise ของ Apidog มี Vault Secret ที่เชื่อมกับ:

HashiCorp Vault
Azure Key Vault
AWS Secrets Manager

Apidog จัดเก็บเฉพาะ vault path และ metadata ส่วนค่าจริงถูกดึงจาก secrets manager เมื่อจำเป็น ถูกเข้ารหัสใน local client และไม่ถูกแชร์ผ่าน project ให้เพื่อนร่วมทีม

ถ้าต้องการลอง workflow นี้ ให้ ดาวน์โหลด Apidog สร้าง project เปิด Environment Management แล้วเพิ่ม credential เป็น environment variable พร้อม local-only value

ข้อควรจำ: การย้าย secret เข้า Apidog ช่วยลด plaintext secret ใน repo และ workspace แต่ไม่ได้ทำให้เครื่องปลอดภัยจากเครื่องมือที่ถูกบุกรุกทั้งหมด คุณยังต้องตรวจ extension, จำกัดสิทธิ์ key, ใช้ short-lived token และ rotate ตามกำหนด

Checklist สำหรับเริ่มทำทันที

เปิด repo ที่คุณใช้บ่อยที่สุด แล้วทำตามนี้

# ค้นหา keyword ที่มักเกี่ยวกับ secret
grep -RInE "key|secret|token|password|api_key|apikey" . \
  --exclude-dir=.git \
  --exclude-dir=node_modules

ตรวจว่า .env เคยถูก commit หรือไม่:

git log --all --full-history --oneline -- .env
git log -p --all -- .env | grep -iE "key|secret|token|password"

ถ้าพบ secret:

rotate key ทันที
revoke ค่าเก่า
ล้าง Git history ถ้าจำเป็น
เพิ่ม secret scanning ใน CI
ย้าย production credential ออกจาก plaintext file
แยก key ตาม environment
ตั้งรอบ rotation

ตัวอย่าง pre-commit hook แบบง่ายเพื่อกัน .env:

#!/bin/sh

if git diff --cached --name-only | grep -E '(^|/)\.env$'; then
  echo "Error: .env must not be committed"
  exit 1
fi

เพิ่มใน .git/hooks/pre-commit แล้วทำให้ executable:

chmod +x .git/hooks/pre-commit

สำหรับทีมจริง ควรใช้ secret scanning tool ที่ครอบคลุมกว่า hook แบบง่ายนี้

บทสรุป

การละเมิดของ GitHub เป็นสัญญาณชัดเจนว่า developer workstation เป็นเป้าหมายสำคัญ ผู้โจมตีรู้ว่าเครื่องนักพัฒนามักมี editor extension, config file และ plaintext credential รวมอยู่ในที่เดียว

คุณอาจป้องกันเครื่องจาก supply-chain attack ไม่ได้ 100% แต่คุณทำให้สิ่งที่ผู้โจมตีขโมยไปมีค่าน้อยลงได้:

อย่า hardcode key
อย่า commit .env
อย่าพึ่ง .gitignore เป็น security control
ใช้ key แยกตาม environment
จำกัด scope และสิทธิ์
ใช้ short-lived token
rotate ตาม schedule
เก็บ API credentials ใน environment variables หรือ secrets manager

เริ่มจาก repo ที่ใช้งานจริงวันนี้ ค้นหา key, secret, token, password ตรวจ Git history แล้ว rotate ทุกค่าที่เคยรั่ว จากนั้นย้าย credential ชุดถัดไปไปไว้ในระบบที่เหมาะกว่า plaintext file เช่น ดาวน์โหลด Apidog แล้วใช้ environment variables พร้อม local-only values

อ่านต่อได้ที่ เครื่องมือ API แบบ self-hosted หลังจากการละเมิดของ GitHub และ เครื่องมือจัดการ API key

คำถามที่พบบ่อย

ส่วนขยาย VS Code สามารถอ่านไฟล์ .env และ API key ของฉันได้จริงหรือ?

ได้ ส่วนขยาย VS Code รันด้วยสิทธิ์ของผู้ใช้บนเครื่อง มันสามารถอ่านไฟล์ใน workspace และไฟล์ credential เช่น .env, config file หรือ ~/.aws/credentials ได้ นี่เป็นพฤติกรรมปกติของ extension ที่ต้องทำงานกับไฟล์ ความเสี่ยงคือ extension ที่เป็นอันตรายใช้สิทธิ์เดียวกันเพื่อเก็บเกี่ยว secret

การเพิ่ม .env ไปยัง .gitignore เพียงพอหรือไม่?

ไม่เพียงพอ .gitignore ช่วยกันไฟล์ที่ยังไม่ถูก track ไม่ให้ถูกเพิ่มด้วย git add ตามปกติ แต่ไม่ช่วยกับไฟล์ที่เคย commit แล้ว และไม่ป้องกัน process บนเครื่องจากการอ่านไฟล์ .env ที่ยังอยู่บน disk

ถ้าพบ API key ใน Git history ควรทำอย่างไร?

ให้ถือว่าถูกบุกรุกทันที ขั้นตอนคือ rotate key, revoke ค่าเก่า, ล้าง history ด้วยเครื่องมืออย่าง git filter-repo, ประสานงานกับทีมก่อน force-push และย้าย secret ออกจาก plaintext file อ่านแนวทางต่อได้ใน เครื่องมือจัดการ API key

การเก็บ API key ไว้ใน Apidog ช่วยลดการเปิดเผยข้อมูลอย่างไร?

Apidog ให้เก็บ credential เป็น environment variables และอ้างอิงด้วยชื่อใน request เช่น {{access_token}} แทนการวางค่าจริงใน .env หรือ source code นอกจากนี้ local-only values ช่วยให้ secret อยู่บนเครื่องของผู้ใช้และไม่ sync ไปยังทีม ช่วยลด plaintext secret ที่เครื่องมืออื่นใน workspace อ่านได้

Apidog มีส่วนขยาย VS Code ด้วยหรือไม่ และนั่นเป็นความเสี่ยงหรือไม่?

มี Apidog มี VS Code extension และ MCP server ประเด็นไม่ใช่ว่าเครื่องมือ client ใดปลอดภัยจาก supply-chain attack แบบสมบูรณ์ แต่คือการลดตำแหน่งที่ secret แบบ plaintext ถูกเก็บไว้ คุณยังควรใช้ defense in depth: ตรวจ extension, ใช้ least privilege, ใช้ short-lived token และ rotate key

การกำหนดขอบเขตกับการหมุนเวียน API key ต่างกันอย่างไร?

การกำหนดขอบเขตจำกัดว่า key ทำอะไรได้และใช้ที่ไหน เช่น dev key ใช้ได้เฉพาะ sandbox หรือ read-only key อ่านได้อย่างเดียว ส่วนการหมุนเวียนคือการเปลี่ยนค่า key เพื่อให้ค่าเก่าใช้ไม่ได้ การกำหนดขอบเขตลดความเสียหาย ส่วนการหมุนเวียนลดช่วงเวลาที่ key ที่รั่วใช้งานได้

ควรหมุนเวียน API key บ่อยแค่ไหน?

ควรหมุนเวียนตาม schedule เช่น production key ที่มีสิทธิ์สูงรายเดือน และ key ความเสี่ยงต่ำกว่ารายไตรมาส ปรับตามความเสี่ยงและ compliance ของทีม อย่ารอให้เกิด incident ก่อนค่อย rotate

API key สำหรับ production ควรอยู่ในแล็ปท็อปของนักพัฒนาหรือไม่?

โดยทั่วไปไม่ควร Production credential ควรอยู่ใน secrets manager และ production runtime เท่านั้น นักพัฒนาควรใช้ development หรือ staging credential ที่ scope จำกัด หาก laptop ถูกบุกรุก ผู้โจมตีควรเข้าถึงได้แค่ sandbox ไม่ใช่ production system.

DEV Community