ข้อกล่าวอ้างที่ตรวจสอบได้

รหัสผ่านจำเป็นเฉพาะเพื่อเปิดการเชื่อมต่อ SSH ครั้งแรกและติดตั้งผู้ใช้เชิงบริการเท่านั้น มันถูกส่งผ่านเป็นการยืนยันตัวตน SSH สำหรับการเชื่อมต่อของเรา — ไม่ใช่ในฐานะอาร์กิวเมนต์ของสคริปต์หรือตัวแปรสภาพแวดล้อม ฐานข้อมูลของเราไม่มีฟิลด์สำหรับมัน มันไม่เข้าไปในสภาพแวดล้อมการรันสคริปต์ และไม่ถูกเขียนลงในบันทึก (ข้อผิดพลาดการเชื่อมต่อมีเพียงที่อยู่และพอร์ตเท่านั้น ไม่มีรหัสผ่าน) ในหน่วยความจำ มันถูกล้าง (best-effort) หลังการใช้งาน — นั่นคือการป้องกันเชิงลึก ไม่ใช่การรับประกัน: Go อาจเก็บสำเนาของค่าไว้บน heap จนกว่าจะมีการเก็บขยะ (garbage collection)

ข้อแม้ตามตรง: มันยังคงเป็นรหัสผ่าน root บนเซิร์ฟเวอร์ของคุณ หลังการติดตั้ง เราปิดการล็อกอินด้วยรหัสผ่านและการล็อกอินแบบ root ผ่าน SSH แต่เราไม่เปลี่ยนตัวรหัสผ่านเอง — เปลี่ยนมันด้วยตัวคุณเองหากต้องการ 'เราไม่จัดเก็บมัน' เป็นความจริง แต่ 'มันเลิกเป็นความลับแล้ว' ไม่ใช่

PasswordAuthentication no, PermitRootLogin no, SSH ถูกย้ายไปยังพอร์ตที่ไม่ใช่มาตรฐาน (12011 โดยค่าเริ่มต้น), เปิดใช้งาน fail2ban (แบนหนึ่งชั่วโมงหลังล้มเหลว 5 ครั้ง), ล็อกอินด้วยคีย์เท่านั้น คีย์สาธารณะถูกตรวจสอบอย่างเข้มงวดก่อนใช้งาน: การขึ้นบรรทัดใหม่ (ป้องกันการแอบใส่คีย์เพิ่มเข้าไปใน authorized_keys) และคีย์ที่มีไวยากรณ์ไม่ถูกต้องจะถูกปฏิเสธ

ป้องกันการล็อกตัวเองออก: พอร์ต 22 จะไม่ถูกปิดจนกว่าเคอร์เนลจะยืนยัน (ผ่าน ss) ว่าพอร์ต SSH ใหม่กำลังรับฟังอยู่จริง; การตั้งค่าถูกตรวจสอบด้วย sshd -t และกฎ sudo ด้วย visudo -cf ทั้งคู่จะถูกย้อนกลับหากเกิดข้อผิดพลาด

แผงควบคุมไม่ได้ทำงานด้วยรหัสผ่านของคุณ แต่ด้วยคีย์แยกต่างหาก (ed25519) ที่มันสร้างขึ้นเอง ส่วนคีย์ส่วนตัวอยู่ในฐานข้อมูลโดยเข้ารหัสด้วย AES-256-GCM คีย์เข้ารหัส (KEK) ถูกจัดเก็บแยกจากฐานข้อมูล — ในตัวแปรสภาพแวดล้อมของเซิร์ฟเวอร์ — และในระบบโปรดักชันมันเป็นสิ่งบังคับ (ไม่มีค่าเริ่มต้นที่ไม่ปลอดภัย: หากไม่มี KEK ระบบย่อยการเข้ารหัสจะไม่เริ่มทำงานเลย) การเข้ารหัสเดียวกันนี้ปกป้องความลับหนัก ๆ ในฐานข้อมูล — รหัสผ่าน/โทเคน/JWT ของแอดมิน Marzban, คีย์ Reality, คีย์ของผู้ให้บริการชำระเงิน, แคชข้อมูลรับรองพร็อกซี, การตั้งค่าสำรองข้อมูล

