ข้ามไปยังเนื้อหาหลัก

ความมั่นคงปลอดภัย

Rosetta ได้รับการออกแบบมาให้มีความปลอดภัยในสภาพแวดล้อมที่ไม่เป็นมิตร — ซึ่งข้อมูล locale อาจมาจากแหล่งที่ไม่น่าเชื่อถือ, การสร้างชื่อไฟล์ที่อาจหลุดรอดออกจากขอบเขตของไดเรกทอรี, และผลลัพธ์จาก LLM ที่อาจมีเนื้อหาใดๆ ก็ได้

แบบจำลองภัยคุกคาม​

ภัยคุกคามช่องทางการโจมตีการบรรเทาผลกระทบ
Prototype pollutionคีย์ JSON ที่ถูกสร้างขึ้นมา (__proto__, constructor)ปฏิเสธตั้งแต่ขั้นตอนการแยกวิเคราะห์ (Parse)
Path traversalรหัส Locale เช่น ../../etc/passwdตรวจสอบการเขียนไฟล์ให้อยู่ในไดเรกทอรีที่กำหนดค่าไว้
Code block corruptionLLM แปลเนื้อหาภายใน code fencesป้องกันด้วย Unicode sentinel
Hallucinated keysLLM ส่งคืนคีย์ที่ไม่ได้ส่งไปการตรวจสอบการตอบกลับ — เขียนเฉพาะคีย์ที่ยอมรับเท่านั้น
Runaway token spendการวนลูปลองใหม่ (Retry) แบบไม่สิ้นสุดจำกัดงบประมาณผ่าน maxRetries

การป้องกัน Prototype Pollution​

คีย์ locale ทั้งหมดจะถูกตรวจสอบกับ blocklist ก่อนการประมวลผล:

  • __proto__
  • constructor
  • prototype

คีย์ใดๆ ที่ตรงกับรูปแบบเหล่านี้จะถูกปฏิเสธและแสดงข้อผิดพลาด สิ่งนี้ช่วยป้องกันไม่ให้ผู้โจมตีใช้ไฟล์ locale ที่สร้างขึ้นมาเพื่อแก้ไข JavaScript object prototypes

การควบคุม Path​

เมื่อเขียนไฟล์ locale, rosetta จะตรวจสอบว่า path ของผลลัพธ์ยังคงอยู่ภายในไดเรกทอรีที่กำหนดค่าไว้ (localesDir, contentDir) รหัส locale จะถูกทำความสะอาด (Sanitize) — รหัสเช่น ../../secrets จะไม่สามารถเขียนออกนอกไดเรกทอรีที่คาดหวังได้

การป้องกัน Block​

ในระหว่างการแปลเนื้อหา Markdown องค์ประกอบที่มีโครงสร้างจะถูกแทนที่ด้วย Unicode sentinel placeholders ก่อนที่ข้อความจะถูกส่งไปยัง LLM:

  1. Code blocks (แบบ fenced และ inline) → sentinel
  2. Hugo shortcodes ({{< >}}, {{% %}}) → sentinel
  3. Raw HTML → sentinel
  4. Interpolation variables ({{ .Count }}) → sentinel

หลังจากการแปล sentinels จะถูกแทนที่กลับด้วยเนื้อหาต้นฉบับ LLM จะไม่เห็น code blocks, shortcodes หรือ HTML เลย — จึงไม่สามารถทำให้ข้อมูลเหล่านี้เสียหายได้

การตรวจสอบการตอบกลับ (Response Validation)​

เมื่อ LLM ส่งคืนการตอบกลับแบบ JSON, rosetta จะตรวจสอบว่า:

  • มีเฉพาะคีย์ที่ถูกส่งไปในชุดข้อมูล (Batch) เท่านั้นที่ปรากฏในการตอบกลับ
  • ไม่มีคีย์ส่วนเกินถูกแทรกเข้ามา
  • การตอบกลับสามารถแยกวิเคราะห์ (Parse) เป็น JSON ที่ถูกต้องได้

