ในด้านคอมพิวเตอร์นโยบายต้นทางเดียวกัน (Same-Origin PolicyหรือSOP ) เป็นแนวคิดใน แบบจำลองความปลอดภัย ของแอปพลิเคชันเว็บภายใต้นโยบายนี้ เว็บเบราว์เซอร์อนุญาตให้สคริปต์ที่อยู่ในเว็บเพจแรกเข้าถึงข้อมูลในเว็บเพจที่สองได้ แต่เฉพาะในกรณีที่ทั้งสองเว็บเพจมีต้นทาง เดียวกัน เท่านั้น ต้นทางถูกกำหนดให้เป็นส่วนประกอบของรูปแบบ URI ชื่อโฮสต์ และหมายเลขพอร์ต นโยบายนี้ป้องกันไม่ให้สคริปต์ที่เป็นอันตรายในหน้าหนึ่งเข้าถึงข้อมูลที่ละเอียดอ่อนในอีกเว็บเพจหนึ่งผ่านทางDocument Object Model (DOM) ของหน้าเพจนั้น

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

นโยบายการเข้าถึงจากแหล่งกำเนิดเดียวกัน (Same-origin policy) ใช้ได้เฉพาะกับสคริปต์เท่านั้น ซึ่งหมายความว่าทรัพยากรต่างๆ เช่น รูปภาพ CSS และสคริปต์ที่โหลดแบบไดนามิก สามารถเข้าถึงได้จากแหล่งกำเนิดที่แตกต่างกันผ่านแท็ก HTML ที่เกี่ยวข้อง (โดยมีข้อยกเว้นที่สำคัญคือฟอนต์) การโจมตีใช้ประโยชน์จากข้อเท็จจริงที่ว่านโยบายการเข้าถึงจากแหล่งกำเนิดเดียวกันไม่มีผลบังคับใช้กับแท็ก HTML

มีกลไกบางอย่างที่สามารถช่วยผ่อนคลายข้อกำหนดมาตรฐานการปฏิบัติงาน (SOP) ได้ หนึ่งในนั้นคือการแบ่งปันทรัพยากรข้ามโดเมน (CORS)

แนวคิดนโยบายต้นทางเดียวกันได้รับการแนะนำโดยNetscape Navigator 2.02ในปี 1995 ^{[ 1 ]} ไม่นานหลังจากที่ JavaScriptได้รับการแนะนำใน Netscape 2.0 ^{[ 2 ] [ 3 ]} JavaScript ช่วยให้สามารถเขียนสคริปต์บนเว็บเพจได้ โดยเฉพาะอย่างยิ่งการเข้าถึง DOM แบบโปรแกรม

เดิมทีนโยบายนี้ถูกออกแบบมาเพื่อปกป้องการเข้าถึง DOM แต่ต่อมาได้ขยายขอบเขตไปเพื่อปกป้องส่วนที่สำคัญของอ็อบเจ็กต์ JavaScript ทั่วโลกด้วย

เบราว์เซอร์สมัยใหม่ทั้งหมดใช้รูปแบบนโยบายต้นทางเดียวกันบางรูปแบบ เนื่องจากเป็นรากฐานด้านความปลอดภัยที่สำคัญ^{[ 4 ]}นโยบายเหล่านี้ไม่จำเป็นต้องตรงกับข้อกำหนดที่แน่นอน^{[ 5 ]}แต่มักจะขยายออกไปเพื่อกำหนดขอบเขตความปลอดภัยที่เข้ากันได้โดยประมาณสำหรับเทคโนโลยีเว็บอื่นๆ เช่นMicrosoft Silverlight , Adobe FlashหรือAdobe Acrobat หรือสำหรับกลไกอื่นๆ นอกเหนือจากการ จัดการ DOM โดยตรง เช่นXMLHttpRequest

อัลกอริทึมที่ใช้ในการคำนวณ "ต้นกำเนิด" ของ URI นั้นระบุไว้ใน RFC 6454 ส่วนที่ 4 สำหรับ URI แบบสัมบูรณ์ ต้นกำเนิดคือสามค่า {scheme, host, port} หาก URI ไม่ได้ใช้องค์ประกอบแบบลำดับชั้นเป็นตัวกำหนดชื่อ (ดูRFC 3986ส่วนที่ 3.2) หรือหาก URI ไม่ใช่ URI แบบสัมบูรณ์ จะใช้ตัวระบุที่ไม่ซ้ำกันทั่วโลกแทน ทรัพยากรสองรายการจะถือว่ามีต้นกำเนิดเดียวกันก็ต่อเมื่อค่าเหล่านี้ทั้งหมดเหมือนกันทุกประการ

