CORS là gì?

Scrapeless Agent Browser chạy các phiên trình duyệt có thể quan sát cách mà một trang web hoạt động dưới các quy tắc đa nguồn của trình duyệt.

Chia sẻ tài nguyên giữa các nguồn, hoặc CORS, là một cơ chế tiêu đề HTTP cho phép máy chủ chỉ định khi nào trình duyệt có thể hiển thị phản hồi cho một đoạn kịch bản đang chạy trên một nguồn khác. Một nguồn là sự kết hợp của sơ đồ, máy chủ và cổng. CORS quan trọng vì một trang được tải từ một nguồn thường muốn gọi một API ở một nguồn khác; trình duyệt hạn chế việc đọc đó trừ khi phản hồi thỏa mãn các quy tắc CORS.

Một lỗi CORS dễ bị hiểu nhầm là một sự cố mạng hoặc một vấn đề xác thực API. Yêu cầu có thể đã đến máy chủ, và máy chủ có thể đã trả về dữ liệu, trong khi trình duyệt từ chối cung cấp dữ liệu đó cho kịch bản của trang. Chẩn đoán quyết định của trình duyệt tách biệt với quyết định kinh doanh của API.

Ranh giới nguồn gốc CORS Áp dụng cho

Hai URL chỉ chia sẻ một nguồn gốc khi sơ đồ, máy chủ và cổng của chúng khớp nhau. Chuyển từ http sang https, chuyển sang một tên miền phụ, hoặc sử dụng một cổng khác sẽ tạo ra một nguồn gốc khác. Một trang có thể thực hiện một số yêu cầu ngang nguồn gốc mà không cần truy cập vào nội dung phản hồi. The Hướng dẫn CORS của MDN mô tả điều này như một sự thư giãn có kiểm soát của chính sách cùng nguồn cho các yêu cầu HTTP xuyên nguồn được thực hiện bởi các tập lệnh.

Máy chủ giao tiếp quyền truy cập bằng các tiêu đề phản hồi như Access-Control-Allow-Origin. Một trình duyệt so sánh giá trị với nguồn gốc của trang yêu cầu. Trình duyệt là điểm thực thi cho kịch bản của trang. Một khách hàng dòng lệnh có thể gửi yêu cầu HTTP mà không áp dụng các quy tắc CORS của trình duyệt, vì vậy một phản hồi thành công từ dòng lệnh không chứng minh rằng một trang web có thể đọc cùng một tài nguyên.

CORS không phải là một hệ thống ủy quyền. Một máy chủ vẫn phải xác thực người gọi và kiểm tra quyền truy cập tài nguyên. Việc cấp quyền cho một nguồn để đọc phản hồi là khác so với việc quyết định rằng một người dùng có thể xem hồ sơ tài khoản riêng tư. Hãy coi những điều đó như là hai điều khiển riêng biệt và kiểm tra cả hai. Một cấu hình CORS quá dễ dãi không thể thay thế an toàn việc kiểm tra quyền truy cập phía máy chủ.

Yêu cầu đơn giản và Yêu cầu trước chuyến bay

Đối với một số yêu cầu giữa các nguồn khác nhau, trình duyệt gửi yêu cầu thực tế và sau đó kiểm tra quyền phản hồi. Các yêu cầu khác cần một yêu cầu trước: trình duyệt đầu tiên gửi một yêu cầu OPTIONS để hỏi xem phương thức và tiêu đề đề xuất có được phép hay không. định nghĩa preflight xác định các trường Origin và Access-Control-Request-Method, với Access-Control-Request-Headers khi cần thiết.

Một yêu cầu với tiêu đề ủy quyền tùy chỉnh hoặc kiểu nội dung không nằm trong danh sách an toàn có thể kích hoạt preflight. Nếu preflight thất bại, trình duyệt sẽ không gửi yêu cầu thực tế liên quan. Sự khác biệt đó quan trọng trong quá trình chẩn đoán. Một bản ghi máy chủ ứng dụng mà không có POST vẫn có thể hiển thị một yêu cầu OPTIONS, và một nhà phát triển chỉ kiểm tra tuyến đường POST có thể bỏ lỡ điểm từ chối.

