เหตุใดการแบ่งปันทรัพยากรแบบ Cross-Origin จึงมีความสำคัญ

ในอดีต เมื่อเทคโนโลยีอินเทอร์เน็ตยังใหม่ มักเกิดปัญหาการโจมตีแบบ Cross-Site Request Forgery ขึ้น ปัญหาเหล่านี้คือการส่งคำขอของลูกค้าปลอมจากเบราว์เซอร์ของเหยื่อไปยังแอปพลิเคชันอื่น ตัวอย่างเช่น มีเหยื่อเข้าสู่ระบบในแอปพลิเคชันธนาคารของตน จากนั้น พวกเขาจะถูกหลอกให้โหลดเว็บไซต์ภายนอกบนแท็บเบราว์เซอร์ใหม่ จากนั้นเว็บไซต์ภายนอกจะใช้ข้อมูลประจำตัวในของคุกกี้ของเหยื่อและส่งข้อมูลไปยังโปรแกรมธนาคารในขณะที่แสร้งทำเป็นเหยื่อ และผู้ใช้ที่ไม่ได้รับอนุญาตก็จะสามารถเข้าถึงแอปพลิเคชันธนาคารนั้นได้โดยเจตนาร้าย เพื่อป้องกันไม่ให้เกิดปัญหา CSRF เบราว์เซอร์ทั้งหมดในขณะนี้ใช้นโยบาย Same-Origin Policy <h3 style="margin-left:0in; margin-right:0in">Same-Origin Policy</h3> ในปัจจุบัน เบราว์เซอร์ต่างๆ บังคับว่าลูกค้าจะต้องส่งคำขอไปยังทรัพยากรโดยใช้ต้นทางเดียวกับ URL ของลูกค้าเท่านั้น โปรโตคอล พอร์ต และชื่อโฮสต์ของ URL ของลูกค้าทุกคนจะต้องตรงกับเซิร์ฟเวอร์ที่ร้องขอ ตัวอย่างเช่น ลองดูการเปรียบเทียบต้นทางของ URL ด้านล่างกับ URL ของลูกค้า http://store.aws.com/dir/page.html <table border="1" cellspacing="0" class="Table" style="border-collapse:collapse; border:solid windowtext 1.0pt"> <tbody> <tr> <td> URL </td> <td> ผลลัพธ์ </td> <td> เหตุผล </td> </tr> <tr> <td> http://store.aws.com/dir2/new.html </td> <td> ต้นทางเดียวกัน </td> <td> มีเพียงพาธที่ต่างกัน </td> </tr> <tr> <td> http://store.aws.com/dir/inner/other.html </td> <td> ต้นทางเดียวกัน </td> <td> มีเพียงพาธที่ต่างกัน </td> </tr> <tr> <td> https://store.aws.com/page.html </td> <td> ต้นทางแตกต่างกัน       </td> <td> โปรโตคอลแตกต่างกัน </td> </tr> <tr> <td> http://store.aws.com:81/dir/page.html </td> <td> ต้นทางแตกต่างกัน </td> <td> พอร์ตแตกต่างกัน (http://เป็นพอร์ต 80 โดยค่าเริ่มต้น) </td> </tr> <tr> <td> http://news.aws.com/dir/page.html </td> <td> ต้นทางแตกต่างกัน </td> <td> โฮสต์แตกต่างกัน </td> </tr> </tbody> </table> ดังนั้นนโยบาย Same-Origin Policy มีความปลอดภัยสูง แต่ไม่ยืดหยุ่นสำหรับในกรณีที่การใช้งานนั้นเป็นของผู้ใช้จริงๆ Cross-origin Resource Sharing (CORS) เป็นส่วนขยายเพิ่มเติมของนโยบาย Same-Origin Policy คุณจำเป็นต้องใช้สิ่งนี้ในการแบ่งปันทรัพยากรที่ได้รับอนุญาตกับบุคคลที่สามภายนอก ตัวอย่างเช่นคุณต้องใช้ CORS เมื่อคุณต้องการที่จะดึงข้อมูลจาก API ภายนอกที่เป็นสาธารณะหรือที่ได้รับอนุญาต นอกจากนี้คุณยังต้องใช้ CORS ถ้าคุณต้องการที่จะอนุญาตบุคคลที่สามที่ได้รับอนุญาตเข้าถึงทรัพยากรเซิร์ฟเวอร์ของคุณเองได้