เพื่อเป็นตัวอย่าง ตารางต่อไปนี้แสดงภาพรวมของผลลัพธ์ทั่วไปสำหรับการตรวจสอบURL " http://www.example.com/dir/page.html "

ต่างจากเบราว์เซอร์อื่นๆ Internet Explorer ไม่ได้รวมพอร์ตในการคำนวณต้นทาง แต่ใช้โซนความปลอดภัยแทน^{[ 8 ]}

นโยบาย Same-Origin ช่วยป้องกันการนำเซสชันที่ได้รับการตรวจสอบสิทธิ์แล้วกลับมาใช้ซ้ำข้ามโดเมน ตัวอย่างต่อไปนี้แสดงให้เห็นถึงความเสี่ยงด้านความปลอดภัยที่อาจเกิดขึ้นได้หากไม่มีนโยบาย Same-Origin สมมติว่าผู้ใช้กำลังเยี่ยมชมเว็บไซต์ธนาคารและไม่ได้ออกจากระบบ จากนั้นผู้ใช้ไปที่เว็บไซต์อื่นที่มีโค้ด JavaScript ที่เป็นอันตรายซึ่งร้องขอข้อมูลจากเว็บไซต์ธนาคาร เนื่องจากผู้ใช้ยังคงล็อกอินอยู่ในเว็บไซต์ธนาคาร โค้ดที่เป็นอันตรายจึงสามารถทำอะไรก็ได้ที่ผู้ใช้สามารถทำได้ในเว็บไซต์ธนาคาร ตัวอย่างเช่น อาจได้รับรายการธุรกรรมล่าสุดของผู้ใช้ สร้างธุรกรรมใหม่ ฯลฯ ทั้งนี้เพราะตามหลักการดั้งเดิมของเวิลด์ไวด์เว็บ เบราว์เซอร์จำเป็นต้องแนบรายละเอียดการตรวจสอบสิทธิ์ เช่น คุกกี้เซสชันและส่วนหัวคำขอการอนุญาตระดับแพลตฟอร์มไปยังเว็บไซต์ธนาคารโดยอิงตามโดเมนของเว็บไซต์ธนาคาร

เจ้าของเว็บไซต์ธนาคารคาดหวังว่าเบราว์เซอร์ทั่วไปของผู้ใช้ที่เข้าชมเว็บไซต์ที่เป็นอันตรายจะไม่อนุญาตให้โค้ดที่โหลดจากเว็บไซต์ที่เป็นอันตรายเข้าถึงคุกกี้เซสชันของธนาคารหรือการอนุญาตระดับแพลตฟอร์ม แม้ว่า JavaScript จะไม่สามารถเข้าถึงคุกกี้เซสชันของธนาคารได้โดยตรง แต่ก็ยังสามารถส่งและรับคำขอไปยังเว็บไซต์ธนาคารโดยใช้คุกกี้เซสชันของเว็บไซต์ธนาคารได้ นโยบาย Same Origin Policy ถูกนำมาใช้เป็นข้อกำหนดสำหรับเบราว์เซอร์ที่คำนึงถึงความปลอดภัยเพื่อปฏิเสธการเข้าถึงการอ่านการตอบสนองจากแหล่งที่มาต่างกัน โดยมีสมมติฐานว่าผู้ใช้ส่วนใหญ่เลือกใช้เบราว์เซอร์ที่สอดคล้องกับนโยบายนี้ นโยบายนี้ไม่ได้ปฏิเสธการเขียน การแก้ไขปัญหาการใช้สิทธิ์การเขียนในทางที่ผิดจำเป็นต้องมี การป้องกัน CSRF เพิ่มเติม โดยเว็บไซต์เป้าหมาย

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

