Cookie, session & CORS — vì sao request bị chặn

TL;DR: Browser chặn cross-origin request vì same-origin policy — cơ chế bảo mật ngăn JavaScript trên evil.com đọc dữ liệu từ bank.com. CORS (Cross-Origin Resource Sharing) là cơ chế cho phép server nới lỏng giới hạn đó có chọn lọc. Khi bạn thấy lỗi CORS trong DevTools, đừng nhầm: server đã nhận được request (thậm chí đã xử lý!) — chỉ là browser từ chối đưa response về cho JavaScript. Cookie là cơ chế lưu trạng thái trên browser, gắn với ba attribute bảo mật quan trọng: HttpOnly (chống XSS đọc cookie), Secure (chỉ gửi qua HTTPS), SameSite (kiểm soát cross-site cookie, chống CSRF). Session vs JWT là đánh đổi giữa stateful (server lưu session) và stateless (client mang token).

Bạn đã thấy trong bài 01 rằng HTTP stateless — không có bộ nhớ giữa các request. Vậy login ở trang web hoạt động ra sao? Và tại sao đôi khi fetch() từ React app lại bị browser chặn với lỗi CORS? Bài này trả lời cả hai câu hỏi đó.

1. Analogy — Huy hiệu thành viên và quy tắc cửa hàng

Cookie giống huy hiệu thành viên mà cửa hàng (server) trao cho bạn khi đăng ký:

• Cửa hàng in huy hiệu và trao cho bạn — server gửi Set-Cookie response header.
• Mỗi lần bạn vào cửa hàng, bạn đeo huy hiệu — browser tự đính kèm Cookie request header.
• Huy hiệu có thể có ghi chú: "Chỉ dùng tại chi nhánh X" (Domain), "Hết hạn ngày Y" (Expires), "Chỉ nhân viên nhìn thấy" (HttpOnly — JavaScript không đọc được).

Same-origin policy giống quy tắc của trung tâm thương mại: huy hiệu thành viên cửa hàng A không được dùng tại cửa hàng B (khác origin không được đọc cookie của nhau). CORS giống cửa hàng B đặt bảng "Khách hàng của cửa hàng A được chào đón" — server B cho phép explicitly.

2. Cookie — cơ chế và attributes bảo mật

2.1 Cách cookie hoạt động

Server tạo cookie bằng Set-Cookie response header:

HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=86400

Browser lưu cookie và tự đính kèm vào mọi request tiếp theo tới cùng domain:

GET /api/profile HTTP/1.1
Host: api.example.com
Cookie: session_id=abc123

Đây là cách duy nhất HTTP stateless vẫn "nhớ" người dùng — không phải HTTP nhớ, mà browser nhớ và gửi lại.

2.2 Ba attribute bảo mật quan trọng

HttpOnly — ngăn JavaScript đọc cookie:

Set-Cookie: session_id=abc123; HttpOnly

Cookie có HttpOnly không thể đọc bằng document.cookie hay fetch(). Điều này bảo vệ chống XSS (Cross-Site Scripting) — kể cả khi attacker chèn được JavaScript vào trang, chúng không thể đánh cắp session cookie.

Secure — chỉ gửi qua HTTPS:

Set-Cookie: session_id=abc123; Secure

Browser không gửi cookie có Secure qua kết nối HTTP thường — chỉ HTTPS. Bảo vệ chống network eavesdropping (nghe lén trên mạng).

SameSite — kiểm soát cross-site cookie gửi hay không, chống CSRF:

CSRF (Cross-Site Request Forgery) là tấn công khiến browser của nạn nhân gửi request đến bank.com mà nạn nhân không hay biết. Attacker tạo trang evil.com với form ẩn submit POST bank.com/transfer. Nếu nạn nhân đang logged in với cookie session, browser tự đính kèm cookie → bank thực hiện chuyển tiền.

SameSite giải quyết bằng cách kiểm soát khi nào browser gửi cookie theo cross-site request:

Lax là default từ Chrome 80 (2020). Dùng None khi cần gửi cookie cross-site (ví dụ: third-party widget embed trên nhiều trang) — bắt buộc kết hợp Secure.

3. Session vs JWT — hai cách implement auth trên HTTP stateless

3.1 Session (server-side stateful)