Cross-Origin Resource Sharing ทำงานอย่างไร

ในการสื่อสารอินเทอร์เน็ตมาตรฐาน เบราว์เซอร์ของคุณจะส่งคำขอ HTTP ไปยังเซิร์ฟเวอร์แอปพลิเคชันที่ได้รับข้อมูลเป็นการตอบกลับ HTTP และแสดงผล ในคำศัพท์เกี่ยวกับเบราว์เซอร์ URL ของเบราว์เซอร์ปัจจุบันจะเรียกว่า Current Origin และ URL ของบุคคลที่สามคือ Cross-Origin เมื่อคุณส่งคำขอ Cross-Origin ก็จะเป็นกระบวนการร้องขอการตอบกลับ: <ol> <li>เบราว์เซอร์จะเพิ่มส่วนหัวต้นทางของคำขอที่มีข้อมูลเกี่ยวกับต้นทางปัจจุบันของโปรโตคอล โฮสต์ และพอร์ต</li> <li>เซิร์ฟเวอร์ตรวจสอบส่วนหัวต้นทางของคำขอปัจจุบันและตอบสนองกับข้อมูลที่ร้องขอและส่วนหัว Access-Control-Allow-Origin</li> <li>เบราว์เซอร์จะดูส่วนหัวคำขอควบคุมการเข้าถึงและแชร์ข้อมูลที่ส่งกลับมาให้กับไคลเอนต์แอปพลิเคชัน</li> </ol> อีกวิธีหนึ่งคือ ถ้าเซิร์ฟเวอร์ไม่ต้องการที่จะอนุญาตให้เข้าถึงแบบ Cross-Origin ก็จะตอบกลับเป็นข้อผิดพลาด <h3 style="margin-left:0in; margin-right:0in">ตัวอย่างการแบ่งปันทรัพยากรแบบ Cross-Origin</h3> ตัวอย่างเช่น ลองพิจารณาเว็บไซต์ที่เรียกว่า https://news.example.com เว็บไซต์นี้ ต้องการเข้าถึงทรัพยากรจาก API ที่ partner-api.com นักพัฒนาที่ https://partner-api.com กำหนดค่าส่วนหัว Cross-Origin Resource Sharing (CORS) บนเซิร์ฟเวอร์ของตนโดยการเพิ่ม new.example.com ไปยังรายการต้นทางที่ได้รับอนุญาต พวกเขาทำเช่นนี้โดยการเพิ่มบรรทัดด้านล่างไปยังไฟล์การกำหนดค่าเซิร์ฟเวอร์ของตน Access-Control-Allow-Origin: https://news.example.com เมื่อกำหนดค่าการเข้าถึงแบบ CORS แล้ว news.example.com จะสามารถขอทรัพยากรจาก partner-api.com ได้ สำหรับทุกคำขอ partner-api.com จะตอบกลับด้วย Access-Control-Allow-Credentials : "true." และเบราว์เซอร์จะรู้ว่าการสื่อสารใดที่ได้รับอนุญาตและอนุญาตให้เข้าถึงแบบ Cross-Origin หากคุณต้องการให้สิทธิ์การเข้าถึงต้นทางหลายต้นทาง ให้ใช้การคั่นด้วยเครื่องหมายจุลภาคหรืออักขระตัวแทนเช่น * ที่ให้สิทธิ์การเข้าถึงแก่ทุกคน

CORS คืออะไร

สร้างบัญชี AWS

สำรวจข้อเสนอการผสานแอปพลิเคชันฟรี

ดูข้อเสนอฟรีสำหรับบริการผสานแอปพลิเคชันในระบบคลาวด์

ดูบริการผสานแอปพลิเคชัน

สร้างสรรค์นวัตกรรมได้เร็วยิ่งขึ้นด้วยชุดบริการผสานแอปพลิเคชันที่ครอบคลุมที่สุด