การเข้ารหัสไม่เพียงซ่อนแต่ยังยืนยันความถูกต้องของข้อมูล (GCM auth tag): การแก้ไขฟิลด์ที่เข้ารหัสจะถูกตรวจพบตอนถอดรหัสและถูกปฏิเสธ ทุกฟิลด์ถูกเข้ารหัสด้วย nonce สุ่มค่าใหม่ ค่า KEK ไม่เคยไปถึงบันทึก — มีเพียง id สั้น ๆ ของมันเท่านั้น

เกี่ยวกับ capability token: โทเคนการสมัครสมาชิก /sub เป็น bearer secret สำหรับการค้นหาเราเก็บเพียง SHA-256 ของมันเท่านั้น ส่วนสำเนาที่จำเป็นสำหรับการแสดงลิงก์ที่ออกไปแล้วอีกครั้งจะถูกเก็บเป็น ciphertext แบบ AES-GCM ระเบียนแบบ plaintext ที่เก่ากว่าจะถูกย้ายไปยังรูปแบบใหม่แบบ fail-closed ก่อนที่เซิร์ฟเวอร์ HTTP จะเริ่มทำงาน ตัวระบุ URL ของ payment-webhook ถูกเก็บแบบไม่เข้ารหัส แต่ตัวมันเองไม่ได้ยืนยันความถูกต้องของเหตุการณ์: ความถูกต้องถูกตรวจสอบแยกต่างหากด้วยลายเซ็น HMAC

คีย์ถูกถอดรหัสเฉพาะบนเซิร์ฟเวอร์ ในหน่วยความจำเท่านั้น; API ทั่วไปไม่เคยส่งคืนมัน วิธีเดียวที่จะได้มันมาคือฟังก์ชันส่งออกที่ตั้งใจ ('เอาคีย์ของคุณ') ซึ่งได้รับการปกป้องด้วยการลงชื่อเข้าใช้บวกกับรหัสอีเมลแบบใช้ครั้งเดียว (รหัสถูกเก็บเป็นแฮช HMAC เท่านั้น เปรียบเทียบแบบ constant time, TTL 10 นาที, 5 ครั้ง) ดังนั้นคีย์สามารถถูกดึงออกมาได้อย่างตั้งใจ แต่ไม่สามารถ 'รั่วไหล' ผ่านคำขอปกติได้

ก่อนที่สถานะของเซิร์ฟเวอร์จะเปลี่ยนและก่อนการดำเนินการเครือข่ายเบื้องหลังใด ๆ ฟิลด์ที่เก็บคีย์การจัดการจะถูกตั้งเป็นศูนย์แบบซิงโครนัส หากฐานข้อมูลไม่ยืนยันการล้าง การดำเนินการจะส่งคืนข้อผิดพลาดและสามารถลองใหม่ได้ การลบยังคงเป็นแบบ 'soft': แถวและข้อมูลเชิงบริการที่ไม่เป็นความลับจะถูกเก็บไว้ นี่ไม่ได้หมายถึงการลบข้อมูลสำรองที่สร้างไว้แล้วออกทางกายภาพ — วงจรชีวิตของมันถูกกำกับด้วยนโยบายการเก็บรักษาข้อมูลสำรอง

