今天在網上浪了許久，只是為了找一個很簡單的配置，卻奈何怎么都找不到。
好不容易找到了，我覺得還是記錄下來的好，或許省得許多人像我一樣浪費時間。
1.X-Frame-Options
如果網站可以嵌入到IFRAME元素中，則攻擊者可以在社交場合設計一種情況，即受害者被指向攻擊者控制的網站，該網站構成目標網站的框架。然后攻擊者可以操縱受害者在目標網站上不知不覺地執行操作。即使有跨站點請求偽造保護，這種攻擊也是可能的，並且被稱為“clickjacking”，有關更多信息，請參閱https://www.owasp.org/index.php/Clickjacking。為了避免這種情況，創建了“X-Frame-Options”標題。此標題允許網站所有者決定允許哪些網站構建其網站。
通常的建議是將此標頭設置為“SAMEORIGIN”，它只允許屬於同源策略的資源構成受保護資源的框架，或者設置為“DENY”，它拒絕任何資源（本地或遠程）嘗試框架也提供“X-Frame-Options”標頭的資源。如下所示：
X-Frame-Options：SAMEORIGIN
請注意，“X-Frame-Options”標題已被棄用，將由內容安全策略中的Frame-Options指令替換，該指令仍處於活動開發階段。但是，“X-Frame-Options”標題目前具有更廣泛的支持，因此仍應實施安全措施。
說白了呢，就是讓你的網站禁止被嵌套。
其實也很簡單（我還在網上搜羅了半天）
配置文件config
<httpProtocol>
<customHeaders>
<add name="X-Frame-Options" value="SAMEORIGIN" />
</customHeaders>
</httpProtocol>
</system.webServer>
2.Content-Security-Policy
內容安全策略（CSP）旨在允許Web應用程序的所有者通知客戶端瀏覽器有關應用程序的預期行為（包括內容源，腳本源，插件類型和其他遠程資源），這允許瀏覽器更多智能地執行安全約束。雖然CSP本質上是復雜的，如果沒有適當部署它可能會變得混亂，一個應用良好的CSP可以大大降低利用大多數形式的跨站點腳本攻擊的機會。
需要整個帖子來深入了解CSP允許的功能和不同設置，因此建議進一步閱讀。以下是Mozilla開發者網絡對CSP的精彩介紹性帖子：https：//developer.mozilla.org/en-US/docs/Web/Security/CSP
下面的簡要示例顯示了如何使用CSP指定您的網站希望從任何URI加載圖像，從受信任的媒體提供商（包括內容分發網絡）列表中插入插件內容，以及僅從您控制的服務器加載腳本：
Content-Security-Policy：default-src'self'; img-src *; object-src media1.example.com media2.example.com * .cdn.example.com; script-src trustedscripts.example.com
請注意，使用CSP的主要問題涉及策略錯誤配置（即使用“不安全內聯”），或使用過於寬松的策略，因此在實施CSP時應特別注意。
這個呢，是將你引入的一切，加一個限制，這樣如果別人想通過一些手段在你的網站加一些不好的東西，我們就可以有效地防止了
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="script-src 'unsafe-inline' http://localhost:56504; object-src 'none'; style-src 'unsafe-inline' http://localhost:56504;" />
</customHeaders>
</httpProtocol>
</system.webServer>
其中預設值有以下這些：
none不匹配任何東西。self匹配當前域，但不包括子域。比如example.com可以，api.example.com則會匹配失敗。unsafe-inline允許內嵌的腳本及樣式。是的，沒看錯，對於頁面中內嵌的內容也是有相應限制規則的。unsafe-eval允許通過字符串動態創建的腳本執行，比如eval，setTimeout等。
3.X-Content-Type-Options
一種稱為MIME類型混淆的漂亮攻擊是創建此標頭的原因。大多數瀏覽器采用稱為MIME嗅探的技術，其中包括對教育服務器響應的內容類型進行教育猜測，而不是信任標頭的內容類型值。在某些情況下，瀏覽器可能會被欺騙做出錯誤的決定，允許攻擊者在受害者的瀏覽器上執行惡意代碼。有關更多信息，請參閱https://en.wikipedia.org/wiki/Content_sniffing。
“X-Content-Type-Options”可用於通過將此標頭的值設置為“nosniff”來防止發生這種“受過教育”的猜測，如下所示：
X-Content-Type-Options：nosniff
請注意，Internet Explorer，Chrome和Safari都支持此標題，但Firefox團隊仍在辯論它：https：//bugzilla.mozilla.org/show_bug.cgi？ id = 471020
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="nosniff" />
</customHeaders>
</httpProtocol>
</system.webServer>
4.X-XSS-Protection
現代瀏覽器包括一項有助於防止反映跨站點腳本攻擊的功能，稱為XSS過濾器。“X-XSS-Protection”標頭可用於啟用或禁用此內置功能（目前僅在Internet Explorer，Chrome和Safari中支持此功能）。
建議的配置是將此標頭設置為以下值，這將啟用XSS保護並指示瀏覽器在從用戶輸入插入惡意腳本時阻止響應，而不是清理：
X-XSS-Protection：1; mode = block。
如果沒有從服務器發送“X-XSS-Protection”標頭，Internet Explorer和Chrome將默認清理任何惡意數據。
請注意，X-XSS-Protection標頭已被棄用，將被內容安全策略中的Reflected-XSS指令取代，該指令仍處於活動開發階段。但是，“X-XSS-Protection”標題目前有更廣泛的支持，因此仍應實施安全措施。
0 – 關閉對瀏覽器的xss防護 1 – 開啟xss防護 1; mode=block – 開啟xss防護並通知瀏覽器阻止而不是過濾用戶注入的腳本。 1; report=http://site.com/report – 這個只有chrome和webkit內核的瀏覽器支持，這種模式告訴瀏覽器當發現疑似xss攻擊的時候就將這部分數據post到指定地址。
配置方法
<httpProtocol> <customHeaders> <add name="X-XSS-Protection" value="1;mode=block" /> </customHeaders> </httpProtocol> </system.webServer>
這就是困擾了我許久，網上又找不到的幾個安全配置
文中介紹引自 ： https://www.dionach.com/blog/an-overview-of-http-security-headers
如果大家想要更深入了解，這是我一下午找的資料
https://www.cnblogs.com/alisecurity/p/5924023.html
https://www.cnblogs.com/Wayou/p/intro_to_content_security_policy.html
https://www.cnblogs.com/doseoer/p/5676297.html
網址安全型檢測
https://tools.geekflare.com/report/xss-protection-test/http://hgwebsite.cn/
學習的道路是漫長的