เรียกดูการฝึกอบรมด้านการผสานแอปพลิเคชัน

เริ่มต้นการฝึกอบรมด้านการผสานแอปพลิเคชันด้วยเนื้อหาที่จัดทำขึ้นโดยผู้เชี่ยวชาญของ AWS

อ่านบล็อกการผสานแอปพลิเคชัน

อ่านข่าวสารล่าสุดและแนวปฏิบัติที่ดีที่สุดเกี่ยวกับผลิตภัณฑ์การผสานแอปพลิเคชันของ AWS

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

ในอดีต เมื่อเทคโนโลยีอินเทอร์เน็ตยังใหม่ มักเกิดปัญหาการโจมตีแบบ Cross-Site Request Forgery ขึ้น ปัญหาเหล่านี้คือการส่งคำขอของลูกค้าปลอมจากเบราว์เซอร์ของเหยื่อไปยังแอปพลิเคชันอื่น

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

เพื่อป้องกันไม่ให้เกิดปัญหา CSRF เบราว์เซอร์ทั้งหมดในขณะนี้ใช้นโยบาย Same-Origin Policy

Same-Origin Policy

ในปัจจุบัน เบราว์เซอร์ต่างๆ บังคับว่าลูกค้าจะต้องส่งคำขอไปยังทรัพยากรโดยใช้ต้นทางเดียวกับ URL ของลูกค้าเท่านั้น โปรโตคอล พอร์ต และชื่อโฮสต์ของ URL ของลูกค้าทุกคนจะต้องตรงกับเซิร์ฟเวอร์ที่ร้องขอ

ตัวอย่างเช่น ลองดูการเปรียบเทียบต้นทางของ URL ด้านล่างกับ URL ของลูกค้า http://store.aws.com/dir/page.html

URL	ผลลัพธ์	เหตุผล
http://store.aws.com/dir2/new.html	ต้นทางเดียวกัน	มีเพียงพาธที่ต่างกัน
http://store.aws.com/dir/inner/other.html	ต้นทางเดียวกัน	มีเพียงพาธที่ต่างกัน
https://store.aws.com/page.html	ต้นทางแตกต่างกัน	โปรโตคอลแตกต่างกัน
http://store.aws.com:81/dir/page.html	ต้นทางแตกต่างกัน	พอร์ตแตกต่างกัน (http://เป็นพอร์ต 80 โดยค่าเริ่มต้น)
http://news.aws.com/dir/page.html	ต้นทางแตกต่างกัน	โฮสต์แตกต่างกัน

ดังนั้นนโยบาย Same-Origin Policy มีความปลอดภัยสูง แต่ไม่ยืดหยุ่นสำหรับในกรณีที่การใช้งานนั้นเป็นของผู้ใช้จริงๆ

Cross-origin Resource Sharing (CORS) เป็นส่วนขยายเพิ่มเติมของนโยบาย Same-Origin Policy คุณจำเป็นต้องใช้สิ่งนี้ในการแบ่งปันทรัพยากรที่ได้รับอนุญาตกับบุคคลที่สามภายนอก ตัวอย่างเช่นคุณต้องใช้ CORS เมื่อคุณต้องการที่จะดึงข้อมูลจาก API ภายนอกที่เป็นสาธารณะหรือที่ได้รับอนุญาต นอกจากนี้คุณยังต้องใช้ CORS ถ้าคุณต้องการที่จะอนุญาตบุคคลที่สามที่ได้รับอนุญาตเข้าถึงทรัพยากรเซิร์ฟเวอร์ของคุณเองได้

ในการสื่อสารอินเทอร์เน็ตมาตรฐาน เบราว์เซอร์ของคุณจะส่งคำขอ HTTP ไปยังเซิร์ฟเวอร์แอปพลิเคชันที่ได้รับข้อมูลเป็นการตอบกลับ HTTP และแสดงผล ในคำศัพท์เกี่ยวกับเบราว์เซอร์ URL ของเบราว์เซอร์ปัจจุบันจะเรียกว่า Current Origin และ URL ของบุคคลที่สามคือ Cross-Origin