Netscape Navigatorเคยมี ฟีเจอร์ ตรวจสอบการปนเปื้อน อยู่ช่วงสั้นๆ ฟีเจอร์นี้ถูกนำมาใช้ในเชิงทดลองในปี 1997 ใน Netscape 3 ^{[ 9 ]}ฟีเจอร์นี้ถูกปิดใช้งานโดยค่าเริ่มต้น แต่หากผู้ใช้เปิดใช้งาน จะทำให้เว็บไซต์สามารถพยายามอ่านคุณสมบัติ JavaScript ของหน้าต่างและเฟรมที่อยู่ในโดเมนอื่นได้ จากนั้นเบราว์เซอร์จะถามผู้ใช้ว่าต้องการอนุญาตการเข้าถึงดังกล่าวหรือไม่^{[ 10 ] [ 11 ]}

หากหน้าต่าง (หรือเฟรม) สองบานมีสคริปต์ที่ตั้งค่าโดเมนเป็นค่าเดียวกัน นโยบายต้นทางเดียวกันจะถูกผ่อนปรนสำหรับหน้าต่างทั้งสองบานนี้ และแต่ละหน้าต่างสามารถโต้ตอบกันได้ ตัวอย่างเช่น สคริปต์ที่ทำงานร่วมกันในเอกสารที่โหลดจาก orders.example.com และ catalog.example.com อาจตั้งค่าdocument.domainคุณสมบัติเป็น “example.com” ซึ่งจะทำให้เอกสารดูเหมือนมีต้นทางเดียวกันและทำให้แต่ละเอกสารสามารถอ่านคุณสมบัติของอีกเอกสารหนึ่งได้ การตั้งค่าคุณสมบัตินี้จะตั้งค่าพอร์ตเป็นค่าว่างโดยปริยาย ซึ่งเบราว์เซอร์ส่วนใหญ่จะตีความแตกต่างจากพอร์ต 80 หรือแม้แต่พอร์ตที่ไม่ได้ระบุ เพื่อให้แน่ใจว่าเบราว์เซอร์จะอนุญาตการเข้าถึง ให้ตั้งค่าคุณสมบัติ document.domain ของทั้งสองหน้า^{[ 12 ]}

แนวคิด นี้document.domainได้รับการแนะนำเป็นส่วนหนึ่งของ Netscape Navigator 3 ^{[ 13 ]}ซึ่งวางจำหน่ายในปี พ.ศ. 2539 ^{[ 9 ]}

เทคนิคอื่นสำหรับการผ่อนปรนนโยบายต้นทางเดียวกันคือการกำหนดมาตรฐานภายใต้ชื่อการแบ่งปันทรัพยากรข้ามต้นทาง (CORS) มาตรฐานนี้ขยาย HTTP ด้วยOriginส่วนหัวคำขอใหม่และAccess-Control-Allow-Originส่วนหัวการตอบกลับ ใหม่ ^{[ 14 ]}อนุญาตให้เซิร์ฟเวอร์ใช้ส่วนหัวเพื่อระบุต้นทางที่อาจร้องขอไฟล์อย่างชัดเจน หรือใช้สัญลักษณ์ตัวแทนและอนุญาตให้ร้องขอไฟล์จากไซต์ใดก็ได้ เบราว์เซอร์เช่น Firefox 3.5, Safari 4 และInternet Explorer 10ใช้ส่วนหัวนี้เพื่ออนุญาตคำขอ HTTP ข้ามต้นทางด้วย XMLHttpRequest ซึ่งโดยปกติแล้วจะถูกห้ามโดยนโยบายต้นทางเดียวกัน

เทคนิคอีกอย่างหนึ่งคือการส่งข้อความข้ามเอกสารซึ่งช่วยให้สคริปต์จากหน้าหนึ่งสามารถส่งข้อความไปยังสคริปต์ในอีกหน้าหนึ่งได้ โดยไม่คำนึงถึงที่มาของสคริปต์ การเรียกใช้เมธอด postMessage() บนออบเจ็กต์ Window แบบอะซิงโครนัส จะเรียกใช้งานอีเวนต์ "onmessage" ในหน้าต่างนั้น ซึ่งจะเรียกใช้งานตัวจัดการอีเวนต์ที่ผู้ใช้กำหนดไว้ สคริปต์ในหน้าหนึ่งยังคงไม่สามารถเข้าถึงเมธอดหรือตัวแปรในอีกหน้าหนึ่งได้โดยตรง แต่สามารถสื่อสารกันได้อย่างปลอดภัยผ่านเทคนิคการส่งข้อความนี้