sequenceDiagram
    participant B as Browser
    participant S as Server
    participant DB as Session Store (Redis)
    B->>S: POST /login {username, password}
    S->>DB: Luu session: {id: "abc123", userId: 42, expires: ...}
    S-->>B: 200 OK + Set-Cookie: session_id=abc123; HttpOnly
    B->>S: GET /api/profile + Cookie: session_id=abc123
    S->>DB: Lookup session "abc123" -> userId=42
    S-->>B: 200 OK + {name: "Nguyen Van A"}

Server lưu session data trong session store (thường là Redis). Cookie chỉ chứa ID ngẫu nhiên, không có thông tin user. Revoke session: xoá khỏi Redis — hiệu lực ngay lập tức.

3.2 JWT (client-side stateless)

JWT (JSON Web Token) là token tự chứa thông tin (claims) và được ký bằng private key. Server không cần lưu gì — chỉ verify signature:

sequenceDiagram
    participant B as Browser
    participant S as Server
    B->>S: POST /login {username, password}
    Note over S: Tao JWT: header.payload.signature
    S-->>B: 200 OK + {token: "eyJhbG..."}
    B->>S: GET /api/profile + Authorization: Bearer eyJhbG...
    Note over S: Verify signature -> decode claims -> userId=42
    S-->>B: 200 OK + {name: "Nguyen Van A"}

Token được lưu ở client (localStorage hoặc cookie). Decode payload thấy claims như userId, role, exp.

3.3 Đánh đổi session vs JWT

Session phù hợp khi cần revoke ngay (banking, enterprise). JWT phù hợp khi cần stateless/microservices — nhưng phải chấp nhận không revoke được trước khi hết hạn (trừ khi dùng blacklist, tức là bạn vừa thêm stateful trở lại).

4. Same-origin policy — nền tảng bảo mật web

4.1 Origin là gì?

Origin (RFC 6454) = scheme + host + port. Ba thành phần phải khớp cả ba mới là same-origin:

4.2 Same-origin policy ngăn gì?

JavaScript chạy trên https://evil.com không được dùng fetch() để đọc response từ https://bank.com/api/balance — dù request có bay đi và server xử lý. Browser chặn JavaScript đọc response cross-origin.

Điều này bảo vệ: nếu bạn đang logged in bank.com và vô tình mở evil.com, JavaScript trên evil.com không thể đọc dữ liệu tài khoản từ bank.com — dù nó có thể gửi request (và browser tự đính kèm cookie — đây là lý do CSRF tồn tại).

5. CORS — cross-origin có kiểm soát

CORS (Cross-Origin Resource Sharing) là cơ chế server dùng để nói với browser: "Tôi cho phép JavaScript từ origin X đọc response của tôi."

5.1 Simple request vs Preflight

Không phải mọi cross-origin request đều cần preflight. Simple request (GET/POST với Content-Type thông thường, không có custom header) được gửi thẳng — browser chỉ kiểm tra CORS header trong response:

sequenceDiagram
    participant J as JavaScript (evil.com)
    participant B as Browser
    participant S as api.example.com
    J->>B: fetch("https://api.example.com/data")
    B->>S: GET /data + Origin: https://evil.com
    S-->>B: 200 OK + Access-Control-Allow-Origin: https://myapp.com
    Note over B: evil.com KHONG co trong ACAO -> block response
    B-->>J: TypeError: Failed to fetch

Preflight xảy ra khi request có custom header, hoặc method không phải GET/POST, hoặc Content-Type là application/json. Browser tự động gửi request OPTIONS trước để hỏi server:

sequenceDiagram
    participant J as JavaScript (myapp.com)
    participant B as Browser
    participant S as api.example.com
    J->>B: fetch với PUT + Authorization header
    B->>S: OPTIONS /api/data<br/>Origin: https://myapp.com<br/>Access-Control-Request-Method: PUT<br/>Access-Control-Request-Headers: Authorization
    S-->>B: 200 OK<br/>Access-Control-Allow-Origin: https://myapp.com<br/>Access-Control-Allow-Methods: GET, PUT<br/>Access-Control-Allow-Headers: Authorization<br/>Access-Control-Max-Age: 86400
    Note over B: Preflight thanh cong -> gui request that
    B->>S: PUT /api/data + Authorization: Bearer ...
    S-->>B: 200 OK + Access-Control-Allow-Origin: https://myapp.com
    B-->>J: Response data

5.2 Các CORS header quan trọng

Response headers (server gửi):

Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 86400