เมื่อคุณส่งคำขอ Cross-Origin ก็จะเป็นกระบวนการร้องขอการตอบกลับ:

เบราว์เซอร์จะเพิ่มส่วนหัวต้นทางของคำขอที่มีข้อมูลเกี่ยวกับต้นทางปัจจุบันของโปรโตคอล โฮสต์ และพอร์ต
เซิร์ฟเวอร์ตรวจสอบส่วนหัวต้นทางของคำขอปัจจุบันและตอบสนองกับข้อมูลที่ร้องขอและส่วนหัว Access-Control-Allow-Origin
เบราว์เซอร์จะดูส่วนหัวคำขอควบคุมการเข้าถึงและแชร์ข้อมูลที่ส่งกลับมาให้กับไคลเอนต์แอปพลิเคชัน

อีกวิธีหนึ่งคือ ถ้าเซิร์ฟเวอร์ไม่ต้องการที่จะอนุญาตให้เข้าถึงแบบ Cross-Origin ก็จะตอบกลับเป็นข้อผิดพลาด

ตัวอย่างการแบ่งปันทรัพยากรแบบ Cross-Origin

ตัวอย่างเช่น ลองพิจารณาเว็บไซต์ที่เรียกว่า https://news.example.com เว็บไซต์นี้ ต้องการเข้าถึงทรัพยากรจาก API ที่ partner-api.com

นักพัฒนาที่ https://partner-api.com กำหนดค่าส่วนหัว Cross-Origin Resource Sharing (CORS) บนเซิร์ฟเวอร์ของตนโดยการเพิ่ม new.example.com ไปยังรายการต้นทางที่ได้รับอนุญาต พวกเขาทำเช่นนี้โดยการเพิ่มบรรทัดด้านล่างไปยังไฟล์การกำหนดค่าเซิร์ฟเวอร์ของตน

Access-Control-Allow-Origin: https://news.example.com

เมื่อกำหนดค่าการเข้าถึงแบบ CORS แล้ว news.example.com จะสามารถขอทรัพยากรจาก partner-api.com ได้ สำหรับทุกคำขอ partner-api.com จะตอบกลับด้วย Access-Control-Allow-Credentials : "true." และเบราว์เซอร์จะรู้ว่าการสื่อสารใดที่ได้รับอนุญาตและอนุญาตให้เข้าถึงแบบ Cross-Origin

หากคุณต้องการให้สิทธิ์การเข้าถึงต้นทางหลายต้นทาง ให้ใช้การคั่นด้วยเครื่องหมายจุลภาคหรืออักขระตัวแทนเช่น * ที่ให้สิทธิ์การเข้าถึงแก่ทุกคน

คำขอพรีไฟลต์ของ CORS คืออะไร

ใน HTTP วิธีการส่งคำขอคือการดำเนินงานข้อมูลที่ลูกค้าต้องการให้เซิร์ฟเวอร์ดำเนินการ กระบวนการทั่วไปของ HTTP ได้แก่ รับ, โพสต์, ใส่ และ ลบ

ในปฏิสัมพันธ์แบบ Cross-Origin Resource Sharing (CORS) ปกติ เบราว์เซอร์จะส่งคำขอและการควบคุมการเข้าถึงส่วนหัวในเวลาเดียวกัน การดำเนินการเหล่านี้มักจะ รับ คำขอข้อมูลและถือว่ามีความเสี่ยงต่ำ

อย่างไรก็ตามบางคำขอ HTTP ถือว่าซับซ้อนและต้องมีการยืนยันเซิร์ฟเวอร์ก่อนที่จะส่งคำขอจริง ขั้นตอนการอนุมัติล่วงหน้าเรียกว่าคำขอพรีไฟลต์

คำขอ Cross-Origin ที่ซับซ้อน

คำขอ Cross-Origin จะมีความซับซ้อนหากใช้รูปแบบใดๆ ต่อไปนี้:

วิธีการอื่นที่ไม่ใช่ รับ, โพสต์, หรือ ส่วนหัว
ส่วนหัวอื่นๆ นอกเหนือจาก Accept-Language, Accept หรือ Content-Language
ส่วนหัวชนิดเนื้อหาอื่นๆ นอกเหนือจาก multipart/form-data, application/x-www-form-urlencoded หรือ text/plain