เนื่องจาก <script>องค์ประกอบ HTML ได้รับอนุญาตให้ดึงและเรียกใช้เนื้อหาจากโดเมนอื่นได้ หน้าเว็บจึงสามารถหลีกเลี่ยงนโยบายต้นทางเดียวกัน (same-origin policy) และรับ ข้อมูล JSONจากโดเมนอื่นได้โดยการโหลดทรัพยากรที่ส่งคืนเพย์โหลด JSONP เพย์โหลด JSONP ประกอบด้วยเพย์โหลด JSON ภายในที่ห่อหุ้มด้วยการเรียกใช้ฟังก์ชันที่กำหนดไว้ล่วงหน้า เมื่อเบราว์เซอร์โหลดทรัพยากรสคริปต์ ฟังก์ชันเรียกกลับที่กำหนดไว้จะถูกเรียกใช้เพื่อประมวลผลเพย์โหลด JSON ที่ห่อหุ้มไว้

เบราว์เซอร์สมัยใหม่จะอนุญาตให้สคริปต์เชื่อมต่อกับที่อยู่ WebSocket โดยไม่ต้องใช้หลักการ Same-Origin Policy อย่างไรก็ตาม เบราว์เซอร์จะตรวจจับได้ว่ามีการใช้ URI ของ WebSocket หรือไม่ และจะแทรกส่วน หัว Origin:ลงในคำขอเพื่อระบุที่มาของสคริปต์ที่ร้องขอการเชื่อมต่อ เพื่อให้มั่นใจในความปลอดภัยข้ามเว็บไซต์ เซิร์ฟเวอร์ WebSocket ต้องตรวจสอบว่าที่มานั้นได้รับอนุญาตให้รับการตอบกลับหรือไม่

พฤติกรรมของการตรวจสอบแหล่งกำเนิดเดียวกันและกลไกที่เกี่ยวข้องนั้นไม่ได้ถูกกำหนดไว้อย่างชัดเจนในกรณีพิเศษหลายกรณี เช่น สำหรับโปรโตคอลเสมือนที่ไม่มีชื่อโฮสต์หรือพอร์ตที่กำหนดไว้อย่างชัดเจนใน URL (เช่นfile: , เป็นต้น) ซึ่งในอดีตได้ก่อให้เกิดปัญหาด้านความปลอดภัยมากมาย เช่น ความสามารถที่ไม่พึงประสงค์โดยทั่วไปของไฟล์ HTML ที่จัดเก็บไว้ในเครื่องในการเข้าถึงไฟล์อื่นๆ ทั้งหมดในดิสก์ หรือสื่อสารกับเว็บไซต์ใดๆ บนอินเทอร์เน็ตได้

สุดท้ายนี้ การโจมตีบางประเภท เช่น การเปลี่ยน DNS หรือพร็อกซีฝั่งเซิร์ฟเวอร์ อนุญาตให้การตรวจสอบชื่อโฮสต์ถูกบิดเบือนได้บางส่วน และทำให้เว็บเพจที่ไม่พึงประสงค์สามารถโต้ตอบกับเว็บไซต์โดยตรงผ่านที่อยู่ที่ไม่ใช่ที่อยู่ต้นทาง "ที่แท้จริง" หรือที่เป็นทางการ ผลกระทบของการโจมตีดังกล่าวจำกัดอยู่เฉพาะสถานการณ์ที่เฉพาะเจาะจงมาก เนื่องจากเบราว์เซอร์ยังคงเชื่อว่ากำลังโต้ตอบกับเว็บไซต์ของผู้โจมตี ดังนั้นจึงไม่เปิดเผยคุกกี้ของบุคคลที่สามหรือข้อมูลที่ละเอียดอ่อนอื่น ๆ ให้กับผู้โจมตี

แม้ว่านโยบายต้นทางเดียวกันจะมีผลบังคับใช้ (โดยไม่ได้รับการผ่อนปรนจากการแบ่งปันทรัพยากรข้ามต้นทาง) การโจมตีข้ามต้นทางบางอย่างก็ยังสามารถดำเนินการได้WebRTCสามารถใช้เพื่อค้นหาที่อยู่ IP ภายในของเหยื่อได้^{[ 15 ]}หากพยายามเชื่อมต่อกับพอร์ตข้ามต้นทาง จะไม่สามารถอ่านการตอบสนองได้แม้จะมีนโยบายต้นทางเดียวกัน แต่JavaScriptยังคงสามารถอนุมานได้ว่าพอร์ตเปิดหรือปิดอยู่โดยการตรวจสอบว่าเหตุการณ์ onload/onerror ทำงานหรือไม่ หรือว่าเราได้รับการหมดเวลาหรือไม่ ซึ่งเปิดโอกาสให้มี การ สแกน พอร์ต ข้ามต้นทาง