• Access-Control-Allow-Origin: origin nào được phép. Có thể là một origin cụ thể hoặc * (wildcard — tất cả).
• Access-Control-Allow-Credentials: có cho phép gửi cookie/auth kèm request không.
• Access-Control-Max-Age: cache preflight result bao nhiêu giây (tránh gửi OPTIONS mỗi request).

5.3 Vì sao Allow-Origin: * + credentials bị cấm

Đây là rule quan trọng trong CORS spec: không thể kết hợp Access-Control-Allow-Origin: * với Access-Control-Allow-Credentials: true.

Lý do: nếu wildcard origin được phép gửi cookie, bất kỳ website nào cũng có thể đọc dữ liệu của bạn từ bank.com kèm session cookie — về cơ bản là xoá bỏ toàn bộ bảo vệ same-origin. Browser từ chối enforce combination này. Khi cần credentials (cookie, Authorization), phải set origin cụ thể.

6. Pitfall — lỗi thường gặp

❌ Nhầm 1: "Lỗi CORS là lỗi server — server không nhận được request." ✅ Sai. CORS check xảy ra ở browser khi đọc response. Server thường đã nhận request và xử lý xong — chỉ là không set CORS header đúng trong response. Hệ quả: nếu request là DELETE hay POST có side effect, server đã thực thi dù browser block response. Fix: thêm CORS header vào response, không phải "fix server nhận request".

❌ Nhầm 2: Set Access-Control-Allow-Origin: * và Access-Control-Allow-Credentials: true cùng lúc. ✅ Browser từ chối combination này — lỗi sẽ là "credential flag is 'true' but the 'Access-Control-Allow-Origin' header is '*'". Phải liệt kê origin cụ thể: Access-Control-Allow-Origin: https://myapp.com khi cần credentials.

❌ Nhầm 3: Cookie không có HttpOnly — lưu session token trong document.cookie có thể đọc bằng JavaScript. ✅ Bất kỳ XSS nào (kể cả từ script inject qua third-party) đều đọc được document.cookie nếu thiếu HttpOnly. Session cookie phải luôn có HttpOnly. JWT nếu lưu trong cookie cũng nên HttpOnly — nếu lưu trong localStorage thì không được bảo vệ bởi HttpOnly.

7. Liên hệ các bài khác

• Bài 01 — HTTP anatomy: 401 vs 403 liên quan trực tiếp — 401 khi thiếu/sai credentials, 403 khi đủ quyền. Method OPTIONS là gì — bài này giải thích trong context CORS preflight.
• Bài 02 — HTTP headers: cookie gửi qua Cookie request header và Set-Cookie response header — là header đặc biệt nhất trong HTTP.
• Bài 06 — REST, gRPC, WebSocket, SSE: WebSocket handshake ban đầu là HTTP GET với Upgrade header — cũng chịu CORS rule.
• Module 1 — TCP handshake: CORS preflight là một HTTP round trip — mỗi OPTIONS request tốn 1 RTT. Access-Control-Max-Age cache preflight để tránh tốn RTT mỗi request.

8. 📚 Deep Dive — tài liệu gốc

9. Tóm tắt

• Cookie là cách HTTP stateless lưu trạng thái: server gửi Set-Cookie, browser lưu và tự gửi kèm Cookie header mỗi request cùng domain.
• HttpOnly ngăn JavaScript đọc cookie — bảo vệ khỏi XSS. Secure chỉ gửi qua HTTPS. SameSite=Lax ngăn gửi cookie theo cross-site POST — chống CSRF.
• SameSite=None phải kèm Secure; kết hợp Access-Control-Allow-Origin: * + credentials: true bị spec cấm.
• Session: server lưu state (Redis), cookie chứa ID — revoke ngay lập tức. JWT: stateless, client mang token — không revoke trước expire trừ khi có blacklist.
• Same-origin policy: JavaScript không đọc được response cross-origin. Origin = scheme + host + port — cả ba phải khớp.
• Same-origin policy không ngăn request gửi đi — chỉ ngăn JavaScript đọc response. Lỗi CORS xảy ra ở browser, không phải server.
• CORS preflight: browser tự gửi OPTIONS hỏi server; request "không simple" (custom header, method PUT/DELETE, Content-Type là JSON) đều trigger preflight.
• Access-Control-Max-Age cache preflight để tránh OPTIONS mỗi request.

10. Tự kiểm tra

Bài tiếp theo: HTTP/2 — multiplexing và stream