Technical SEO

Content Security Policy (CSP)

Header HTTP hoặc thẻ meta định nghĩa nguồn gốc đáng tin cậy cho các tài nguyên (script, style, image…) nhằm ngăn chặn XSS và tấn công mã độc.

4 lượt xem Cập nhật: 29/05/2026

Content Security Policy (CSP) là gì?

Content Security Policy (CSP) là một cơ chế bảo mật do trình duyệt hỗ trợ, được thiết lập qua header HTTP Content-Security-Policy hoặc thẻ <meta> trong HTML. CSP giúp kiểm soát nguồn gốc nào được phép tải và thực thi các tài nguyên như script, stylesheet, hình ảnh, phông chữ, iframe, kết nối AJAX (fetch/XHR), hay thậm chí cả các sự kiện nội tuyến (onclick, onload). Mục tiêu chính là ngăn chặn các cuộc tấn công chèn mã độc như XSS (Cross-Site Scripting), clickjacking và data injection.

Khác với tường lửa hoặc WAF — vốn hoạt động ở tầng mạng hoặc máy chủ — CSP là lớp bảo mật phía người dùng (client-side), do trình duyệt thực thi dựa trên quy tắc do chủ sở hữu trang web định nghĩa. Nó không thay thế việc viết mã an toàn, mà là lớp phòng thủ bổ sung khi có lỗ hổng tồn tại.

Tại sao quan trọng trong SEO?

CSP không trực tiếp ảnh hưởng đến thứ hạng tìm kiếm, nhưng lại tác động gián tiếp và mạnh mẽ đến các yếu tố xếp hạng chất lượng trải nghiệm người dùng (Core Web Vitals, độ tin cậy, tính ổn định). Cụ thể:

  • Giảm lỗi chặn tài nguyên: Nếu CSP quá nghiêm ngặt, trình duyệt sẽ chặn CSS/JS cần thiết → trang render sai, layout vỡ, tương tác hỏng → tăng tỷ lệ thoát, giảm thời gian ở lại → ảnh hưởng tiêu cực đến tín hiệu hành vi người dùng.
  • Ảnh hưởng đến công cụ phân tích: CSP chặn script của Google Analytics, GTM hoặc các tag quản lý quảng cáo nếu không khai báo đúng nguồn → dữ liệu đo lường bị thiếu → ra quyết định SEO sai lệch.
  • Tương thích với bot tìm kiếm: Các bot hiện đại như Googlebot tuân thủ một phần CSP (đặc biệt với script-src và frame-src). Nếu CSP vô tình chặn JS cần thiết để render nội dung động (SSR/CSR), bot có thể không thấy nội dung đầy đủ → ảnh hưởng khả năng lập chỉ mục.
  • Tín hiệu uy tín: Trang có CSP hợp lý cho thấy chủ sở hữu quan tâm đến bảo mật và chất lượng kỹ thuật — yếu tố gián tiếp củng cố độ tin cậy trong mắt Google (theo tài liệu chính thức về Page Experience).

Cách hoạt động

CSP hoạt động theo nguyên tắc “từ chối mặc định”: mọi nguồn đều bị chặn trừ khi được liệt kê rõ ràng trong directive. Mỗi directive điều khiển một loại tài nguyên:

  • script-src: nguồn script được phép chạy
  • style-src: nguồn CSS được phép áp dụng
  • img-src: nguồn hình ảnh được phép tải
  • font-src: nguồn phông chữ
  • connect-src: đích cho fetch(), XMLHttpRequest, EventSource…
  • frame-src: nguồn iframe được phép nhúng
  • default-src: giá trị mặc định cho các directive chưa khai báo riêng