เส้นทาง (route) ของพาร์ทเนอร์ที่ผ่านการตรวจสอบจะอนุญาตสิทธิ์ด้วย partner_id ซึ่งเซิร์ฟเวอร์ดึงมาจากโทเคนล็อกอินที่มีลายเซ็น — ไม่ใช่จากสิ่งที่ไคลเอนต์ส่งมาในพาธหรือเนื้อหา (body) ก่อนที่จะส่งคืนหรือเปลี่ยนแปลงอะไร ระบบจะตรวจสอบซ้ำว่าเซิร์ฟเวอร์ คลัสเตอร์ inbound เส้นทาง ผู้ใช้ VPN หรือการชำระเงินที่ร้องขอนั้นเป็นของบัญชีคุณ; คำสั่งค้นฐานข้อมูลที่เกี่ยวข้องถูกจำกัดขอบเขตด้วย partner_id ของคุณ และสคีมา (คีย์เฉพาะแบบผสมบวกกับคีย์นอกแบบผสม) จะปฏิเสธการเชื่อมโยงข้ามพาร์ทเนอร์ที่ไม่ถูกต้อง การแยกส่วนเป็นแบบหลายชั้น: แอปพลิเคชัน, การตรวจสอบซ้ำในระดับ usecase, ตัวกรอง partner_id, และสคีมา

ข้อแม้ตามตรง: สิ่งนี้ถูกตรวจสอบด้วยการออดิตโค้ดตลอดเส้นทางคำขอ ไม่ใช่ด้วยการทดสอบเจาะระบบแบบสาธารณะ — ดังนั้น SR-16 เช่นเดียวกับข้ออื่น ๆ เปิดให้หักล้างได้ในโครงการ bug bounty

เพื่อกำหนดค่าทุกอย่างโดยอัตโนมัติ (ติดตั้ง Xray+Reality, ใช้การตั้งค่า, อ่านเมตริก) แผงควบคุมถือสิทธิ์การดูแลระบบเต็มรูปแบบบนเซิร์ฟเวอร์ (เทียบเท่า root ผ่านผู้ใช้เชิงบริการที่มี sudo แบบไม่ต้องใช้รหัสผ่าน) นี่จำเป็นสำหรับการจัดการ และเราไม่เรียกมันว่า 'จำกัด'

สิ่งที่ลดความเสี่ยง: ความลับถูกส่งไปยังเซิร์ฟเวอร์ผ่าน stdin ของโปรเซสเท่านั้น (ไม่ใช่ในฐานะอาร์กิวเมนต์คำสั่ง — จึงไม่ปรากฏในรายการโปรเซส); หลังการติดตั้งครั้งแรก ทุกการเชื่อมต่อเพื่อจัดการจะตรวจสอบ host key ที่ปักหมุด (pinned) ของเซิร์ฟเวอร์ — การสลับเซิร์ฟเวอร์ 'ตรงกลาง' จะถูกปฏิเสธ สิ่งที่คุณควบคุม: การเข้าถึงตั้งอยู่บนคีย์ที่คุณสามารถเพิกถอนได้ทุกเมื่อ — ด้วยการลบเซิร์ฟเวอร์ (คีย์จะถูกตั้งเป็นศูนย์) หรือเพียงลบ VPS ที่ผู้ให้บริการโฮสต์ของคุณ (จากนั้นทุกอย่างจะหายไป)

บัญชี VPN เอง (VLESS/Reality) ถูกสร้างและอยู่ใน Marzban บนเซิร์ฟเวอร์มาสเตอร์ของคุณ ที่ส่วนกลางเราเก็บเพียงสิ่งที่จำเป็นสำหรับการออกลิงก์สมัครสมาชิก: โทเคนสมัครสมาชิกแบบสุ่มและสแนปช็อตข้อมูลรับรองพร็อกซีที่เข้ารหัส (แคช; แหล่งข้อมูลจริงคือ Marzban ของคุณ) เราไม่มีประวัติทราฟฟิก IP หรือการเข้าเว็บของผู้ใช้

