Mô phỏng preflight và yêu cầu thực tế từ phía máy chủ, xác định nhanh chóng vấn đề là do Allow-Origin, Allow-Headers hay credentials.
Mô phỏng CORS preflight và yêu cầu thực từ máy chủ, kiểm tra 6 tiêu đề chính, phát hiện lỗi cấu hình cross-domain chính xác, kèm mẫu code Nginx/Node.js/Spring
Đây là sự cố CORS kinh điển nhất! Bởi Postman và curl hoàn toàn không chịu ảnh hưởng của Same-Origin Policy — chúng là ứng dụng khách HTTP, không phải trình duyệt, không chặn phản hồi, cũng không tự động gửi OPTIONS preflight. Lỗi xuyên miền là cơ chế bảo mật riêng của trình duyệt, chỉ môi trường JavaScript của trình duyệt mới kiểm tra CORS. Postman gọi thành công chỉ chứng minh giao diện có thể trả về dữ liệu, không chứng minh CORS chính xác. Bạn cần sử dụng trình duyệt hoặc công cụ này (mô phỏng quy trình CORS phía máy chủ) để kiểm tra
99% lỗi CORS là vấn đề cấu hình phía backend. Phía frontend có thể làm được rất ít, bản chất CORS là máy chủ cấp quyền cho trình duyệt thông qua tiêu đề. Phía frontend chỉ có thể đặt withCredentials, không thể nào né tránh hạn chế bảo mật. Việc sử dụng proxy của frontend là lừa trình duyệt coi là cùng nguồn gốc, không phải sửa CORS thực sự. Môi trường sản xuất vẫn cần backend cấu hình CORS chính xác
Bởi GET thường đáp ứng simple request, trình duyệt gửi trực tiếp; còn POST nếu gửi Content-Type: application/json (90% giao diện POST) sẽ không phải simple request, sẽ kích hoạt OPTIONS preflight. Yêu cầu preflight cần tiêu đề CORS chính xác. Nhiều người chỉ cấu hình tiêu đề cho GET/POST mà không xử lý OPTIONS. Bản thân PUT/DELETE/PATCH cũng không phải phương thức đơn giản, chắc chắn cần preflight
Môi trường phát triển có nhiều cách: ①proxy tích hợp của framework (devServer.proxy, server.proxy): ủy quyền yêu cầu đến cùng nguồn; ②tắt tham số bảo mật trình duyệt với --disable-web-security, chỉ giới hạn thử nghiệm tại máy; ③backend cấu hình CORS cho phép localhost (đề xuất). Môi trường sản xuất bắt buộc phải backend cấu hình CORS chính xác: danh sách trắng, Allow-Methods/Allow-Headers/Allow-Credentials, Vary: Origin hoặc sử dụng gateway/Nginx quản lý tập trung
Không được. Tiêu đề này chỉ có thể có một giá trị, duy nhất là một nguồn cụ thể hoặc *. Trình duyệt sẽ không chấp nhận nhiều nguồn. Cách đúng là: máy chủ duy trì danh sách trắng, mỗi lần nhận yêu cầu đọc Origin, kiểm tra xem có trong danh sách trắng không, nếu có thì trả về Access-Control-Allow-Origin là chính giá trị Origin đó, đồng thời Vary: Origin. Đừng cố trả về nhiều tiêu đề hoặc phân cách bằng dấu phẩy
OPTIONS preflight không cần trả về bất kỳ logic nghiệp vụ và nội dung nào, chỉ cần tiêu đề CORS chính xác và 200/204 là đủ. Cách thực hành tốt nhất là: chặn OPTIONS trực tiếp tại Nginx/gateway, trả về 204 No Content và tiêu đề CORS chính xác, không cần chuyển tiếp đến backend, giảm tải và tránh 405. Nhưng phải đảm bảo tiêu đề CORS của OPTIONS nhất quán với yêu cầu thực
Yêu cầu xuyên miền mang Cookie cần đáp ứng ba điều kiện: ①withCredentials=true hoặc credentials: 'include'; ②Allow-Credentials: true; ③Allow-Origin phải là nguồn gốc cụ thể (không được *). Thiếu một cũng không được. Ngoài ra Cookie phải đặt SameSite=None; Secure (HTTPS) mới có thể gửi xuyên miền; SameSite=Lax/Strict sẽ không mang; thuộc tính Domain phải chính xác; cũng cần lưu ý chính sách Cookie của bên thứ ba
CORS là nới lỏng hạn chế xuyên miền, CSRF là tấn công giả mạo yêu cầu xuyên trang, hai khái niệm khác nhau. Cấu hình CORS đúng cách sẽ không trực tiếp gây ra CSRF — CORS chỉ cho phép JS đọc phản hồi, còn CSRF là kẻ tấn công dụ người dùng gửi yêu cầu không hay biết, những yêu cầu này dù không có CORS cũng sẽ được gửi kèm Cookie. Phòng chống CSRF cần dùng CSRF Token, SameSite Cookie, kiểm tra Origin/Referer, đừng phòng CSRF bằng cách tắt CORS. Nhưng nếu Allow-Origin là * và cho phép credentials sẽ mở rộng rủi ro CSRF, vì vậy khi gửi credentials tuyệt đối không được dùng *
Tải tài nguyên bằng <img>, <script>, <link> thông thường không gặp sự cố CORS, là "tài nguyên nhúng" không phải AJAX, trình duyệt cho phép tải nhưng JS không thể đọc nội dung. Nhưng nếu muốn sử dụng Canvas xử lý hình ảnh xuyên miền hoặc dùng fetch/XHR đọc nội dung thì cần CORS và thêm thuộc tính crossorigin. Tải tệp xuyên miền không cần CORS. Chuyển hướng sẽ ảnh hưởng đến CORS: nếu OPTIONS trả về 3xx trình duyệt sẽ từ chối trực tiếp (Preflight redirect not allowed)
Điểm chính: ①sử dụng map đối sánh Origin danh sách trắng, đặt $cors_origin động; ②OPTIONS trả về 204 trực tiếp không chuyển tiếp; ③add_header phải thêm always để đảm bảo phản hồi lỗi cũng có tiêu đề; ④thêm Vary: Origin; ⑤cấu hình đúng Allow-Methods/Allow-Headers/Credentials. Mẫu cấu hình có thể tìm thấy trong hướng dẫn sửa lỗi của công cụ này. Cho Nginx, Apache, Node.js Express, Spring Boot, Flask/Django, Koa, Go Gin chúng tôi đều có mẫu đã được kiểm chứng
Các bước xác nhận: ①trước tiên sử dụng công cụ này kiểm tra trực tuyến; ②mở DevTools Network, đánh dấu Disable cache, kích hoạt yêu cầu, kiểm tra tiêu đề OPTIONS và yêu cầu thực; ③xem Console có lỗi không; ④kiểm tra các tình huống khác nhau: GET không tiêu đề, POST dạng application/json, PUT/DELETE, có/không Cookie, có tiêu đề tùy chỉnh; ⑤sử dụng curl mô phỏng OPTIONS: curl -i -X OPTIONS -H "Origin: https://sourcecuaban.com" https://api.example.com/endpoint
Các trình duyệt khác nhau có sự khác biệt trong chi tiết CORS: ①Safari giới hạn Max-Age nghiêm ngặt hơn, chính sách Cookie (ITP) cũng nghiêm ngặt hơn; ②Chrome kiểm tra ký tự đại diện khi gửi credentials nghiêm ngặt hơn, không cho phép *; ③IE11 dùng XDomainRequest thay vì XMLHttpRequest có nhiều hạn chế; ④xử lý Vary, chuyển hướng, tiêu đề bảo mật có khác biệt tinh tế. Cách khắc phục là cấu hình nghiêm ngặt theo quy định, đừng dựa vào hành vi của một trình duyệt nào
Đề xuất 3600 (1 giờ) đến 86400 (24 giờ). Quá ngắn (60 giây): bộ đệm hết nhanh, gửi OPTIONS thường xuyên, tăng thời gian và tải máy chủ. Quá dài (một năm): sau khi cập nhật cấu hình bộ đệm cũ có thể còn lâu, khiến cấu hình mới không hoạt động. Chrome/Firefox tự động cắt giá trị vượt quá 86400 xuống 86400. Môi trường phát triển có thể đặt -1 tắt đệm để thuận tiện debug
WebSocket (ws:// và wss://) không chịu ảnh hưởng từ cơ chế CORS của HTTP, vì là giao thức độc lập. Nhưng giai đoạn bắt tay là yêu cầu HTTP, máy chủ có thể kiểm tra Origin để quyết định cho phép kết nối — đây là kiểm soát quyền ở cấp độ WebSocket, không phải CORS tiêu chuẩn, nhưng nguyên tắc tương tự. Nếu WebSocket bị từ chối cần kiểm tra cấu hình kiểm tra Origin của máy chủ WebSocket, không phải tiêu đề CORS của HTTP
Công cụ này mô phỏng quy trình preflight và yêu cầu thực theo quy định W3C CORS nghiêm ngặt phía máy chủ, logic về cơ bản nhất quán với trình duyệt hiện đại. Nếu công cụ vượt qua nhưng trình duyệt vẫn lỗi, nguyên nhân có thể: ①trình duyệt lưu đệm kết quả cũ, thử Ctrl+F5 làm mới hoặc xóa bộ đệm; ②tiện ích mở rộng trình duyệt sửa đổi hoặc chặn yêu cầu; ③các cài đặt điền trong công cụ không nhất quán với những gì frontend thực sự gửi; ④bộ đệm nút CDN/proxy không nhất quán; ⑤trình duyệt có chính sách bảo mật đặc biệt (nội dung hỗn hợp, hạn chế file://)
