Kiến thức Hữu ích 😍

CORS Là Gì? Giải Thích Chi Tiết Cross-Origin Resource Sharing Trong Web Development

Kiến thức về Bảo mật

Trong thế giới lập trình web, bảo mật luôn là một ưu tiên hàng đầu. Khi các ứng dụng web ngày càng phức tạp và kết nối với nhiều dịch vụ bên ngoài, việc kiểm soát cách tài nguyên được chia sẻ trở nên vô cùng quan trọng. Một trong những thách thức phổ biến nhất mà các lập trình viên thường gặp phải là vấn đề liên quan đến truy cập tài nguyên từ các nguồn (domain) khác nhau. Đây là lúc cơ chế CORS là gì (Cross-Origin Resource Sharing) phát huy vai trò của mình. CORS không chỉ là một giải pháp kỹ thuật, mà còn là một cơ chế bảo mật thiết yếu, giúp trình duyệt và máy chủ quyết định liệu một yêu cầu từ một tên miền khác có an toàn và được phép hay không. Bài viết này sẽ đi sâu vào định nghĩa, cơ chế hoạt động, tầm quan trọng, các vấn đề thường gặp và cách xử lý lỗi CORS một cách hiệu quả nhất.

Định nghĩa CORS và thuật ngữ Cross-Origin Resource Sharing

CORS là gì?

CORS, viết tắt của Cross-Origin Resource Sharing, là một cơ chế cho phép các tài nguyên bị hạn chế trên một trang web (như font chữ, JavaScript, API) được yêu cầu từ một tên miền khác ngoài tên miền mà trang web đó đang phục vụ. Nói một cách đơn giản, CORS là một tập hợp các quy tắc và tiêu đề HTTP mà máy chủ sử dụng để “nói” với trình duyệt rằng nó cho phép một ứng dụng web chạy tại một nguồn (origin) A được phép truy cập tài nguyên tại nguồn B.

Hình minh họa

Mục đích chính của CORS trong môi trường web hiện đại là tạo ra một cách thức linh hoạt nhưng vẫn an toàn để vượt qua Chính sách Cùng Nguồn gốc (Same-Origin Policy). Nó cho phép các ứng dụng web hiện đại (Single Page Applications – SPAs) có thể gọi API từ các máy chủ khác, nhúng nội dung từ các dịch vụ bên thứ ba, và xây dựng các kiến trúc microservices một cách hiệu quả mà không làm suy yếu hàng rào bảo mật cơ bản của trình duyệt. Tham khảo thêm Xss là gì để hiểu về các rủi ro bảo mật trong phát triển web.

Tại sao cần có Cross-Origin Resource Sharing?

Để hiểu tại sao CORS lại cần thiết, chúng ta phải nói về “kẻ tiền nhiệm” của nó: Chính sách Cùng Nguồn gốc (Same-Origin Policy – SOP). Đây là một tính năng bảo mật quan trọng được tích hợp trong tất cả các trình duyệt web hiện đại. SOP quy định rằng một tập lệnh (script) từ một nguồn chỉ có thể yêu cầu tài nguyên từ chính nguồn đó. Một “nguồn” được định nghĩa bởi sự kết hợp của ba yếu tố: giao thức (http, https), tên miền (domain), và cổng (port). Nếu có bất kỳ sự khác biệt nào trong ba yếu tố này, chúng sẽ được coi là hai nguồn khác nhau. Ví dụ, http://azweb.vn và https://azweb.vn là hai nguồn khác nhau vì chúng khác giao thức. Tương tự, http://blog.azweb.vn và http://www.azweb.vn cũng là hai nguồn khác nhau.

Hình minh họa

