Chính sách bảo mật nội dung có thể làm giảm đáng kể nguy cơ và tác động của các cuộc tấn công vào tập lệnh trên nhiều trang web trong các trình duyệt hiện đại.
Mô hình bảo mật của web dựa trên một chính sách cùng nguồn gốc. Ví dụ: mã từ https://mybank.com chỉ được có quyền truy cập vào dữ liệu của https://mybank.com và https://evil.example.com không được phép truy cập.
Về lý thuyết, mỗi nguồn gốc được tách biệt với phần còn lại của web, cung cấp cho các nhà phát triển một hộp cát an toàn để xây dựng. Tuy nhiên, trong thực tế, những kẻ tấn công đã tìm ra nhiều cách để lật đổ hệ thống.
Ví dụ: các cuộc tấn công Tập lệnh trên nhiều trang web (XSS) né tránh chính sách cùng nguồn gốc bằng cách lừa một trang web phân phối mã độc hại cùng với nội dung mong muốn. Đây là một vấn đề rất lớn vì trình duyệt tin tưởng rằng tất cả các mã xuất hiện trên một trang là một phần hợp pháp của nguồn gốc bảo mật của trang đó. Bản tóm tắt về XSS là một phần cũ nhưng mang tính đại diện cho các phương thức mà kẻ tấn công có thể sử dụng để vi phạm niềm tin này bằng cách chèn mã độc hại. Nếu một kẻ tấn công chèn thành công bất kỳ mã nào, thì kẻ tấn công đã xâm phạm phiên hoạt động của người dùng và giành được quyền truy cập vào thông tin riêng tư.
Trang này trình bày Chính sách bảo mật nội dung (CSP) như một chiến lược giúp giảm thiểu rủi ro và tác động của các cuộc tấn công XSS trong các trình duyệt hiện đại.
Các thành phần của CSP
Để triển khai CSP hiệu quả, hãy làm theo các bước sau:
- Sử dụng danh sách cho phép để cho khách hàng biết nội dung nào được phép và không được phép.
- Tìm hiểu xem có những lệnh nào.
- Tìm hiểu những từ khoá mà họ sử dụng.
- Hạn chế việc sử dụng mã cùng dòng và
eval(). - Hãy báo cáo lỗi vi phạm chính sách cho máy chủ của bạn trước khi thực thi.
Danh sách nguồn được cho phép
Các cuộc tấn công XSS lợi dụng việc trình duyệt không thể phân biệt tập lệnh là một phần của ứng dụng và tập lệnh đã được bên thứ ba chèn độc hại. Ví dụ: nút Google +1 ở cuối trang này sẽ tải và thực thi mã từ https://apis.google.com/js/plusone.js theo bối cảnh nguồn gốc của trang này.
Chúng tôi tin tưởng mã đó, nhưng chúng tôi không thể kỳ vọng trình duyệt tự xác định rằng mã từ apis.google.com là an toàn để chạy, trong khi mã từ apis.evil.example.com có thể thì không. Trình duyệt sẽ sẵn sàng tải xuống và thực thi bất kỳ mã nào mà trang yêu cầu, bất kể nguồn nào.
Tiêu đề HTTP Content-Security-Policy của CSP cho phép bạn tạo danh sách cho phép các nguồn nội dung đáng tin cậy và yêu cầu trình duyệt chỉ thực thi hoặc chỉ hiển thị tài nguyên từ các nguồn đó. Ngay cả khi kẻ tấn công có thể tìm thấy lỗ hổng để chèn một tập lệnh, tập lệnh đó sẽ không khớp với danh sách cho phép và do đó sẽ không được thực thi.
Chúng tôi tin tưởng apis.google.com sẽ cung cấp mã hợp lệ và chúng tôi cũng tin tưởng chính mình cũng làm như vậy. Dưới đây là một chính sách mẫu cho phép các tập lệnh chỉ thực thi khi các tập lệnh đó đến từ một trong hai nguồn đó:
Content-Security-Policy: script-src 'self' https://apis.google.com
script-src là một lệnh kiểm soát một tập hợp các đặc quyền liên quan đến tập lệnh cho một trang. Tiêu đề này 'self' là một nguồn tập lệnh hợp lệ và https://apis.google.com là một nguồn tập lệnh khác. Hiện tại, trình duyệt có thể tải xuống và thực thi JavaScript từ apis.google.com qua HTTPS, cũng như từ nguồn gốc của trang hiện tại, nhưng không thể tải từ bất kỳ nguồn nào khác. Nếu kẻ tấn công chèn mã vào trang web của bạn, thì trình duyệt sẽ gửi lỗi và không chạy tập lệnh được chèn.
Chính sách áp dụng cho nhiều loại tài nguyên
CSP cung cấp một tập hợp các lệnh chính sách cho phép kiểm soát chi tiết các tài nguyên mà một trang được phép tải, bao gồm cả script-src trong ví dụ trước.
Danh sách sau đây trình bày phần còn lại của các lệnh về tài nguyên tính đến cấp 2. Thông số kỹ thuật cấp 3 đã được soạn thảo, nhưng phần lớn chưa được triển khai trong các trình duyệt chính.
base-uri- Giới hạn những URL có thể xuất hiện trong phần tử
<base>của một trang. child-src- Liệt kê các URL của worker và nội dung khung được nhúng. Ví dụ:
child-src https://youtube.comcho phép nhúng video từ YouTube mà không cho phép nhúng video từ các nguồn khác. connect-src- Giới hạn các nguồn gốc mà bạn có thể kết nối bằng XHR, WebSockets và EventSource.
font-src- Chỉ định nguồn gốc có thể phân phát phông chữ trên web. Ví dụ: bạn có thể cho phép phông chữ web của Google bằng cách sử dụng
font-src https://themes.googleusercontent.com. form-action- Liệt kê các điểm cuối hợp lệ để gửi từ các thẻ
<form>. frame-ancestors- Chỉ định các nguồn có thể nhúng trang hiện tại. Lệnh này áp dụng cho các thẻ
<frame>,<iframe>,<embed>và<applet>. Bạn không thể dùng tính năng này trong thẻ<meta>hoặc cho tài nguyên HTML. frame-src- Lệnh này không còn được dùng ở cấp 2 nữa, nhưng được khôi phục ở cấp 3. Nếu không có, trình duyệt sẽ quay lại sử dụng
child-src. img-src- Xác định nguồn hình ảnh có thể được tải từ đó.
media-src- Hạn chế các nguồn gốc được phép phân phối video và âm thanh.
object-src- Cho phép kiểm soát Flash và các trình bổ trợ khác.
plugin-types- Giới hạn các loại trình bổ trợ mà một trang có thể gọi.
report-uri- Chỉ định một URL mà trình duyệt gửi báo cáo đến khi vi phạm chính sách bảo mật nội dung. Bạn không thể sử dụng lệnh này trong thẻ
<meta>. style-src- Giới hạn nguồn gốc mà một trang có thể sử dụng biểu định kiểu.
upgrade-insecure-requests- Hướng dẫn tác nhân người dùng viết lại giao thức URL bằng cách thay đổi HTTP thành HTTPS. Lệnh này dành cho các trang web có nhiều URL cũ cần được viết lại.
worker-src- Lệnh CSP cấp 3 hạn chế các URL có thể tải dưới dạng một trình thực thi, trình thực thi dùng chung hoặc trình chạy dịch vụ. Kể từ tháng 7 năm 2017, chỉ thị này đã được triển khai giới hạn.
Theo mặc định, trình duyệt tải tài nguyên được liên kết từ mọi nguồn gốc mà không có hạn chế, trừ phi bạn đặt chính sách bằng một lệnh cụ thể. Để ghi đè
lệnh mặc định, hãy chỉ định một lệnh default-src. Lệnh này xác định giá trị mặc định cho mọi lệnh chưa được chỉ định kết thúc bằng -src. Ví dụ: nếu bạn đặt default-src thành https://example.com và không chỉ định lệnh font-src, thì bạn chỉ có thể tải phông chữ từ https://example.com.
Các lệnh sau đây không dùng default-src làm phương án dự phòng. Hãy nhớ rằng việc không đặt chúng cũng giống như cho phép bất kỳ điều gì:
base-uriform-actionframe-ancestorsplugin-typesreport-urisandbox
Cú pháp CSP cơ bản
Để sử dụng các lệnh CSP, hãy liệt kê các lệnh đó trong tiêu đề HTTP với các lệnh được phân tách bằng dấu hai chấm. Hãy nhớ liệt kê tất cả các tài nguyên bắt buộc thuộc một loại cụ thể trong một lệnh như sau:
script-src https://host1.com https://host2.com
Sau đây là ví dụ về nhiều lệnh, trong trường hợp này là một ứng dụng web tải tất cả tài nguyên từ một mạng phân phối nội dung tại https://cdn.example.net và không sử dụng nội dung hoặc trình bổ trợ có khung:
Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'
Thông tin triển khai
Các trình duyệt hiện đại hỗ trợ tiêu đề Content-Security-Policy không có tiền tố.
Đây là tiêu đề được đề xuất. Các tiêu đề X-WebKit-CSP và X-Content-Security-Policy mà bạn có thể thấy trong hướng dẫn trực tuyến không còn được dùng nữa.
CSP được xác định trên cơ sở từng trang. Bạn cần gửi tiêu đề HTTP kèm theo mọi phản hồi mà bạn muốn bảo vệ. Điều này cho phép bạn tinh chỉnh chính sách cho các trang cụ thể dựa trên nhu cầu cụ thể của các trang đó. Ví dụ: nếu một nhóm trang trong trang web của bạn có nút +1, trong khi những trang khác không có, bạn có thể chỉ cho phép mã nút tải khi cần.
Danh sách nguồn cho mỗi lệnh có thể linh hoạt. Bạn có thể chỉ định các nguồn bằng lược đồ (data:, https:) hoặc mức độ cụ thể từ chỉ so khớp tên máy chủ (example.com, so khớp mọi nguồn gốc trên máy chủ lưu trữ đó: giao thức bất kỳ, cổng bất kỳ) đến URI đủ điều kiện (https://example.com:443, chỉ khớp HTTPS, chỉ example.com và chỉ cổng 443). Chúng tôi chấp nhận ký tự đại diện, nhưng chỉ dưới dạng lược đồ, cổng hoặc ở vị trí ngoài cùng bên trái của tên máy chủ: *://*.example.com:* sẽ khớp với tất cả miền con của example.com (nhưng không phải example.com), bằng bất kỳ lược đồ nào trên bất kỳ cổng nào.
Danh sách nguồn cũng chấp nhận 4 từ khoá:
'none'không khớp với giá trị nào.'self'khớp với nguồn gốc hiện tại, nhưng không khớp với miền con của nguồn gốc hiện tại.'unsafe-inline'cho phép JavaScript và CSS cùng dòng. Để biết thêm thông tin, hãy xem phần Tránh dùng mã cùng dòng.'unsafe-eval'cho phép cơ chế chuyển văn bản sang JavaScript nhưeval. Để biết thêm thông tin, hãy xem phần Tránheval().
Những từ khoá này yêu cầu phải dùng dấu ngoặc đơn. Ví dụ: script-src 'self' (có dấu ngoặc kép) uỷ quyền thực thi JavaScript từ máy chủ hiện tại; script-src self (không có dấu ngoặc kép) cho phép JavaScript từ một máy chủ có tên "self" (và không phải từ máy chủ hiện tại), có thể không phải như ý bạn muốn.
Hộp cát các trang của bạn
Có một lệnh khác đáng chú ý: sandbox. Báo cáo này hơi khác với những mục khác mà chúng tôi đã xem xét, vì công cụ này đặt ra các hạn chế về các thao tác mà trang có thể thực hiện thay vì các tài nguyên mà trang có thể tải. Nếu có lệnh sandbox, trang sẽ được coi là đã được tải bên trong <iframe> bằng thuộc tính sandbox. Điều này có thể có nhiều hiệu ứng trên trang: buộc trang nhập một nguồn gốc duy nhất và ngăn việc gửi biểu mẫu, v.v. Nội dung này nằm ngoài phạm vi của trang này một chút, nhưng bạn có thể tìm thấy đầy đủ thông tin chi tiết về các thuộc tính hộp cát hợp lệ trong mục "Hộp cát" của thông số kỹ thuật HTML5.
Thẻ meta
Cơ chế phân phối ưu tiên của CSP là một tiêu đề HTTP. Tuy nhiên, bạn nên đặt một chính sách trên một trang ngay trong mã đánh dấu. Thực hiện việc đó bằng cách sử dụng thẻ <meta> có thuộc tính http-equiv:
<meta http-equiv="Content-Security-Policy" content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'">
Bạn không thể dùng giá trị này cho frame-ancestors, report-uri hoặc sandbox.
Tránh dùng mã cùng dòng
Mạnh mẽ như danh sách cho phép dựa trên nguồn gốc được dùng trong các lệnh CSP, nhưng chúng không thể giải quyết được mối đe doạ lớn nhất do các cuộc tấn công XSS gây ra: chèn tập lệnh cùng dòng.
Nếu kẻ tấn công có thể chèn một thẻ tập lệnh trực tiếp chứa một số tải trọng độc hại (chẳng hạn như <script>sendMyDataToEvilDotCom()</script>), thì trình duyệt sẽ không có cách nào để phân biệt thẻ đó với thẻ tập lệnh cùng dòng hợp lệ. CSP giải quyết vấn đề này bằng cách cấm hoàn toàn tập lệnh cùng dòng.
Lệnh cấm này không chỉ áp dụng cho các tập lệnh được nhúng trực tiếp trong thẻ script, mà còn cả trình xử lý sự kiện nội tuyến và URL javascript:. Bạn cần di chuyển nội dung của thẻ script sang tệp bên ngoài, đồng thời thay thế các URL javascript: và <a ...
onclick="[JAVASCRIPT]"> bằng lệnh gọi addEventListener() thích hợp. Ví dụ: bạn có thể viết lại nội dung sau từ:
<script>
function doAmazingThings() {
alert('YOU ARE AMAZING!');
}
</script>
<button onclick='doAmazingThings();'>Am I amazing?</button>
thành những thông tin khác như:
<!-- amazing.html -->
<script src='amazing.js'></script>
<button id='amazing'>Am I amazing?</button>
// amazing.js
function doAmazingThings() {
alert('YOU ARE AMAZING!');
}
document.addEventListener('DOMContentLoaded', function () {
document.getElementById('amazing')
.addEventListener('click', doAmazingThings);
});
Mã được viết lại không chỉ tương thích với CSP mà còn phù hợp với các phương pháp hay nhất về thiết kế web. JavaScript nội tuyến kết hợp cấu trúc và hành vi theo những cách khiến mã trở nên khó hiểu. Việc lưu vào bộ nhớ đệm và biên dịch cũng phức tạp hơn. Việc di chuyển mã ra các tài nguyên bên ngoài giúp các trang của bạn hoạt động hiệu quả hơn.
Bạn cũng nên di chuyển các thẻ và thuộc tính style cùng dòng vào các biểu định kiểu bên ngoài để bảo vệ trang web của mình khỏi các cuộc tấn công đánh cắp dữ liệu dựa trên CSS.
Cách tạm thời cho phép các tập lệnh và kiểu cùng dòng
Bạn có thể bật các kiểu và tập lệnh cùng dòng bằng cách thêm 'unsafe-inline' làm nguồn được phép trong lệnh script-src hoặc style-src. CSP cấp 2 cũng cho phép bạn thêm các tập lệnh cùng dòng cụ thể vào danh sách cho phép bằng cách sử dụng số chỉ dùng một lần mã hoá (số đã dùng một lần) hoặc hàm băm như sau.
Để sử dụng số chỉ dùng một lần, hãy cung cấp cho thẻ tập lệnh của bạn một thuộc tính số chỉ dùng một lần. Giá trị của lớp này phải khớp với một giá trị trong danh sách các nguồn đáng tin cậy. Ví dụ:
<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
// Some inline code I can't remove yet, but need to as soon as possible.
</script>
Thêm số chỉ dùng một lần vào lệnh script-src theo từ khoá nonce-:
Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'
Số chỉ dùng một lần phải được tạo lại cho mọi yêu cầu của trang và phải không thể đoán được.
Hàm băm hoạt động theo cách tương tự. Thay vì thêm mã vào thẻ tập lệnh, hãy tạo hàm băm SHA của chính tập lệnh và thêm hàm đó vào lệnh script-src.
Ví dụ: nếu trang của bạn có chứa:
<script>alert('Hello, world.');</script>
Chính sách của bạn phải có:
Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='
Tiền tố sha*- chỉ định thuật toán tạo hàm băm. Ví dụ trước sử dụng sha256-, nhưng CSP cũng hỗ trợ sha384- và sha512-. Khi tạo hàm băm, hãy bỏ qua các thẻ <script>. Vấn đề về cách viết hoa và khoảng trắng, bao gồm cả khoảng trắng ở đầu và cuối.
Các giải pháp tạo hàm băm SHA có sẵn bằng nhiều ngôn ngữ. Khi sử dụng Chrome 40 trở lên, bạn có thể mở Công cụ cho nhà phát triển rồi tải lại trang. Thẻ Bảng điều khiển sẽ hiển thị các thông báo lỗi kèm theo hàm băm SHA-256 chính xác cho mỗi tập lệnh cùng dòng.
Tránh eval()
Ngay cả khi không thể chèn tập lệnh trực tiếp, kẻ tấn công vẫn có thể đánh lừa ứng dụng của bạn chuyển đổi văn bản đầu vào thành JavaScript có thể thực thi rồi thay mặt chúng thực thi tập lệnh đó. eval(), new Function(), setTimeout([string], …) và setInterval([string], ...) đều là những vectơ mà kẻ tấn công có thể sử dụng để thực thi mã độc thông qua văn bản được chèn. Phản hồi mặc định của CSP đối với rủi ro này là chặn hoàn toàn tất cả các vectơ này.
Điều này có những ảnh hưởng sau đây trong cách bạn xây dựng ứng dụng:
- Bạn phải phân tích cú pháp JSON bằng
JSON.parsetích hợp sẵn, thay vì dựa vàoeval. Thao tác JSON an toàn có sẵn trên mọi trình duyệt kể từ IE8. Bạn phải ghi lại mọi lệnh gọi
setTimeouthoặcsetIntervalmà bạn thực hiện bằng các hàm cùng dòng thay vì chuỗi. Ví dụ: nếu trang của bạn có chứa những nội dung sau:setTimeout("document.querySelector('a').style.display = 'none';", 10);Viết lại dưới dạng:
setTimeout(function () { document.querySelector('a').style.display = 'none'; }, 10); ```Tránh tạo mẫu cùng dòng trong thời gian chạy. Nhiều thư viện tạo mẫu thường sử dụng
new Function()để tăng tốc độ tạo mẫu trong thời gian chạy, từ đó cho phép đánh giá văn bản độc hại. Một số khung hỗ trợ CSP ngay từ đầu, quay lại sử dụng trình phân tích cú pháp mạnh mẽ khi không cóeval. Lệnh ng-csp của AngularJS là một ví dụ điển hình cho trường hợp này. Tuy nhiên, thay vào đó, bạn nên sử dụng một ngôn ngữ mẫu có tính năng biên dịch sẵn, chẳng hạn như Thanh điều khiển. Việc biên dịch sẵn mẫu có thể giúp trải nghiệm người dùng nhanh hơn nữa so với cách triển khai nhanh nhất trong thời gian chạy, đồng thời giúp trang web của bạn bảo mật hơn.
Nếu eval() hoặc các hàm chuyển văn bản thành JavaScript khác cần thiết đối với ứng dụng của bạn, thì bạn có thể bật các hàm đó bằng cách thêm 'unsafe-eval' làm nguồn được phép trong lệnh script-src. Chúng tôi đặc biệt không khuyến khích việc này vì tính năng này có rủi ro chèn mã.
Báo cáo vi phạm chính sách
Để thông báo cho máy chủ về các lỗi có thể cho phép chèn phần mềm độc hại, bạn có thể yêu cầu trình duyệt gửi các báo cáo vi phạm theo định dạng JSON POST đến một vị trí được chỉ định trong lệnh report-uri:
Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;
Các báo cáo này trông giống như sau:
{
"csp-report": {
"document-uri": "http://example.org/page.html",
"referrer": "http://evil.example.com/",
"blocked-uri": "http://evil.example.com/evil.js",
"violated-directive": "script-src 'self' https://apis.google.com",
"original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
}
}
Báo cáo này chứa nhiều thông tin hữu ích giúp bạn tìm ra nguyên nhân gây ra lỗi vi phạm chính sách, bao gồm trang xảy ra lỗi trên (document-uri), referrer của trang đó, tài nguyên vi phạm chính sách của trang (blocked-uri), lệnh cụ thể mà trang đã vi phạm (violated-directive) và chính sách hoàn chỉnh của trang (original-policy).
Chỉ báo cáo
Nếu mới bắt đầu sử dụng CSP, bạn nên sử dụng chế độ chỉ báo cáo để đánh giá trạng thái của ứng dụng trước khi thay đổi chính sách. Để thực hiện việc này, thay vì gửi tiêu đề Content-Security-Policy, hãy gửi tiêu đề Content-Security-Policy-Report-Only:
Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;
Chính sách được chỉ định ở chế độ chỉ báo cáo không chặn tài nguyên bị hạn chế nhưng sẽ gửi báo cáo vi phạm đến vị trí bạn chỉ định. Thậm chí bạn có thể gửi cả hai tiêu đề để thực thi một chính sách trong khi theo dõi một chính sách khác. Đây là một cách hiệu quả để kiểm thử các thay đổi đối với CSP của bạn trong khi thực thi chính sách hiện tại: bật tính năng báo cáo cho một chính sách mới, theo dõi báo cáo lỗi vi phạm và khắc phục mọi lỗi. Khi bạn hài lòng với chính sách mới, hãy bắt đầu thực thi chính sách đó.
Cách sử dụng thực tế
Bước đầu tiên để tạo chính sách cho ứng dụng là đánh giá các tài nguyên mà ứng dụng tải. Khi bạn hiểu cấu trúc của ứng dụng, hãy tạo một chính sách dựa trên yêu cầu của ứng dụng. Các phần sau đây trình bày một số trường hợp sử dụng phổ biến và quy trình quyết định việc hỗ trợ những trường hợp đó tuân theo nguyên tắc của CSP.
Tiện ích mạng xã hội
- Nút Thích của Facebook có nhiều cách triển khai. Bạn nên dùng phiên bản
<iframe>để đặt hộp cát trên các phần còn lại của trang web. Lớp này cần có lệnhchild-src https://facebook.comđể hoạt động đúng cách. - Nút Tweet của X dựa trên quyền truy cập vào tập lệnh.
Di chuyển tập lệnh được cung cấp vào một tệp JavaScript bên ngoài và sử dụng lệnh
script-src https://platform.twitter.com; child-src https://platform.twitter.com. - Các nền tảng khác cũng có yêu cầu tương tự và có thể được giải quyết theo cách tương tự.
Để kiểm thử các tài nguyên này, bạn nên đặt
default-srclà'none'và xem bảng điều khiển để xác định tài nguyên nào cần bật.
Để sử dụng nhiều tiện ích, hãy kết hợp các lệnh như sau:
script-src https://apis.google.com https://platform.twitter.com; child-src https://plusone.google.com https://facebook.com https://platform.twitter.com
Phong tỏa
Đối với một số trang web, bạn cần đảm bảo rằng chỉ có thể tải các tài nguyên cục bộ. Ví dụ sau đây phát triển một CSP cho trang web của ngân hàng, bắt đầu bằng một chính sách mặc định chặn mọi thứ (default-src 'none').
Trang web tải tất cả hình ảnh, kiểu và tập lệnh từ CDN tại https://cdn.mybank.net và kết nối với https://api.mybank.com/ bằng XHR để truy xuất dữ liệu. Phương thức này sử dụng khung, nhưng chỉ đối với các trang cục bộ trên trang web (không có nguồn gốc của bên thứ ba). Trang web không có Flash, không có phông chữ, không có tính năng bổ sung. Tiêu đề CSP hạn chế nhất mà hệ thống có thể gửi là:
Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'
Chỉ SSL
Sau đây là ví dụ về CSP dành cho một quản trị viên diễn đàn muốn đảm bảo rằng tất cả tài nguyên trên diễn đàn của họ chỉ được tải bằng các kênh an toàn, nhưng thiếu kinh nghiệm lập trình và không có tài nguyên để viết lại phần mềm diễn đàn bên thứ ba gồm nhiều tập lệnh và kiểu cùng dòng:
Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'
Mặc dù https: được chỉ định trong default-src, nhưng tập lệnh và lệnh
không tự động kế thừa nguồn đó. Mỗi lệnh sẽ ghi đè giá trị mặc định cho loại tài nguyên cụ thể đó.
Phát triển tiêu chuẩn CSP
Chính sách bảo mật nội dung Cấp 2 là tiêu chuẩn được đề xuất của W3C. Nhóm hoạt động về bảo mật ứng dụng web của W3C đang phát triển phiên bản tiếp theo của quy cách, Chính sách bảo mật nội dung cấp 3.
Để theo dõi nội dung thảo luận về các tính năng sắp ra mắt này, hãy tham khảo bản lưu trữ danh sách gửi thưpublic-webappsec@.