Mỗi directive chấp nhận nhiều giá trị: 'self' (cùng origin), 'none' (chặn hoàn toàn), tên miền (ví dụ: https://cdn.example.com), lược đồ (https:), hoặc từ khóa đặc biệt như 'unsafe-inline' (cho phép inline script — KHÔNG KHUYẾN KHÍCH).

Hướng dẫn thực hiện

  1. Phân tích hiện trạng: Dùng DevTools → tab Console hoặc Network để ghi lại các cảnh báo CSP (vi phạm policy). Lưu ý các tài nguyên bị chặn — đặc biệt là script từ CDN, analytics, widget bên ngoài.
  2. Bắt đầu bằng chế độ báo cáo (report-only): Thiết lập header Content-Security-Policy-Report-Only thay vì Content-Security-Policy. Khi đó, vi phạm sẽ không chặn tài nguyên mà gửi báo cáo JSON tới endpoint bạn chỉ định (qua report-uri hoặc report-to).
  3. Xây dựng policy từng bước: Bắt đầu từ default-src 'self', sau đó mở rộng dần: thêm script-src 'self' https://www.google-analytics.com, img-src 'self' data: https:… Tránh dùng 'unsafe-inline' hoặc 'unsafe-eval' — thay vào đó, dùng nonce hoặc hash nếu bắt buộc.
  4. Kiểm thử kỹ: Kiểm tra trên nhiều thiết bị, trình duyệt và đặc biệt là với các tính năng phụ thuộc JS (form gửi, menu dropdown, lazy load ảnh). Đảm bảo không có lỗi console liên quan đến CSP.
  5. Triển khai chính thức: Chuyển sang header Content-Security-Policy sau khi đã ổn định ít nhất 7 ngày ở chế độ report-only.

Lỗi thường gặp

  • Lỗi: Chặn script Google Analytics / GTM
    Nguyên nhân: Thiếu script-src cho https://www.googletagmanager.com hoặc https://www.google-analytics.com.
    Khắc phục: Thêm domain này vào script-src; nếu dùng gtag.js, cần cả https://www.google.com (do gọi API geolocation).
  • Lỗi: CSS không áp dụng, giao diện vỡ
    Nguyên nhân: style-src thiếu 'self' hoặc chặn inline style (dùng trong WordPress theme, React component).
    Khắc phục: Thêm 'self'; nếu bắt buộc dùng inline style, dùng style-src 'self' 'unsafe-inline' — nhưng nên chuyển sang class CSS ngoài file.
  • Lỗi: Ảnh không hiển thị
    Nguyên nhân: img-src không cho phép data: (dùng cho ảnh base64) hoặc https: (nếu ảnh từ CDN HTTPS).
    Khắc phục: Thêm data: và https: vào img-src.
  • Lỗi: Form không gửi được
    Nguyên nhân: connect-src chặn endpoint API (ví dụ: https://api.example.com/submit).
    Khắc phục: Liệt kê đầy đủ domain API trong connect-src.

Ví dụ thực tế

Dưới đây là một CSP tối thiểu nhưng an toàn cho website WordPress chuẩn, tích hợp Google Analytics và CDN ảnh:

Content-Security-Policy: default-src 'none'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com https://www.google-analytics.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self' https://api.example.com; frame-src https://www.youtube.com; base-uri 'self'; form-action 'self';

Giải thích ngắn:

Directive Giá trị Mục đích
default-src 'none' Chặn tất cả trừ khi có directive riêng
script-src 'self' 'unsafe-inline' https://www.googletagmanager.com... Cho phép script từ domain chính, inline (tạm thời), và GA/GTM
img-src 'self' data: https: Hỗ trợ ảnh local, base64 và mọi CDN HTTPS
connect-src 'self' https://api.example.com Chỉ cho phép gọi API từ domain chính và API cụ thể

Câu hỏi thường gặp

CSP có làm chậm tải trang không?

Không. CSP là header hoặc thẻ meta nhẹ, không yêu cầu xử lý phức tạp từ trình duyệt. Việc kiểm tra nguồn gốc được thực hiện song song khi tải tài nguyên — không gây trễ đáng kể. Tuy nhiên, nếu CSP gây ra nhiều vi phạm và trình duyệt phải log cảnh báo liên tục, có thể ảnh hưởng nhẹ đến hiệu năng CPU ở tab DevTools — nhưng không ảnh hưởng đến người dùng thật.

Có thể dùng CSP cùng với HTTP Strict Transport Security (HSTS) không?

Có thể — và nên dùng cùng nhau. HSTS đảm bảo kết nối luôn qua HTTPS, còn CSP kiểm soát nội dung được tải. Hai cơ chế bổ trợ, không xung đột. Lưu ý: CSP không thay thế HSTS, và ngược lại.

CSP có hỗ trợ trên tất cả trình duyệt không?

Hầu hết trình duyệt hiện đại đều hỗ trợ đầy đủ: Chrome, Firefox, Safari (từ phiên bản 15.4+), Edge. Internet Explorer chỉ hỗ trợ một phần (không có report-to, thiếu nhiều directive). Với website hướng đến người dùng Việt Nam (Chrome chiếm >85%), CSP có thể triển khai an toàn. Tính năng report-to (thay thế report-uri) có thể thay đổi tùy trình duyệt — kiểm tra tại caniuse.com/csp.