คีย์ที่เกิดจากอาการ Hallucinate จะถูกละทิ้งไปอย่างเงียบๆ สิ่งนี้ช่วยป้องกันไม่ให้ผลลัพธ์จาก LLM แทรกคำแปลที่ไม่คาดคิดลงในไฟล์ locale ของคุณ

Quality Gate​

ทุกคำแปลจะถูกตรวจสอบผ่านการตรวจสอบแบบกำหนดได้ (Deterministic checks) 5 ขั้นตอนก่อนที่จะถูกเขียนลงดิสก์ ดูรายละเอียดเพิ่มเติมได้ที่ Quality Gate

Exponential Backoff​

การเรียก API ใช้ exponential backoff พร้อม jitter เมื่อได้รับการตอบกลับแบบ 429 (rate limit) และ 5xx (server error) การลองใหม่ 3 ครั้งพร้อมระยะเวลาหน่วงที่เพิ่มขึ้นช่วยป้องกันการกระหน่ำเรียก API ในช่วงที่ระบบขัดข้อง

Request Timeout​

ทุกคำขอ API มีการกำหนดเวลาหมดอายุ (Timeout) ที่ 30 วินาทีผ่าน AbortController สิ่งนี้ช่วยป้องกันไม่ให้กระบวนการซิงค์ค้างอย่างไม่มีกำหนดเมื่อการเชื่อมต่อขาดหาย

การแจ้งเตือนข้อผิดพลาดการแปลแบบ Fail-Loud​

เมื่อ API ไม่พร้อมใช้งานหรือการแปลล้มเหลว rosetta จะแสดงข้อผิดพลาดอย่างชัดเจนพร้อมคำแนะนำที่สามารถนำไปปฏิบัติได้ แทนที่จะเขียนข้อมูลขยะลงไปอย่างเงียบๆ จะไม่มีการเขียน placeholders ที่นำหน้าด้วย [EN] ในระหว่างการซิงค์อย่างเด็ดขาด

[ERR] Content sync for fr: no API key available.
  Set OPENROUTER_API_KEY in .env.local to translate content.

ความล้มเหลวของไฟล์ใดไฟล์หนึ่งจะไม่หยุดการซิงค์ทั้งหมด — ข้อผิดพลาดจะถูกบันทึกไว้และไปป์ไลน์จะดำเนินการต่อไปยังไฟล์ถัดไป เพื่อให้คุณได้รับความคืบหน้าสูงสุดในการรันแต่ละครั้ง

การตรวจสอบหลังการซิงค์ (Post-Sync Verification)​

หลังจากการแปลทั้งหมดเสร็จสิ้น rosetta จะอ่านไฟล์ locale ที่เขียนลงดิสก์อีกครั้งและดำเนินการตรวจสอบ สิ่งนี้ช่วยตรวจจับช่องโหว่ระหว่างการรายงานผลการซิงค์ว่าสำเร็จกับคำแปลที่ผิดพลาดในความเป็นจริง:

  • Key parity — คีย์ต้นทางทั้งหมดต้องมีอยู่ในแต่ละเป้าหมาย
  • เครื่องหมาย [EN] — เครื่องหมาย fallback แบบเก่าจากการรันครั้งก่อนหน้า
  • คำแปลว่างเปล่า — ค่าว่างที่หลุดรอดไปได้
  • ความสอดคล้องของสคริปต์ (Script compliance) — locale ที่ไม่ใช่ภาษาละตินแต่มีคำแปลที่เป็น ASCII เท่านั้น
  • การคงรักษา Placeholder — ICU placeholders ต้องตรงกับต้นทาง

ข้ามขั้นตอนนี้ด้วย --no-verify หรือรันแบบสแตนด์อโลนด้วย npx i18n-rosetta verify

การทดสอบ​

คุณสมบัติด้านความปลอดภัยได้รับการตรวจสอบโดยชุดทดสอบแบบไม่เป็นมิตร (Adversarial test suite):

npm run test:redteam    # prototype pollution, path traversal, encoding attacks

ดูเพิ่มเติม​