นี่คือรายการอย่างตรงไปตรงมาว่าอีเมลของผู้ใช้ปลายทางผ่านฐานข้อมูลกลางของเราจริง ๆ ที่จุดใดบ้าง: อีเมลรหัสเข้าสู่ระบบนั้นเราเป็นผู้ส่ง ดังนั้นที่อยู่จึงผ่านคิวการส่งของเรา (สำหรับการเข้าสู่ระบบหน้าร้านทุกกรณี รวมถึงแบบฟรี); เมื่อชำระเงิน อีเมลของผู้ซื้อจะมาถึงใน webhook การชำระเงินและเข้าสู่บันทึกการชำระเงิน; เมื่อเชื่อม Telegram อีเมลจะถูกบันทึกลงในโปรไฟล์ จุดสัมผัสเหล่านี้เป็นเพียงจุดเดียวเท่านั้น — เป็นเชิงบริการและตามความจำเป็น; ไม่เกี่ยวข้องกับทราฟฟิกหรือพฤติกรรมของผู้ใช้เลย

ข้อมูลบริการเหล่านี้เราเก็บไว้เพียงเท่าที่จำเป็นและล้างทิ้งโดยอัตโนมัติ: อีเมลจะถูกลบออกจากคิวการส่งทันทีหลังการส่ง เนื้อหาของเหตุการณ์การชำระเงินหลังการประมวลผล และเหตุการณ์ที่รอการลองใหม่ภายในช่วงเวลา 90 วัน คุณสามารถลบบัญชีของคุณพร้อมกับข้อมูลที่เกี่ยวข้องได้โดยติดต่อฝ่ายสนับสนุน (ดูรายละเอียดที่ความเสี่ยงข้อ 7) เราเปิดเผยเรื่องนี้อย่างตรงไปตรงมา แทนที่จะซ่อนไว้เบื้องหลังถ้อยคำคลุมเครือ

แพลตฟอร์ม CreateYourVPN ไม่รับหรือจัดเก็บข้อมูลว่าคุณหรือผู้ใช้ของคุณเข้าเว็บไซต์ใดบ้าง สคีมา metrics-ingest เป็นแบบปิด: ในทางกายภาพมันไม่มีฟิลด์สำหรับ IP โดเมน หรือการเข้าเว็บ — มีเพียงค่ารวม (จำนวนออนไลน์ที่ไม่ซ้ำ, จำนวนไบต์รวม, CPU/RAM/โหลด) แต่ละโหนดยืนยันตัวตนด้วยโทเคน HMAC ที่ผูกกับ id ของตัวเองและเขียนเมตริกได้เฉพาะสำหรับตัวเองเท่านั้น ตัวจัดสมดุลบนโหนด (HAProxy) ทำงานเป็นเราเตอร์ TCP ตาม SNI และไม่ถอดรหัสทราฟฟิก บนตัวเซิร์ฟเวอร์เอง system journal ถูกเก็บไว้ไม่เกินประมาณหนึ่งชั่วโมงและไม่ถูกส่งต่อไปยัง syslog

นอกเหนือจากระดับแพลตฟอร์มแล้ว เซิร์ฟเวอร์ก็ไม่ได้เก็บบันทึกการเข้าเว็บเช่นกัน: การบันทึกการเข้าถึงของ Xray ถูกบังคับปิดในทุกครั้งที่ push การตั้งค่า (แพลตฟอร์มตั้งค่า log.access เป็น none) ดังนั้น edge proxy จึงไม่บันทึกว่าผู้ใช้เชื่อมต่อไปยังที่อยู่ใด สิ่งนี้ถูกบังคับใช้ในโค้ดและปล่อยใช้งานทั่วทั้งฟลีตแล้ว