Phê duyệt preflight được giới hạn theo phương thức, tiêu đề, nguồn gốc và quy tắc tài nguyên được yêu cầu. Nó không có nghĩa là hoạt động kinh doanh sau đó sẽ thành công. Yêu cầu thực tế có thể vẫn thất bại trong việc xác thực hoặc kiểm tra. Ngược lại, một lần phê duyệt preflight thất bại không phải là bằng chứng rằng API đã từ chối dữ liệu của người dùng; yêu cầu chứa dữ liệu có thể đã không bao giờ đến được ứng dụng.

Thông tin xác thực Thay đổi Quy tắc Phản hồi

Một yêu cầu xuyên nguồn có thể liên quan đến cookie hoặc các thông tin xác thực khác do trình duyệt quản lý. Khi một trang mong đợi một phản hồi có thông tin xác thực, một giá trị Access-Control-Allow-Origin đại diện cho wildcard là không đủ. Máy chủ phải xác định một nguồn được phép và áp dụng quy tắc phản hồi thông tin xác thực liên quan. Hướng dẫn lỗi thông tin xác thực MDN giải thích lý do tại sao sự kết hợp giữa ký tự đại diện và thông tin xác thực thất bại.

Chế độ thông tin xác thực của yêu cầu và chính sách cookie là các đầu vào tách biệt. Một trình duyệt có thể bỏ qua một cookie do cài đặt SameSite, Secure hoặc miền của nó ngay cả khi các tiêu đề CORS trông có vẻ đúng. Một lỗi xác thực sau đó có thể xuất hiện sau khi kiểm tra CORS thành công. Kiểm tra yêu cầu và phản hồi trong công cụ phát triển thay vì thay đổi các trường CORS để bù đắp cho một cookie chưa bao giờ được gửi.

Cho phép mọi nguồn yêu cầu một cách động mà không có xác thực có thể làm lộ những phản hồi nhạy cảm đến các trang không đáng tin cậy. Duy trì một chính sách nguồn rõ ràng cho dữ liệu yêu cầu thông tin xác thực, và đảm bảo rằng các bộ nhớ đệm thay đổi thích hợp khi các phản hồi phụ thuộc vào Origin. Đánh giá bảo mật nên bao gồm tài nguyên được xác thực thực sự, chứ không chỉ là một điểm cuối thử nghiệm trả về văn bản công khai.

Cách Chẩn Đoán Lỗi CORS Trình Duyệt

Bắt đầu với nguồn trang và nguồn đích cuối cùng, bao gồm cả các chuyển hướng. Một yêu cầu chuyển hướng đến một máy chủ đăng nhập có thể cần một chính sách khác so với URL API gốc. Trong công cụ phát triển của trình duyệt, hãy kiểm tra việc trao đổi OPTIONS nếu có, yêu cầu thực tế nếu nó đã được gửi, và các tiêu đề phản hồi. Tiếp tục Danh mục lỗi CORS bản đồ các tin nhắn console chung đến các trường phản hồi thiếu hoặc không tương thích.

Một cuộc gọi fetch không thành công có thể chỉ hiển thị một lỗi chung cho JavaScript trong khi bảng điều khiển chứa lý do CORS cụ thể. Ghi lại cả hai bề mặt. Kiểm tra xem phản hồi có thiếu Access-Control-Allow-Origin, chỉ định một nguồn khác, bỏ qua một phương thức hoặc tiêu đề được phép, hoặc xung đột với chế độ chứng thực hay không. Thực hiện một thay đổi cấu hình tại máy chủ mà bạn kiểm soát, rồi kiểm tra lại cùng một trang và yêu cầu.

Không thêm tiện ích mở rộng trình duyệt hoặc vô hiệu hóa kiểm tra bảo mật như một cách sửa lỗi sản xuất. Thay đổi cục bộ như vậy có thể che giấu một lỗi tích hợp trong khi để lại người dùng thực sự bị chặn. Nếu API là bên thứ ba và không cho phép nguồn trang của bạn, hãy sử dụng một kiến trúc tích hợp phía máy chủ được hỗ trợ hoặc yêu cầu nhà cung cấp một lộ trình truy cập trình duyệt được tài liệu hóa.