Chính sách này cực kỳ hiệu quả trong việc ngăn chặn các trang web độc hại đọc dữ liệu nhạy cảm từ các trang web khác mà bạn đang mở. Tuy nhiên, trong bối cảnh phát triển web hiện đại, giới hạn này lại gây ra nhiều phiền toái. Các ứng dụng cần gọi API từ các máy chủ khác nhau, sử dụng font chữ từ Google Fonts, hoặc tải script từ một CDN. Nếu không có CORS, những hoạt động này sẽ bị trình duyệt chặn lại, làm cho việc xây dựng các ứng dụng web phong phú và tương tác trở nên bất khả thi. CORS ra đời chính là để giải quyết bài toán này, cung cấp một cơ chế tiêu chuẩn để các máy chủ có thể nới lỏng chính sách SOP một cách có kiểm soát. Để hiểu sâu hơn về các lỗ hổng bảo mật có thể gặp phải khi không kiểm soát truy cập hợp lý, bạn có thể tìm hiểu bài viết Lỗ hổng bảo mật.

Cách hoạt động của CORS trong lập trình web

Cơ chế kiểm soát truy cập cross-origin

CORS hoạt động dựa trên sự trao đổi thông tin qua các HTTP header giữa trình duyệt và máy chủ. Khi một ứng dụng web cố gắng thực hiện một yêu cầu cross-origin, trình duyệt sẽ tự động thêm một header Origin vào yêu cầu, chỉ định nguồn gốc của yêu cầu đó (ví dụ: Origin: https://client.azweb.vn).

Hình minh họa

Cơ chế này được chia thành hai loại yêu cầu chính: yêu cầu đơn giản (simple request) và yêu cầu tiền kiểm (preflight request). Yêu cầu đơn giản chỉ áp dụng cho một số trường hợp nhất định (ví dụ: phương thức GET, HEAD, POST với một số loại Content-Type cụ thể). Đối với các yêu cầu phức tạp hơn, chẳng hạn như sử dụng các phương thức PUT, DELETE hoặc các header tùy chỉnh, trình duyệt sẽ tự động gửi một yêu cầu “tiền kiểm” (preflight request) bằng phương thức OPTIONS. Yêu cầu OPTIONS này hỏi máy chủ xem yêu cầu thực tế sắp được gửi có được phép hay không. Máy chủ sẽ trả lời với các header như Access-Control-Allow-Origin, Access-Control-Allow-Methods, và Access-Control-Allow-Headers để cho trình duyệt biết những gì được chấp nhận. Để tăng cường bảo mật và xác thực khi trao đổi dữ liệu qua API, bạn có thể xem thêm bài viết về Jwt là gì.

Quy trình trao đổi dữ liệu qua CORS

Hãy cùng xem xét một quy trình trao đổi dữ liệu CORS điển hình. Giả sử một ứng dụng web tại https://my-app.com muốn lấy dữ liệu từ một API tại https://api.azweb.vn/data.

Yêu cầu tiền kiểm (Preflight Request): Vì đây là một yêu cầu API có thể phức tạp, trình duyệt sẽ bắt đầu bằng cách gửi một yêu cầu OPTIONS đến https://api.azweb.vn/data. Yêu cầu này sẽ chứa các header như Origin: https://my-app.com, Access-Control-Request-Method: GET, và Access-Control-Request-Headers: X-Custom-Header. Về cơ bản, trình duyệt đang hỏi: “Này server, một ứng dụng từ my-app.com muốn gửi một yêu cầu GET với một header tùy chỉnh là X-Custom-Header. Điều đó có được phép không?”
Phản hồi tiền kiểm (Preflight Response): Máy chủ api.azweb.vn nhận được yêu cầu OPTIONS. Nếu nó được cấu hình để cho phép yêu cầu này, nó sẽ trả lời với một mã trạng thái 200 OK và các header CORS quan trọng. Ví dụ: Access-Control-Allow-Origin: https://my-app.com, Access-Control-Allow-Methods: GET, POST, OPTIONS, Access-Control-Allow-Headers: X-Custom-Header. Header này có nghĩa là: “Được chứ! Tôi cho phép các yêu cầu GET, POST, OPTIONS từ nguồn https://my-app.com, và tôi cũng chấp nhận header X-Custom-Header.”
Yêu cầu thực tế (Actual Request): Sau khi nhận được phản hồi tiền kiểm tích cực, trình duyệt biết rằng yêu cầu thực tế là an toàn để gửi đi. Bây giờ, nó sẽ gửi yêu cầu GET thực sự đến https://api.azweb.vn/data, kèm theo header Origin: https://my-app.com và X-Custom-Header.
Phản hồi thực tế (Actual Response): Máy chủ xử lý yêu cầu GET, lấy dữ liệu và gửi lại cho trình duyệt. Phản hồi này cũng phải chứa header Access-Control-Allow-Origin: https://my-app.com để xác nhận lần cuối rằng việc chia sẻ tài nguyên này là hợp lệ. Nếu không có header này trong phản hồi cuối cùng, trình duyệt cũng sẽ từ chối và báo lỗi CORS.

Hình minh họa

Tầm quan trọng của CORS trong bảo mật web

Ngăn chặn tấn công giả mạo (CSRF)

Một trong những vai trò bảo mật quan trọng nhất của CORS là góp phần ngăn chặn các cuộc tấn công giả mạo yêu cầu chéo trang (Cross-Site Request Forgery – CSRF). Trong một cuộc tấn công CSRF, kẻ tấn công lừa người dùng đã đăng nhập vào một ứng dụng web hợp pháp (ví dụ: https://mybank.com) để thực hiện một hành động không mong muốn. Kẻ tấn công có thể tạo một trang web độc hại (https://evil.com) và nhúng một yêu cầu đến https://mybank.com/transfer?amount=1000&to=attacker. Khi người dùng truy cập evil.com, trình duyệt của họ sẽ tự động gửi yêu cầu này đến mybank.com kèm theo cookie xác thực, và giao dịch có thể được thực hiện mà người dùng không hề hay biết.

Hình minh họa

Chính sách Same-Origin Policy đã cung cấp một lớp bảo vệ ban đầu, nhưng CORS làm cho nó mạnh mẽ hơn. Với CORS, máy chủ của mybank.com có thể được cấu hình để chỉ chấp nhận các yêu cầu đến từ chính nguồn của nó (https://mybank.com). Khi yêu cầu từ https://evil.com đến, trình duyệt sẽ đính kèm header Origin: https://evil.com. Máy chủ mybank.com sẽ kiểm tra header này, thấy rằng nó không khớp với danh sách các nguồn được phép và từ chối yêu cầu. Bằng cách này, CORS đảm bảo rằng chỉ các ứng dụng web đáng tin cậy mới có thể thực hiện các yêu cầu thay đổi trạng thái, làm giảm đáng kể bề mặt tấn công của CSRF. Để nắm thêm về các hình thức tấn công mạng, bạn có thể đọc thêm bài Tấn công mạng là gì.

Bảo vệ dữ liệu và quyền truy cập tài nguyên

CORS đóng vai trò như một người gác cổng cho dữ liệu và tài nguyên của bạn trên web. Nếu không có CORS, chính sách Same-Origin Policy sẽ áp dụng một cách cứng nhắc: không chia sẻ gì cả. Điều này an toàn nhưng không thực tế. Ngược lại, nếu không có bất kỳ chính sách nào, bất kỳ trang web nào cũng có thể gửi yêu cầu đến máy chủ của bạn và đọc dữ liệu trả về, gây ra một lỗ hổng bảo mật nghiêm trọng. CORS cung cấp một giải pháp cân bằng hoàn hảo. Nó cho phép bạn, với tư cách là chủ sở hữu máy chủ, toàn quyền quyết định ai được phép truy cập tài nguyên của mình và họ được phép làm gì. Bạn có thể chỉ định chính xác những tên miền nào (Access-Control-Allow-Origin) được phép gửi yêu cầu. Bạn cũng có thể kiểm soát những phương thức HTTP nào (Access-Control-Allow-Methods) họ được sử dụng (ví dụ: chỉ cho phép GET để đọc dữ liệu, nhưng không cho phép POST hoặc DELETE để thay đổi dữ liệu).

Hình minh họa

Sự kiểm soát chi tiết này là vô giá. Nó cho phép bạn xây dựng các API công khai một cách an toàn, chỉ cấp quyền truy cập cho các đối tác cụ thể, hoặc đảm bảo rằng frontend và backend của ứng dụng của bạn (dù được triển khai trên các tên miền phụ khác nhau) có thể giao tiếp với nhau mà không mở cửa cho toàn bộ internet. Về cơ bản, CORS biến việc chia sẻ tài nguyên từ một rủi ro không thể kiểm soát thành một quyết định có chủ ý và an toàn. Bạn cũng nên nắm rõ các phương pháp mã hóa là gì để bảo vệ thông tin nhạy cảm.

Các vấn đề thường gặp liên quan đến CORS

Lỗi phổ biến khi không cấu hình đúng CORS

Gần như mọi nhà phát triển web đều đã từng đối mặt với thông báo lỗi CORS đáng sợ trong console của trình duyệt. Lỗi phổ biến nhất thường có dạng: Access to XMLHttpRequest at 'https://api.azweb.vn/data' from origin 'https://my-app.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Hình minh họa

Thông báo này có nghĩa là trình duyệt đã tuân thủ quy tắc và gửi yêu cầu đến máy chủ, nhưng máy chủ đã không trả về header Access-Control-Allow-Origin trong phản hồi. Điều này nói với trình duyệt rằng “Tôi không cho phép nguồn này truy cập tài nguyên của tôi”, vì vậy trình duyệt sẽ chặn phản hồi đó lại để bảo vệ người dùng.

Các nguyên nhân phổ biến dẫn đến lỗi CORS bao gồm:

Máy chủ chưa được cấu hình CORS: Đây là nguyên nhân phổ biến nhất. Lập trình viên quên hoặc không biết cách thêm các header CORS cần thiết vào cấu hình máy chủ (Apache, Nginx, Express, v.v.). Bạn có thể tham khảo cách cấu hình CORS là gì để biết chi tiết.
Cấu hình sai Access-Control-Allow-Origin: Giá trị của header này trên máy chủ không khớp với header Origin của yêu cầu. Ví dụ, máy chủ chỉ cho phép https://www.azweb.vn nhưng yêu cầu đến từ https://azweb.vn (thiếu www).
Yêu cầu tiền kiểm thất bại: Đối với các yêu cầu phức tạp, nếu yêu cầu OPTIONS bị lỗi (ví dụ, do phương thức HTTP hoặc header tùy chỉnh không được cho phép), yêu cầu thực tế sẽ không bao giờ được gửi đi.
Chuyển hướng (Redirect): Nếu một yêu cầu CORS bị chuyển hướng đến một URL khác, trình duyệt có thể xử lý nó như một yêu cầu mới và các quy tắc CORS sẽ được áp dụng lại, dễ gây ra lỗi nếu URL mới không được cấu hình đúng.

Hạn chế của CORS trong môi trường lập trình thực tế

Mặc dù CORS là một cơ chế mạnh mẽ, nó cũng có những hạn chế và thách thức nhất định trong quá trình làm việc thực tế. Một trong những hiểu lầm lớn nhất là CORS là một cơ chế bảo mật phía máy chủ. Thực tế, CORS là một cơ chế do trình duyệt thực thi. Điều này có nghĩa là các yêu cầu được gửi từ các môi trường không phải trình duyệt (như Postman, cURL, hoặc một kịch bản phía máy chủ khác) sẽ không bị ảnh hưởng bởi các quy tắc CORS. Chúng có thể truy cập tài nguyên của bạn một cách tự do nếu không có các biện pháp bảo mật khác như xác thực Jwt là gì hoặc ủy quyền (authorization). Do đó, bạn không thể chỉ dựa vào CORS để bảo vệ API của mình. Một thách thức khác là sự phức tạp trong việc gỡ lỗi. Khi lỗi CORS xảy ra, thông báo lỗi trong console của trình duyệt đôi khi không cung cấp đủ chi tiết về lý do tại sao yêu cầu tiền kiểm thất bại. Lập trình viên có thể phải kiểm tra log của máy chủ hoặc sử dụng các công cụ mạng để phân tích kỹ lưỡng các header của cả yêu cầu và phản hồi để tìm ra nguyên nhân gốc rễ. Cuối cùng, việc quản lý một danh sách trắng (whitelist) các nguồn được phép có thể trở nên cồng kềnh khi ứng dụng phát triển và có nhiều đối tác hoặc khách hàng cần truy cập API.

Cách cấu hình và xử lý lỗi CORS trong phát triển web

Cấu hình CORS trên server

Việc cấu hình CORS được thực hiện hoàn toàn ở phía máy chủ (server-side). Máy chủ cần được thiết lập để trả về các HTTP header phù hợp khi nhận được yêu cầu từ một nguồn khác. Dưới đây là cách cấu hình trên một số nền tảng phổ biến.

Trên Node.js (sử dụng Express):
Cách đơn giản nhất là sử dụng một middleware như cors. Sau khi cài đặt (npm install cors), bạn có thể thêm nó vào ứng dụng Express của mình:

const express = require('express');
const cors = require('cors');
const app = express();

// Cho phép tất cả các nguồn
// app.use(cors());

// Hoặc cấu hình chi tiết hơn
const corsOptions = {
  origin: 'https://client.azweb.vn',
  optionsSuccessStatus: 200 // Dành cho các trình duyệt cũ
};
app.use(cors(corsOptions));

app.get('/api/data', (req, res) => {
  res.json({ message: 'CORS được cấu hình thành công!' });
});

app.listen(3000, () => console.log('Server đang chạy'));

Trên Apache:
Bạn có thể thêm các quy tắc vào tệp .htaccess hoặc tệp cấu hình chính của Apache (httpd.conf).

<IfModule mod_headers.c>
  Header set Access-Control-Allow-Origin "https://client.azweb.vn"
</IfModule>

Để cho phép nhiều phương thức và header hơn cho các yêu cầu tiền kiểm, bạn có thể cần cấu hình phức tạp hơn.

Trên Nginx:
Bạn có thể thêm các chỉ thị add_header vào khối server hoặc location trong tệp cấu hình của Nginx.

location / {
    add_header 'Access-Control-Allow-Origin' 'https://client.azweb.vn' always;
    add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
    add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range' always;

    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Max-Age' 1728000;
        add_header 'Content-Type' 'text/plain; charset=utf-8';
        add_header 'Content-Length' 0;
        return 204;
    }
}

Hình minh họa

Các giải pháp xử lý lỗi CORS

Khi bạn không có quyền kiểm soát máy chủ để cấu hình CORS (ví dụ: khi làm việc với API của bên thứ ba), bạn cần các giải pháp thay thế.

Sử dụng Proxy Server:
Đây là giải pháp phổ biến và mạnh mẽ nhất. Thay vì ứng dụng frontend của bạn gọi trực tiếp đến API của bên thứ ba, nó sẽ gửi yêu cầu đến backend của chính bạn (proxy server). Backend của bạn, với tư cách là một máy chủ, không bị ràng buộc bởi chính sách Same-Origin Policy, sẽ chuyển tiếp yêu cầu đó đến API của bên thứ ba. Sau khi nhận được phản hồi, backend sẽ gửi lại cho frontend. Vì frontend và backend của bạn có cùng nguồn gốc, nên không có lỗi CORS nào xảy ra.

Hình minh họa

Giải pháp này không chỉ giải quyết vấn đề CORS mà còn tăng cường bảo mật. Bạn có thể giấu các khóa API (API keys) nhạy cảm ở phía backend thay vì để lộ chúng ở frontend.

Sử dụng JSONP (JSON with Padding):
JSONP là một kỹ thuật cũ hơn, hoạt động bằng cách lợi dụng việc thẻ <script> không bị giới hạn bởi Same-Origin Policy. Nó hoạt động bằng cách yêu cầu một script từ máy chủ cross-origin, script này sẽ thực thi một hàm callback đã được định nghĩa sẵn trong ứng dụng của bạn và truyền dữ liệu JSON vào hàm đó. Tuy nhiên, JSONP có nhiều nhược điểm: nó chỉ hỗ trợ phương thức GET, kém an toàn hơn CORS và việc xử lý lỗi cũng phức tạp hơn. Ngày nay, JSONP hiếm khi được sử dụng và chỉ nên được xem là giải pháp cuối cùng khi không thể dùng CORS hoặc proxy.

Best Practices

Để làm việc với CORS một cách hiệu quả và an toàn, các lập trình viên nên tuân thủ một số nguyên tắc tốt nhất đã được chứng minh. Việc áp dụng những thực hành này không chỉ giúp tránh lỗi mà còn đảm bảo rằng ứng dụng của bạn được bảo vệ đúng cách.

Luôn khai báo rõ ràng các nguồn được phép: Tránh sử dụng ký tự đại diện (wildcard *) cho Access-Control-Allow-Origin trong môi trường sản phẩm (production). Thay vào đó, hãy liệt kê cụ thể từng tên miền mà bạn tin cậy và muốn cấp quyền truy cập. Ví dụ: Access-Control-Allow-Origin: https://app.azweb.vn. Điều này đảm bảo rằng chỉ những ứng dụng đã được xác định mới có thể tương tác với tài nguyên của bạn.
Chỉ mở rộng CORS với các domain tin cậy: Trước khi thêm một tên miền vào danh sách trắng của bạn, hãy chắc chắn rằng bạn hiểu rõ về tên miền đó và tin tưởng nó. Mỗi tên miền được thêm vào là một cửa ngõ tiềm năng vào hệ thống của bạn.
Không để CORS ở chế độ mở hoàn toàn trong production: Việc thiết lập Access-Control-Allow-Origin: * có thể hữu ích trong quá trình phát triển để nhanh chóng kiểm thử, nhưng nó cực kỳ nguy hiểm trong môi trường production. Nó cho phép bất kỳ trang web nào trên internet gửi yêu cầu và đọc phản hồi từ API của bạn, có thể dẫn đến việc lạm dụng tài nguyên và rò rỉ dữ liệu.
Cấu hình các header khác một cách cẩn thận: Ngoài Access-Control-Allow-Origin, hãy chú ý đến các header khác như Access-Control-Allow-Methods và Access-Control-Allow-Headers. Chỉ cho phép các phương thức và header thực sự cần thiết cho ứng dụng của bạn hoạt động. Đừng mở rộng quyền một cách không cần thiết.
Kiểm tra và xử lý kịp thời các lỗi CORS: Tích hợp việc kiểm tra cấu hình CORS vào quy trình phát triển và kiểm thử của bạn. Theo dõi log và console của trình duyệt để phát hiện sớm các lỗi CORS và giải quyết chúng trước khi chúng ảnh hưởng đến người dùng cuối.

Hình minh họa

Conclusion

Qua bài viết này, chúng ta đã cùng nhau khám phá sâu sắc về CORS – một khái niệm không thể thiếu trong thế giới web hiện đại. Từ định nghĩa cơ bản, cơ chế hoạt động phức tạp với các yêu cầu tiền kiểm, cho đến vai trò tối quan trọng trong việc bảo vệ ứng dụng web khỏi các mối đe dọa như CSRF và bảo vệ dữ liệu người dùng. CORS không chỉ là một rào cản kỹ thuật mà các lập trình viên cần vượt qua, mà còn là một công cụ bảo mật mạnh mẽ khi được cấu hình đúng cách. Việc hiểu rõ bản chất “trình duyệt thực thi” của CORS, nắm vững cách cấu hình trên các loại máy chủ khác nhau, và biết các giải pháp xử lý khi gặp sự cố là những kỹ năng thiết yếu. AZWEB khuyến khích mọi lập trình viên, từ người mới bắt đầu đến những người có kinh nghiệm, hãy dành thời gian để hiểu sâu và áp dụng đúng đắn các nguyên tắc CORS. Điều này không chỉ giúp xây dựng các ứng dụng web linh hoạt, mạnh mẽ hơn mà còn góp phần tạo nên một môi trường internet an toàn hơn cho tất cả mọi người. Hãy tiếp tục tìm hiểu thêm về bảo mật web để nâng cao kỹ năng lập trình của bạn mỗi ngày. Bạn có thể bắt đầu với các bài viết như Firewall là gì, Phishing là gì, và Malware là gì.