เพื่อทำความเข้าใจว่าเว็บไซต์และแผงควบคุมถูกใช้งานอย่างไร เราใช้ Google Analytics (แบนเนอร์ cookie เตือนเรื่องการเก็บ cookie และสถิติ; รายละเอียดอยู่ในนโยบายความเป็นส่วนตัว) ไม่มีตัวติดตามจากบุคคลที่สามอื่น: ไม่มี Sentry, PostHog, Mixpanel หรือ ad pixel (ตรวจสอบแล้วโดยการค้นหาในทั้งสองฟรอนต์เอนด์) แบ็กเอนด์ไม่มีเทเลเมทรีจากบุคคลที่สามเลย หน้าร้านสำหรับผู้ใช้ปลายทางไม่ถูกครอบคลุมด้วยการวิเคราะห์ใด ๆ ทั้งสิ้น — ไม่มี GA ไม่มีตัวติดตาม (ตรวจสอบได้จากซอร์สโค้ดของมัน)

ข้อแม้: GA รับ IP ของคุณ (ที่ฝั่ง Google) และที่อยู่ของหน้าแผงควบคุมที่ถูกเปิดดู; URL ของแผงควบคุมมีเพียงตัวระบุคลัสเตอร์เท่านั้น ไม่ใช่อีเมล

การชำระเงินและข้อมูลบัตรทั้งหมดถูกจัดการที่ฝั่งผู้ให้บริการ (Tribute / Lemon Squeezy) เรารับเพียง webhook ที่มีลายเซ็นเท่านั้น (HMAC-SHA256, เปรียบเทียบแบบ constant-time, ตรวจสอบก่อนที่จะแยกวิเคราะห์เนื้อหา (body) และก่อนการเขียนฐานข้อมูลใด ๆ: หากไม่รู้ความลับ เหตุการณ์จะไม่ผ่านการตรวจสอบ) เราไม่ได้รับหมายเลขบัตรเต็ม (PAN) หรือ CVV การส่ง webhook เดิมซ้ำ (ผู้ให้บริการลองใหม่) ไม่ทำให้เกิดการให้สิทธิ์ซ้ำซ้อน — เหตุการณ์ถูกกำจัดความซ้ำ

ข้อแม้: ผู้ให้บริการอาจรวมเมทาดาทาของบัตร (แบรนด์และเลข 4 ตัวสุดท้าย) และชื่อกับอีเมลของผู้ชำระเงินไว้ในเนื้อหา (body) ของ webhook เนื้อหาต้นฉบับจำเป็นสำหรับ worker จนกว่าการประมวลผลจะเสร็จสมบูรณ์; หลังการประมวลผลสำเร็จ มันจะถูกลบพร้อมกับข้อมูลอีเมล เหตุการณ์ที่รอการลองใหม่หรือการตรวจทานด้วยมือจะเก็บเนื้อหาต้นฉบับไว้เพียงจนกว่าจะสิ้นสุดช่วงเวลาการเก็บรักษา (90 วันที่ไม่มีกิจกรรม) หลังจากนั้นเมทาดาทาของบัตรและอีเมลของผู้ชำระเงินจะถูกลบโดยอัตโนมัติ 'ไม่มีหมายเลขบัตรเต็ม' เป็นความจริง แต่นั่นเป็นคุณสมบัติของผู้ให้บริการ (เราไม่ได้กรองเนื้อหาเอง); ส่วน 'เราไม่เห็นอะไรเกี่ยวกับบัตรเลย' ไม่ใช่

อีเมล (จำเป็นสำหรับการลงชื่อเข้าใช้), เวลาที่ลงชื่อเข้าใช้ล่าสุด, โหมดอินเทอร์เฟซ; สำหรับการเรียกเก็บเงิน — ยอดคงเหลือและ Telegram (สำหรับการเติมเงิน) IP ของพาร์ทเนอร์ไม่ถูกจัดเก็บในฐานข้อมูล และเราไม่เก็บประวัติการคลิกหรือการกระทำในแผงควบคุม (นอกเหนือจากบันทึกการเข้าถึงสั้น ๆ เมื่อเกิดข้อผิดพลาด)