นอกจากนี้ โค้ด JavaScript สามารถใช้เทคนิคต่างๆ เช่น การรั่วไหลข้ามไซต์^{[ 16 ]}เพื่อใช้ประโยชน์จากการรั่วไหลของข้อมูลที่มีมานานในเบราว์เซอร์เพื่ออนุมานข้อมูลข้ามต้นทาง การโจมตีเหล่านี้สามารถป้องกันได้โดยการใช้ส่วนหัว Cross-Origin Resource Policy (CORP) ซึ่งช่วยให้เจ้าของเว็บไซต์สามารถบล็อกทรัพยากรข้ามต้นทางหรือข้ามไซต์ เช่น รูปภาพ วิดีโอ และสไตล์ชีต CORP ยังสามารถบล็อกfetchคำขอที่เริ่มต้นโดย JavaScript ได้ แต่เฉพาะในกรณีที่ส่งด้วยโหมดคำขอno-cors^{[ 17 ] เท่านั้น [ 18 ]}

นโยบาย Same-Origin ไม่ได้ห้ามเบราว์เซอร์จากการส่งคำขอ GET, POST, OPTIONS และ TRACE แต่จะป้องกันไม่ให้โค้ดของผู้ใช้เข้าถึงข้อมูลที่ได้รับจากคำขอเหล่านั้นเท่านั้น ดังนั้น หากปลายทางใดใช้หนึ่งในวิธีการร้องขอที่ "ปลอดภัย" เหล่านี้ในการเขียนข้อมูลหรือดำเนินการใดๆ ในนามของผู้ใช้ ก็อาจถูกผู้โจมตีใช้ประโยชน์ได้

โปรดทราบว่านโยบายต้นทางเดียวกันไม่มีผลบังคับใช้กับคุกกี้ด้วยเหตุผลทางประวัติศาสตร์^{[ 19 ]}หากมีการใช้งานเว็บไซต์ที่เป็นศัตรูหลายแห่งบนชื่อโฮสต์เดียวกันที่มีหมายเลขพอร์ตต่างกัน ซึ่งขัดกับ SOP คุกกี้ทั้งหมดที่ตั้งค่าโดยเว็บไซต์ใดๆ ก็ตามจะถูกแชร์ ซึ่งสามารถใช้เพื่อรั่วไหลโทเค็นเซสชันของผู้ใช้และขโมยข้อมูลบัญชีได้ ดังนั้น บริการเว็บควรแยกออกจากกันโดยใช้โดเมนย่อย ที่แตกต่างกัน แทนที่จะใช้หมายเลขพอร์ต

• การแบ่งปันทรัพยากรข้ามแหล่งกำเนิด
• การโจมตีแบบ Cross-site scripting
• การปลอมแปลงคำขอข้ามเว็บไซต์
• นโยบายความปลอดภัยของเนื้อหา

• นโยบายการเชื่อมต่อจากแหล่งกำเนิดเดียวกันสำหรับไฟล์ ที่มีจำนวน บรรทัดไม่เกิน 500 บรรทัด

• การเปรียบเทียบโดยละเอียดของนโยบายแหล่งกำเนิดสินค้าเดียวกันหลายรูปแบบ
• บทวิจารณ์เกี่ยวกับข้อบกพร่องในนโยบายต้นทางเดียวกันและผลกระทบต่อความปลอดภัยของเว็บในWayback Machine (เก็บถาวรเมื่อวันที่ 11 กุมภาพันธ์ 2550)
• ตัวอย่างข้อกำหนดนโยบายต้นทางเดียวกันที่ผู้ขายจัดหาให้
• คำจำกัดความของ Origin ในข้อกำหนด HTML5
• บทความของ W3C เกี่ยวกับนโยบายแหล่งกำเนิดเดียวกัน
• RFC 6454 ว่าด้วยแนวคิดเรื่องต้นกำเนิดของเว็บ