ตัวอย่างเช่น คำขอลบหรือแก้ไขข้อมูลที่มีอยู่เดิมถือว่าซับซ้อน

คำขอพรีไฟลต์ทำงานอย่างไร

เบราว์เซอร์จะสร้างคำขอพรีไฟลต์หากจำเป็น สิ่งนี้เป็นคำขอแบบตัวเลือก เช่นต่อไปนี้

OPTIONS /data HTTP/1.1

ต้นทาง: https://example.com

Access-Control-Request-Method: ลบ

เบราว์เซอร์ส่งคำขอพรีไฟลต์ก่อนจะเกิดคำขอขึ้นจริง เซิร์ฟเวอร์ต้องตอบสนองต่อคำขอพรีไฟลต์พร้อมข้อมูลเกี่ยวกับคำขอ Cross-Origin ที่เซิร์ฟเวอร์จะยอมรับจาก URL ของไคลเอ็นต์ ส่วนหัวของการตอบกลับของเซิร์ฟเวอร์ต้องเป็นดังต่อไปนี้:

Access-Control-Allow-Methods
Access-Control-Allow-Headers
Access-Control-Allow-Origin

ตัวอย่างการตอบกลับเซิร์ฟเวอร์มีดังต่อไปนี้

HTTP/1.1 200 OK

Access-Control-Allow-Headers: ประเภทเนื้อหา

Access-Control-Allow-Origin: https://news.example.com

Access-Control-Allow-Methods: รับ, ลบ, ส่วนหัว, ตัวเลือก

การตอบกลับพรีไฟลต์บางครั้งมีส่วนหัว Access Control-Max-Age เพิ่มเติม ตัวชี้วัดนี้ระบุระยะเวลา (เป็นวินาที) สำหรับเบราว์เซอร์ในการแคชผลพรีไฟลต์ในเบราว์เซอร์ การแคชช่วยให้เบราว์เซอร์ส่งคำขอที่ซับซ้อนหลายระหว่างคำขอพรีไฟลต์ได้ โดยไม่จำเป็นต้องส่งคำขอพรีไฟลต์อื่นจนกว่าจะเลยเวลาสูงสุดที่ระบุ

ความแตกต่างระหว่าง CORS-Origin และ JSONP คืออะไร

JSON กับ Padding (JSONP) เป็นเทคนิคเก่าในการสื่อสารระหว่างเว็บแอปพลิเคชันที่ทำงานบนโดเมนที่แตกต่างกัน

ด้วย JSONP คุณจะต้องใช้แท็กสคริปต์ HTML ในหน้าไคลเอ็นต์ แท็กสคริปต์จะโหลดไฟล์ JavaScript ภายนอกหรือฝังโค้ด JavaScript โดยตรงในหน้าเว็บ HTML เนื่องจากสคริปต์ไม่ได้อยู่ภายใต้นโยบายต้นทางเดียวกัน คุณจึงสามารถดึงข้อมูลข้ามต้นทางผ่านโค้ด JavaScript ได้

อย่างไรก็ตามข้อมูลจะต้องอยู่ในรูปแบบ JSON นอกจากนี้ JSONP มีความปลอดภัยน้อยกว่า Cross-Origin Resource Sharing (CORS) เพราะอาศัยความน่าเชื่อถือของโดเมนภายนอกเพื่อให้ข้อมูลที่ปลอดภัย

เบราว์เซอร์สมัยใหม่ได้เพิ่มคุณลักษณะด้านความปลอดภัยบางอย่าง ดังนั้นโค้ดเก่าที่มี JSONP จะไม่สามารถใช้งานได้อีกต่อไป CORS เป็นมาตรฐานของเว็บไซต์ทั่วโลกในปัจจุบันสำหรับการควบคุมการเข้าถึงแบบ Cross-Origin

อ่านเกี่ยวกับ JavaScript »

อ่านเพิ่มเติมเกี่ยวกับ JSON »