ไฟร์วอลล์ปฏิเสธการเชื่อมต่อขาเข้าโดยค่าเริ่มต้น เปิดออกด้านนอก: 443 (VPN, Xray+Reality), SSH บนพอร์ตที่ไม่ใช่มาตรฐาน (12011 โดยค่าเริ่มต้น) และ — บนเซิร์ฟเวอร์มาสเตอร์ — พอร์ตแผงแอดมิน Marzban เฉพาะสำหรับ IP ของ control-plane เท่านั้น พอร์ต 80 ถูกเปิดแยกต่างหากเฉพาะในโหมด Let's Encrypt สำหรับ HTTP-01 พอร์ต 22 ถูกปิดหลังจากย้าย SSH แล้ว

พอร์ตการจัดการของโหนดเปิดเฉพาะให้กับ IP ของเซิร์ฟเวอร์มาสเตอร์เท่านั้น ไม่ได้เปิดออกด้านนอก (หากการผูกนี้ล้มเหลวจะยกเลิกการติดตั้ง) หากไฟร์วอลล์ไม่ทำงาน การติดตั้งจะล้มเหลว ICMP echo ถูกจำกัดเฉพาะสำหรับ IPv4; เราไม่รับปากว่าเซิร์ฟเวอร์ 'มองไม่เห็น' และ ICMP ของ IPv6 ถูกคงไว้เพื่อให้ IPv6 ทำงานได้อย่างถูกต้อง

Unattended upgrades ติดตั้งการอัปเดตแพ็กเกจความปลอดภัยโดยอัตโนมัติ ข้อแม้: การรีบูตอัตโนมัติถูกปิดใช้งานโดยตั้งใจ (เพื่อไม่ให้เคอร์เนลที่ยังไม่ได้ตรวจสอบรีบูตด้วยตัวเอง) — ซึ่งหมายความว่าการแก้ไขที่ต้องรีบูต (เคอร์เนล บางครั้ง OpenSSH) จะมีผลหลังการรีบูตด้วยมือหรือตามกำหนดการเท่านั้น 'การแพตช์อัตโนมัติ' เป็นจริงสำหรับ userland ไม่ใช่สำหรับสิ่งที่ต้องรีบูต

เราไม่กล่าวอ้างว่าเซิร์ฟเวอร์ 'มองไม่เห็น' หรือ 'สแกนไม่ได้' พอร์ต 443 เปิดอยู่และตอบสนองการเชื่อมต่อ TCP เหมือนเว็บเซิร์ฟเวอร์ทั่วไป คุณสมบัติ 'เมื่อเชื่อมต่อไม่ถูกต้องมันดูเหมือนเว็บไซต์ธรรมดาที่ไม่เกี่ยวข้อง' มาจากโปรโตคอล Reality ภายใน Xray — องค์ประกอบแยกต่างหากที่เราไม่ทำให้เป็นคำพูดเด็ดขาด

การลงชื่อเข้าใช้ของพาร์ทเนอร์ใช้รหัส 6 หลักแบบใช้ครั้งเดียวที่ส่งไปยังอีเมล ไม่มีรหัสผ่านบัญชี สิ่งนี้ไม่ใช้กับข้อมูลรับรองภายในของส่วนประกอบที่ถูกจัดการ เช่น รหัสผ่านแอดมิน Marzban ที่ถูกสร้างขึ้น รหัสถูกสร้างโดยตัวสร้างเชิงการเข้ารหัส; จัดเก็บเพียงแฮช HMAC ของมันเท่านั้น และการเปรียบเทียบเป็นแบบ constant-time รหัสใช้ได้ครั้งเดียว: เมื่อสำเร็จมันจะถูกลบทันที (ไม่มีการเล่นซ้ำ); หลังพยายามผิด 5 ครั้งมันจะถูกยกเลิกก่อนเวลา ขีดจำกัดอัตราการออกรหัสถูกนับต่ออีเมล ไม่ใช่ต่อ IP — จึงไม่สามารถหลบเลี่ยงได้ด้วยการสลับที่อยู่

