<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Csp on Commentary of Takao</title><link>https://takao.blog/zh-tw/tags/csp/</link><description>Recent content in Csp on Commentary of Takao</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Commentary of Takao</copyright><lastBuildDate>Wed, 15 Jul 2026 22:01:08 +0900</lastBuildDate><atom:link href="https://takao.blog/zh-tw/tags/csp/index.xml" rel="self" type="application/rss+xml"/><item><title>為 Hugo 部落格設計現代內容安全策略</title><link>https://takao.blog/zh-tw/web/hugo-latest-csp-best-practices-2026/</link><pubDate>Fri, 05 Jun 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/zh-tw/web/hugo-latest-csp-best-practices-2026/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/hugo-latest-csp-best-practices-2026-zh-tw.png" alt="Featured image of post 為 Hugo 部落格設計現代內容安全策略" /&gt;&lt;h2 id="為什麼-csp-對於靜態網站很重要"&gt;為什麼 CSP 對於靜態網站很重要
&lt;/h2&gt;&lt;p&gt;使用 Hugo 建立的靜態網站本質上比動態應用程式更安全，但它們仍然執行用於分析、廣告和嵌入的第三方腳本。 &lt;strong&gt;內容安全策略 (CSP)&lt;/strong&gt; 透過控制可以載入的資源來保護您的訪客免受 XSS、資料注入和惡意腳本執行的侵害。&lt;/p&gt;</description></item><item><title>Testing CSP 規矩 Safely with Content-Security-Policy-Report-Only</title><link>https://takao.blog/zh-tw/web/security-content-security-policy-csp-report-only/</link><pubDate>Fri, 15 May 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/zh-tw/web/security-content-security-policy-csp-report-only/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/security-content-security-policy-csp-report-only-zh-tw.png" alt="Featured image of post Testing CSP 規矩 Safely with Content-Security-Policy-Report-Only" /&gt;&lt;h2 id="the-broken-widget-problem"&gt;The Broken-Widget Problem
&lt;/h2&gt;&lt;p&gt;Deploying a Content Security Policy is one of the strongest defenses against XSS attacks. But a single misconfigured directive can silently break inline scripts, block CDN resources, or disable analytics. If you apply CSP directly via the &lt;code&gt;Content-Security-Policy&lt;/code&gt; header and a critical script gets blocked, your production site breaks—often without an obvious error console notification.&lt;/p&gt;
&lt;p&gt;This is where &lt;strong&gt;Report-Only mode&lt;/strong&gt; saves the day.&lt;/p&gt;</description></item><item><title>Why and 如何 Adopt 'strict-dynamic' in CSP</title><link>https://takao.blog/zh-tw/web/security-csp-strict-dynamic-implementation/</link><pubDate>Sun, 15 Jun 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/zh-tw/web/security-csp-strict-dynamic-implementation/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/security-csp-strict-dynamic-implementation-zh-tw.png" alt="Featured image of post Why and 如何 Adopt 'strict-dynamic' in CSP" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;Implementing a &lt;strong&gt;Content Security Policy (CSP)&lt;/strong&gt; is a highly effective way to mitigate Cross-Site Scripting (XSS) risks. However, configuring and maintaining the policy can become a major headache.&lt;/p&gt;
&lt;p&gt;For websites utilizing third-party SDKs (such as Google Tag Manager, analytics beacons, 支付 widgets, or social sharing buttons), these scripts often dynamically load (inject) additional scripts from nested domains. This forces developers to maintain a long, fragile whitelist of external domains in the &lt;code&gt;script-src&lt;/code&gt; directive.&lt;/p&gt;</description></item></channel></rss>