> For the complete documentation index, see [llms.txt](https://hieus-organization-25.gitbook.io/canhieu-writeup/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hieus-organization-25.gitbook.io/canhieu-writeup/cross-origin-resource-sharing-cors/ly-thuyet.md).
# Lý thuyết
## 1. Định nghĩa
**Cross-Origin Resource Sharing (CORS)** là một cơ chế bảo mật được tiêu chuẩn hóa bởi W3C và được các trình duyệt hiện đại thực thi nhằm kiểm soát xem một tài nguyên web có thể được truy cập bởi một domain khác (cross-origin) hay không.
CORS là phần mở rộng của **chính sách cùng nguồn gốc (Same-Origin Policy)** – một chính sách bảo mật mặc định trong trình duyệt. Chính sách này ngăn các website từ origin A gửi request đến origin B và truy xuất nội dung phản hồi, trừ khi origin B cho phép rõ ràng điều đó thông qua CORS headers.
Một **origin** được xác định bởi:
* **Giao thức (protocol)** – ví dụ: `http`, `https`
* **Tên miền (domain)** – ví dụ: `example.com`
* **Cổng (port)** – ví dụ: `:80`, `:443`, `:3000`
Nếu có sự khác biệt ở bất kỳ thành phần nào, đó được xem là **yêu cầu khác nguồn gốc (cross-origin request)**.
## 2. Ảnh hưởng (Theo tam giác bảo mật CIA)
Trong an ninh mạng, **tam giác CIA** bao gồm ba trụ cột cốt lõi: **Confidentiality (bảo mật), Integrity (toàn vẹn), Availability (sẵn sàng)**. CORS, nếu được cấu hình đúng hoặc sai, đều ảnh hưởng trực tiếp đến cả ba yếu tố này.
### 2.1. Confidentiality – Tính bảo mật
CORS đóng vai trò quan trọng trong việc **bảo vệ dữ liệu nhạy cảm khỏi bị truy cập trái phép** từ các domain lạ. Nếu máy chủ định cấu hình sai `Access-Control-Allow-Origin`, bất kỳ website nào cũng có thể gửi request và đọc dữ liệu người dùng đã đăng nhập (qua session, cookie).
**Ví dụ sai phạm:**
```http
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
```
Cấu hình như trên cho phép mọi website truy cập dữ liệu người dùng – **vi phạm nghiêm trọng tính bảo mật**.
### 2.2. Integrity – Tính toàn vẹn
CORS không chỉ ngăn việc đọc dữ liệu trái phép mà còn ngăn **gửi các yêu cầu có khả năng thay đổi dữ liệu** (như `PUT`, `DELETE`, `PATCH`) từ các nguồn không xác thực. Nếu server cho phép các yêu cầu như vậy mà không xác thực thêm, attacker có thể lợi dụng CORS để gửi dữ liệu giả mạo.
**Ví dụ sai phạm:**\
Một API cho phép mọi origin thực hiện `PUT /update-user`, và dựa vào cookie của người dùng đang đăng nhập → attacker có thể thay đổi thông tin của nạn nhân.
### 2.3. Availability – Tính sẵn sàng
CORS ảnh hưởng đến tính sẵn sàng khi các ứng dụng web frontend hợp lệ không thể truy cập tài nguyên backend do **cấu hình thiếu hoặc sai**. Trình duyệt sẽ chặn yêu cầu ngay cả khi server vẫn xử lý bình thường, gây lỗi “CORS policy blocked...”.
**Hệ quả:**\
Ứng dụng web không thể hoạt động đúng, ảnh hưởng đến trải nghiệm người dùng và tính sẵn sàng của dịch vụ.
## 3. Các biến thể (Dựa theo phân loại từ PortSwigger)
### 3.1. Wildcard Origin với Credentials
Một số server phản hồi:
```http
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
```
Đây là **lỗi nghiêm trọng**, vi phạm chuẩn CORS, nhưng vẫn có server cấu hình như vậy. Khi đó, bất kỳ trang web nào cũng có thể gửi yêu cầu kèm cookie xác thực và nhận dữ liệu phản hồi.
### 3.2. Reflect Origin Header (Phản xạ lại Origin)
Một lỗi phổ biến là server tự động phản xạ lại giá trị của header `Origin` mà không xác thực nó có đáng tin cậy không:
```http
Access-Control-Allow-Origin: [giá trị Origin nhận vào]
```
Điều này cho phép attacker đặt giá trị `Origin` tùy ý và server sẽ phản hồi lại → **mở rộng quyền truy cập trái phép** đến mọi domain.
### 3.3. Null Origin
Một số yêu cầu có thể mang header `Origin: null` khi đến từ:
* iframe có thuộc tính `sandbox`
* Trình duyệt truy cập từ file hệ thống (`file://`)
* Một số trình giả lập hoặc extension
Nếu server cho phép:
```http
Access-Control-Allow-Origin: null
```
thì attacker có thể lợi dụng các môi trường này để vượt qua kiểm tra nguồn gốc.
### 3.4. Subdomain Wildcard (Cho phép subdomain không kiểm soát)
Một số server cấu hình như:
```http
Access-Control-Allow-Origin: *.example.com
```
mà không kiểm soát kỹ các subdomain → nếu attacker chiếm quyền một subdomain yếu như `dev.example.com`, họ có thể truy cập tài nguyên từ `api.example.com`.
### 3.5. Open CORS on Sensitive Endpoints
Nhiều hệ thống bật CORS trên toàn bộ endpoint, bao gồm cả endpoint nhạy cảm như:
* `/user/profile`
* `/admin/config`
Nếu không có xác thực bổ sung, các endpoint này có thể bị truy cập từ các nguồn ngoài, gây **rò rỉ hoặc chỉnh sửa dữ liệu trái phép**.
## 4. Các vị trí hoặc chức năng dễ xảy ra lỗi CORS
Các lỗi liên quan đến CORS thường không xuất hiện ngẫu nhiên, mà tập trung vào các vị trí cụ thể trong kiến trúc hệ thống. Dưới đây là những **nơi dễ mắc lỗi CORS nhất**:
### 4.1. API Gateway hoặc Reverse Proxy
Các hệ thống như Nginx, Apache, hoặc các API Gateway (AWS API Gateway, Kong, v.v.) thường là điểm chặn đầu tiên xử lý request. Nếu không cấu hình đúng CORS tại đây, có thể:
* Chặn luôn request hợp lệ
* Hoặc tệ hơn, mở quá rộng quyền truy cập
### 4.2. Các endpoint yêu cầu xác thực
Ví dụ: `/user/profile`, `/orders/history`, `/admin/settings`.\
Khi frontend gửi request có `Authorization` header hoặc cookie, CORS cần `Access-Control-Allow-Credentials: true` và Origin cụ thể. Nếu dùng `*`, trình duyệt sẽ từ chối phản hồi – hoặc nếu server sai, dữ liệu bị lộ.
### 4.3. Tích hợp hệ thống frontend-backend độc lập
Trong các hệ thống tách biệt frontend và backend (FE chạy ở domain A, BE ở domain B), dev thường quên cấu hình CORS ở backend hoặc sử dụng wildcard tạm thời cho tiện phát triển, nhưng quên sửa trong môi trường production.
### 4.4. Các chức năng AJAX nội bộ bên thứ ba
Ví dụ: frontend từ `myshop.com` gọi API của `payment.partner.com`. Nếu `partner.com` không cấu hình đúng CORS hoặc cấu hình quá rộng, có thể:
* Gây lỗi chức năng thanh toán
* Lộ thông tin người dùng qua third-party
### 4.5. API public cho mobile app hoặc SPA
Khi một API phục vụ nhiều nền tảng, người lập trình backend có thể **cho phép toàn bộ domain** để tránh lỗi → đây là **lỗ hổng nghiêm trọng** nếu không xác thực domain cụ thể.
### 4.6. Các subdomain không được bảo mật kỹ
Ví dụ: `dev.example.com`, `test.example.com` thường bị bỏ ngỏ, không có HTTPS hoặc xác thực. Nếu server chính cho phép wildcard `*.example.com`, attacker có thể lợi dụng subdomain yếu để tấn công hệ thống chính.
### 4.7. Static file hosting (CDN, asset server)
Nếu file cấu hình hoặc API response được phân phối từ domain khác (CDN), cần cấu hình đúng CORS nếu frontend cần đọc dữ liệu từ JavaScript. Nhiều hệ thống tạm thời bật `Access-Control-Allow-Origin: *` nhưng không kiểm soát `Content-Type`, dẫn đến khả năng bị lợi dụng để khai thác dữ liệu.
## 5. Cách vá lỗi (Khắc phục cấu hình CORS sai)
### 5.1. Chỉ cho phép các domain đáng tin cậy
Thay vì dùng dấu `*`, hãy chỉ rõ domain được phép:
```js
const whitelist = ['https://myfrontend.com'];
if (whitelist.includes(req.headers.origin)) {
res.setHeader('Access-Control-Allow-Origin', req.headers.origin);
}
```
### 5.2. Không cho phép CORS với credentials nếu dùng wildcard
Tránh tuyệt đối kết hợp:
```http
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
```
Vì điều này **vô hiệu hóa hoàn toàn kiểm tra xác thực nguồn gốc**.
### 5.3. Không bật CORS cho các endpoint nhạy cảm
Chỉ nên bật CORS cho các API công khai. Các endpoint yêu cầu đăng nhập hoặc xử lý dữ liệu nhạy cảm nên:
* Tắt CORS hoàn toàn
* Yêu cầu xác thực chặt chẽ từ phía server
### 5.4. Kiểm tra Origin trước khi phản hồi
Không nên phản hồi `Access-Control-Allow-Origin` một cách tự động từ request. Hãy so sánh Origin với danh sách whitelist và chỉ phản hồi nếu hợp lệ.
### 5.5. Bảo vệ tầng cookie và xác thực
Sử dụng:
* `SameSite=Lax` hoặc `SameSite=Strict` cho cookie
* `HttpOnly` và `Secure` để tránh bị lộ qua script hoặc mạng
* CORS kết hợp với token (Bearer, JWT) thay vì dựa hoàn toàn vào cookie