CORS trong Tự động hóa Trình duyệt và Thu thập Dữ liệu

Một phiên duyệt web thực thi các tập lệnh trang dưới các quy tắc bảo mật của trình duyệt. Trình duyệt Đại lý Không Rác cung cấp việc thực thi trình duyệt điều khiển từ xa, vì vậy một trang thực hiện các yêu cầu chéo nguồn có thể được quan sát trong môi trường đó. The Giới thiệu về Trình duyệt Đại lý mô tả sản phẩm trình duyệt. Nó không biến phản hồi API không được phép thành phản hồi được phép.

Một yêu cầu dữ liệu phía máy chủ có một ranh giới CORS khác: CORS của trình duyệt không quản lý một bên HTTP client phía backend. Các điều khiển khác vẫn áp dụng, bao gồm thông tin đăng nhập của nhà cung cấp, quyền truy cập đối tượng và chính sách tỷ lệ. Chọn trình duyệt khi bạn cần kiểm tra hoặc tái tạo hành vi của trang. Chọn một API máy chủ đã được tài liệu khi nhiệm vụ là trao đổi dữ liệu trực tiếp và nhà cung cấp hỗ trợ điều đó.

Các liên quan hướng dẫn kiểm tra mạng trình duyệt thảo luận về việc quan sát các yêu cầu được sử dụng bởi một trang. Quan sát không phải là sự cho phép để sử dụng các điểm cuối riêng tư bên ngoài ngữ cảnh dự kiến của chúng. Khi xem xét một dấu vết trình duyệt, hãy tập trung vào dữ liệu công khai hoặc dữ liệu được ủy quyền rõ ràng cần thiết cho nhiệm vụ và giữ thông tin xác thực ra khỏi các nhật ký chia sẻ.

Danh sách kiểm tra quyết định CORS thực tế

Xác định chủ sở hữu của tài nguyên và nguồn gốc của trang gọi nó. Quyết định xem script trình duyệt có thực sự cần đọc phản hồi hay không. Nếu có, cấu hình máy chủ tài nguyên để chỉ cho phép nguồn gốc, phương thức, tiêu đề và hành vi thông tin xác thực đã định. Nếu không, giữ cuộc gọi trên một backend được kiểm soát nơi trình duyệt không bao giờ cần truy cập trực tiếp vào API bên thứ ba.

Kiểm tra phương pháp chính xác và tiêu đề được sử dụng trong sản xuất. Một yêu cầu GET mà không có trường tùy chỉnh có thể hoạt động trong khi một yêu cầu JSON POST với tiêu đề xác thực kích hoạt kiểm tra trước. Cũng cần kiểm tra đường dẫn lỗi: một phản hồi thành công với tiêu đề CORS chính xác là không đủ nếu các lỗi xác thực hoặc chuyển hướng bị thiếu. Người dùng trình duyệt cần sự thất bại thực sự phải xuất hiện và có thể chẩn đoán.

Cuối cùng, hãy tách ba quan sát trong ghi chú sự cố: có thực hiện yêu cầu mạng hay không, máy chủ có chấp nhận thao tác hay không, và trình duyệt có tiết lộ phản hồi cho mã trang hay không. Những câu trả lời đó có thể khác nhau. Giữ chúng riêng biệt ngăn chặn vấn đề chính sách của trình duyệt bị “sửa chữa” bằng cách làm yếu quyền xác thực máy chủ không liên quan.

Kết luận

CORS cho phép một máy chủ tài nguyên chỉ định những nguồn gốc khác nào có thể đọc phản hồi của nó từ các script trên trình duyệt. Tác động của nó phụ thuộc vào nguồn gốc của trang, hình dạng yêu cầu, kiểm tra trước và chế độ xác thực. Chẩn đoán những phần đó trong trình duyệt trong khi giữ nguyên xác thực và các kiểm tra quyền truy cập từ phía máy chủ.