โทเคนเซสชันอยู่ใน cookie แบบ HttpOnly และ Secure (JS อ่านไม่ได้) ตรวจสอบที่แบ็กเอนด์ (ไม่ใช่แค่ที่ edge) การหมดเวลาเมื่อไม่มีการใช้งานและการออกจากระบบอัตโนมัติเมื่อไม่มีกิจกรรมถูกทำที่ฝั่งไคลเอนต์ ไม่ใช่ที่เซิร์ฟเวอร์ โทเคนถูกลงลายเซ็นด้วย HS256; ในการตรวจสอบเราปฏิเสธอัลกอริทึมอื่นใดอย่างเข้มงวด (รวมถึง 'none') — การโจมตีแบบสลับอัลกอริทึมคลาสสิกจะไม่ผ่าน โทเคนของหน้าร้านและโทเคนของแผงพาร์ทเนอร์ถูกแยกด้วย audience: โทเคนของผู้ใช้ปลายทางไม่สามารถไปถึง API ของพาร์ทเนอร์ได้ในเชิงเทคนิค (และในทางกลับกัน) พาร์ทเนอร์ที่ถูกลบจะถูกปฏิเสธแม้จะมีโทเคนที่ยังใช้ได้

ข้อแม้: การเพิกถอนถูกทำโดยการตรวจสอบว่าพาร์ทเนอร์มีอยู่จริงในทุกคำขอ ไม่ใช่ด้วยการทำให้ตัวโทเคนเองใช้ไม่ได้; การออกจากระบบลบ cookie แต่โทเคนที่ออกไปแล้วยังคงใช้ได้ในเชิงการเข้ารหัสจนกว่าจะหมดอายุ (นานถึงหนึ่งชั่วโมง) ยังไม่มีรายการเพิกถอนแบบรวมศูนย์ (การทำให้เรียบง่ายอย่างตั้งใจในระดับ MVP)

ไม่มีโทเคนใน local storage ของเบราว์เซอร์ (มีเพียงการตั้งค่า UI); ไม่มีความลับหรือที่อยู่ API เข้าไปในบันเดิลฝั่งไคลเอนต์ มีเพียงเซิร์ฟเวอร์ (Next.js) เท่านั้นที่วางโทเคนไว้ใน cookie แบบ HttpOnly เบราว์เซอร์สื่อสารกับแกนหลักผ่านเซิร์ฟเวอร์เท่านั้น (Server Actions): ฟรอนต์เอนด์ไม่เรียก API โดยตรงจากเบราว์เซอร์ และ CORS ไม่อนุญาตให้เบราว์เซอร์อ่านการตอบสนองของ API จาก origin อื่น

คำชี้แจงแทนคำพูดเด็ดขาดในอดีต: โดเมน API เองเป็นโฮสต์สาธารณะ — ในเชิงเทคนิคคุณเปิดมันจากเบราว์เซอร์ได้ แต่หากไม่มีเซสชัน มันจะไม่ส่งคืนข้อมูลที่ได้รับอนุญาตใด ๆ

โดเมนสาธารณะของ CreateYourVPN ให้บริการผ่าน HTTPS พร้อม HSTS (max-age สองปี, includeSubDomains) ทั้งเว็บฟรอนต์เอนด์และโดเมน API ต่างส่งชุดส่วนหัวความปลอดภัยที่เข้มงวด ได้แก่ Content-Security-Policy ที่จำกัด, X-Content-Type-Options: nosniff, X-Frame-Options และ Referrer-Policy ที่ล็อกไว้แน่นหนา (no-referrer บน API; strict-origin-when-cross-origin บนฟรอนต์เอนด์ ซึ่งยังส่ง Permissions-Policy ที่จำกัดด้วย)

สิ่งนี้ทำงานอยู่จริงในโปรดักชันบนทั้งสองโดเมนและสามารถตรวจสอบได้อย่างอิสระ — ด้วยเครื่องมือตรวจสอบส่วนหัว HTTP ใด ๆ หรือบริการอย่าง SSL Labs