อะไรคือหลักปฏิบัติที่ดีที่สุดสำหรับ CORS

คุณควรให้ความสำคัญกับสิ่งต่อไปนี้เมื่อคุณกำหนดค่า Cross-Origin Resource Sharing (CORS) บนเซิร์ฟเวอร์ของคุณ

กำหนดรายการการเข้าถึงให้เหมาะสม

เป็นการดีที่สุดเสมอที่จะให้สิทธิ์การเข้าถึงแต่ละโดเมนโดยใช้การคั่นด้วยเครื่องหมายจุลภาค หลีกเลี่ยงการใช้สัญลักษณ์แทน เว้นแต่คุณต้องการทำให้ API เป็นสาธารณะ มิฉะนั้นการใช้สัญลักษณ์แทนและการแสดงออกปกติอาจสร้างช่องโหว่

ตัวอย่างเช่น สมมติว่าคุณเขียนนิพจน์ปกติที่อนุญาตให้เว็บไซต์ทั้งหมดที่มี Suffix ว่า permitted-website.com เข้าถึงได้ ด้วยนิพจน์นี้ คุณอนุญาตให้ api.permitted-website.com และ news.permitted-website.com เข้าถึงได้ แต่คุณยังให้สิทธิ์การเข้าถึงเว็บไซต์ที่ไม่ได้รับอนุญาตโดยไม่ได้ตั้งใจซึ่งอาจใช้โดเมน เช่น maliciouspermitted-website.com ด้วยเช่นกัน

หลีกเลี่ยงการใช้ Null Origin ในรายการของคุณ

เบราว์เซอร์บางแห่งส่งค่า Null ในส่วนหัวคำขอสำหรับสถานการณ์บางอย่าง เช่น การร้องขอไฟล์หรือคำขอจากโฮสต์ภายใน

แต่คุณไม่ควรมีค่า Null ในรายการการเข้าถึงของคุณ นอกจากนี้ มันยังทำให้เกิดความเสี่ยงด้านความปลอดภัยเนื่องจากคำขอที่ไม่ได้รับอนุญาตที่มีส่วนหัว Null อาจได้รับการเข้าถึง

AWS ตอบรับต่อข้อกำหนดด้าน CORS ของคุณได้อย่างไร

บริการมากมายของเรามีการรองรับ Cross-Origin Resource Sharing (CORS) ในตัว ดังนั้นคุณสามารถควบคุมการเข้าถึงแบบ Cross-Origin ที่ไปยัง API และทรัพยากรที่โฮสต์บน Amazon Web Services (AWS) ได้

นี่คือบางส่วนของบริการ AWS ที่รองรับ CORS:

Amazon Simple Storage Service (Amazon S3) เป็นบริการจัดเก็บวัตถุที่มีระดับราคาตามประสิทธิภาพการจัดเก็บข้อมูลสำหรับทุกกรณีการใช้งานพื้นที่เก็บข้อมูล Amazon S3 ช่วยให้คุณสามารถสร้างเอกสารที่มีการกำหนดค่า CORS ด้วยกฎระเบียบที่ระบุต้นทางที่คุณจะอนุญาตให้เข้าถึงข้อมูล S3 การดำเนินงาน (รูปแบบ HTTP) ที่คุณจะสนับสนุนสำหรับแต่ละต้นทาง และข้อมูลการดำเนินงานเฉพาะอื่นๆ คุณสามารถเพิ่มกฎได้ถึง 100 กฎในการกำหนดค่า
เกตเวย์ของ Amazon API เป็นบริการที่มีการจัดการเต็มรูปแบบ ซึ่งทำให้นักพัฒนาสามารถสร้าง เผยแพร่ บำรุงรักษา เฝ้าติดตาม และรักษาความปลอดภัยของ API ทุกๆ ขนาดได้โดยง่าย คุณสามารถเปิดใช้งาน CORS สำหรับ REST API ของคุณได้ด้วยคลิกเดียวที่คอนโซลเกตเวย์ของ Amazon API โดยตรง

เริ่มต้นใช้งาน API บน AWS ด้วยการสร้างบัญชีวันนี้