Phần 1: Tìm Hiểu Về Lịch Sử CORS và Cách Thiết Lập CORS Đúng Cách

Chào mọi người,

Mở bài

Có lẽ các bạn đang gặp rắc rối trong việc thiết lập CORS cho server của mình và tìm kiếm cách sửa lỗi này? Nếu đúng như vậy, chúc mừng bạn đã tìm đến bài viết này. Google đã đưa bạn tới đây với các cụm từ như:

Google Search: Cách sửa lỗi CORS trong Spring Boot, Cách sửa lỗi CORS trong Express.js hoặc thậm chí là: Fix lỗi CORS trong ....

Nếu bạn đang tìm kiếm thông tin bằng tiếng Việt, thì rất có thể bạn đang đọc đúng nơi rồi. Vậy hãy tìm một chỗ ngồi thoải mái, thưởng thức một miếng bánh và một ly nước, và cùng đọc hết bài viết này để lần sau không phải quay lại tìm kiếm nữa nhé! 😆

Bạn có nhận thấy thông báo lỗi này quen thuộc không?

"Access to fetch at 'http://<server_domain_api>/api/users' from origin 'https://<client_domain>.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No Access-Control-Allow-Origin header is present on the requested resource."

Chắc hẳn bạn đã gặp phải các thông báo lỗi tương tự ít nhất một lần.

Thật khó chịu khi bạn đã hoàn thành việc phát triển và thử nghiệm mọi thứ trên Postman, nhưng khi tích hợp APIs vào client, mọi thứ lại không như dự kiến. Nào, chúng ta hãy cùng nhau đi sâu vào bài viết!

Trở Về Lịch Sử CORS

1. Bối Cảnh Lịch Sử

Trước khi có khái niệm CORS (Cross-Origin Resource Sharing), các trang web chủ yếu phục vụ các tài liệu tĩnh và thường chỉ yêu cầu tài nguyên từ chính server mà chúng được lưu trữ. Tuy nhiên, khi trang web bắt đầu trở nên phức tạp, nhu cầu truy cập tài nguyên từ các nguồn khác (cross-origin) đã xuất hiện. Nguy cơ bảo mật từ những truy cập này đã khiến cho các trình duyệt cần một cơ chế bảo vệ.

2. Chính Sách Cùng Nguồn (SOP)

Same-Origin Policy (Chính Sách Cùng Nguồn) là một nguyên tắc bảo mật quan trọng xuất hiện từ cuối những năm 1990, nhằm bảo vệ tài nguyên web khỏi các truy cập trái phép từ một domain khác.

Chính Sách Cùng Nguồn quy định rằng: Một tài nguyên từ một origin chỉ được phép truy cập các tài nguyên khác từ cùng một origin.

Ví dụ:

Một trang tại https://example.com chỉ có thể gửi yêu cầu đến các tài nguyên tại cùng domain đó.
Các yêu cầu đến https://api.example.com sẽ bị chặn do khác domain.

Mục Đích Của SOP Là:

Ngăn chặn Cross-Site Scripting (XSS).
Ngăn chặn Cross-Site Request Forgery (CSRF).

Hạn Chế Của SOP:

SOP hạn chế khả năng truy cập tài nguyên từ các nguồn khác, điều này không phù hợp với nhu cầu của các ứng dụng web hiện đại.

3. Nhu Cầu Giao Tiếp Giữa Các Origin

Giai đoạn phát triển web vào đầu những năm 2000 đã dẫn đến nhu cầu cao hơn về việc truy cập tài nguyên từ nhiều origin khác nhau:

Sự ra đời của AJAX: Cho phép gửi yêu cầu đến server mà không cần tải lại trang, nhưng SOP hạn chế truy cập chỉ tại cùng một origin.
Các Ứng Dụng Web Đương Đại: Cần tải tài nguyên từ CDN, gửi yêu cầu đến các API công cộng, kết nối với nhiều microservices khác nhau.

4. Sự Ra Đời Của CORS

CORS được ra mắt vào năm 2005 nhằm mở rộng SOP và cho phép các server kiểm soát quyền truy cập từ các origin khác, đảm bảo vẫn bảo mật. CORS hoạt động thông qua việc server quyết định tài nguyên có thể được chia sẻ với các origin nào và trình duyệt thực hiện các yêu cầu kiểm tra (preflight).

5. Các Mốc Thời Gian Quan Trọng

1993: Giới thiệu HTML , đánh dấu việc cần thực hiện cross-origin request.
1999: Sự ra đời của AJAX.
2005: Xuất hiện tiêu chuẩn CORS.
2009: Các trình duyệt chính thức hỗ trợ CORS.
Hiện tại: CORS là tiêu chuẩn an ninh cơ bản trong lập trình web.

6. Ví Dụ Về Bảo Mật Với CORS

Giả sử bạn sử dụng dịch vụ ngân hàng tại https://bank.com. Một hacker có thể khai thác để thực hiện hành vi CSRF nếu không có cơ chế bảo vệ như CORS.

Hacker có thể tạo một trang độc hại, lợi dụng cookie phiên đăng nhập của bạn để thực hiện các hành động mà bạn không hề hay biết.
CORS sẽ ngăn chặn hành vi này bằng cách không cho phép các origin độc hại gửi yêu cầu đến server của ngân hàng.

Cấu Hình CORS Đúng Cách

Các Loại Header Trong Cấu Hình CORS

Header	Miêu Tả
`Access-Control-Allow-Origin`	Chỉ định nguồn được phép truy cập tài nguyên.
`Access-Control-Allow-Methods`	Liệt kê các phương thức HTTP được phép trong yêu cầu.
`Access-Control-Allow-Headers`	Liệt kê các headers mà client được phép gửi.
`Access-Control-Allow-Credentials`	Xác định liệu có được phép gửi thông tin nhạy cảm hay không.
`Access-Control-Expose-Headers`	Chỉ định các headers client có thể đọc từ phản hồi.
`Access-Control-Max-Age`	Thời gian mà trình duyệt có thể lưu cache phản hồi.

1. Preflight Request Là Gì?

Preflight Request là loại request HTTP mà trình duyệt gửi trước khi gửi request chính trong các tình huống cross-origin. Nó sử dụng phương thức OPTIONS và không mang dữ liệu nội dung nào.

2. Khi Nào Preflight Request Được Gửi?

Khi request là cross-origin.
Khi request không thuộc loại “Simple Request”.

3. Quy Trình Xử Lý Preflight Request

Trình duyệt gửi request Preflight đến server.
Server phản hồi lại yêu cầu.
Nếu server phản hồi ok, trình duyệt gửi request chính.

Hãy đảm bảo rằng các bạn cấu hình đúng request OPTIONS để tránh bị lỗi CORS.

Tài Liệu Đọc Thêm

Bài viết đã dài, mình sẽ tạm dừng phần 1 tại đây. Hẹn gặp lại các bạn trong phần 2, nơi chúng ta sẽ thực hiện cài đặt CORS trong Java Spring Boot. Cảm ơn các bạn đã đọc bài viết! Hy vọng nó sẽ hữu ích cho các bạn.

Sài Gòn: 00:15, ngày 19/12/2024