前端專案資訊安全與 XSS 攻擊防範指南 實踐 API 安全認證與高品質登入實務流程

如何在前端專案中實踐高品質的資訊安全？

前端專案資訊安全 的核心在於建立高品質的防禦縱深。一套完整的 網站安全檢查 流程包含：1. 傳輸安全：透過 Cloudflare 等服務強制啟用 HTTPS 加密傳輸；2. 輸入驗證：嚴格實施 XSS 攻擊防範，利用 DOMPurify 處理動態內容，避免直接操作 innerHTML；3. 通訊防護：設定 API 安全保護，配置 Content-Security-Policy (CSP) 並移除敏感標頭（如 X-Powered-By）；4. 認證機制：深入理解 登入流程 Auth Token 原理，結合 Fingerprint 技術與雙 Token（Access/Refresh）交換機制。掌握這些 資安防護策略，能有效建構出符合現代高品質標準的 網站服務安全 體系。

在網路攻擊日益頻繁的今天，前端專案資訊安全已成為構建可靠網站服務的基石。本指南將全面解析網站安全檢查的關鍵環節，從源頭防範 XSS 攻擊防範，到確保 API 安全保護的溝通機制，再到強化使用者登入流程 Auth Token 的安全性。

透過深入了解這些資安防護策略與實戰技巧，開發者能夠有效應對潛在威脅，保護用戶數據，並確保網站服務的長期穩定運行。資訊安全，是為了保護機密資訊及維持系統的穩定。而網站的資安會建議從幾個常見流程來處理

1. 網址安全查詢
2. 輸入資料
3. API 溝通
4. 登入流程

網址安全查詢

輸入網址時需注意 https 和網址解析的方式，也可以透過相關服務去查詢該網址是否安全。

https 加密傳輸

Chrome 會自動遮蔽沒有加密的連線，沒有 https 網站會被警告。

網站 https 如何取得?

• cloudflare: 提供 DNS 免費服務，此外還提供 CDN 快取的機制和 DDoS 預防，可以說是網頁安全的無腦第一步
• sslforfree: 想自己安裝的免費解決方案

網址安全解析

網址解析時瀏覽器遇到 # 號時，# 後面會到 scrpit 中執行，預設會找該 id 的 element 並捲動到該位置。

舉例來說: http://localhost:3000/#/test 我們就可以透過 window.location.hash 得到 /test，可以使用 onhashchange 來監聽並做操作。

# 號只對瀏覽器產生有效事件且會被執行。

如果壞人利用這個來做惡意操作怎麼辦? 當未來看到有特殊符號的網址就不要亂點，若縮網址和 QRcode 進行包裝就更需要謹慎了。

網站 XSS

XSS 發生在輸入資料的過程中被攻擊，反過來想就是輸入惡意程式碼進去，<script>alert(0.0)</script> 這段程式碼會不會被執行?

舉例來說，可以避免傳入 href 當成參數，可能會造成漏洞。

1
2
3
4

<a href="javascript:void(0);">單擊此處什麼也不會發生</a>
<a href="javascript:void(document.form.submit());">
<a href="javascript:dangerous();" onclick="goToLink();">點我</a>

1
2
3
4
5
6
7
8

function validateURL(url) {
  const parsed = new URL(url)
  return ['https:', 'http:'].includes(parsed.protocol)
}

<a href={validateURL(url) ? url : ''}>Click here!</a>
<a href={attackerControlled}>Click here!</a>

前端若使用 react，在使用 dangerouslySetInnerHTML 這類包含危險提示的時候都該注意一點，dangerouslySetInnerHTML 先用相關工具處理，避免直接 this.myRef.current.innerHTML = attackerControlledValue;。

1
2
3

import purify from "dompurify";
<div dangerouslySetInnerHTML={{ __html:purify.sanitize(data) }} />

實作伺服器渲染過過程中，會需要把伺服器狀態重新給到前端的 store，這個時候這段就很有可能發生類似問題，可以做的是就是把 state 字串編碼再解碼。

API 溝通

資料傳輸的過程中會不會發生問題，瀏覽器很雞婆都會發 OPTIONS 方法送出請求到另一個網域，去確認是否跨網域以及方法是否可用，也就是我們常常聽到的 CORS 問題，那 API 會不會被機器人一直試? 就是看這一關有沒有擋，擋了之後有沒有可能在 client 端被偽裝，如果不是專業的，要怎麼預防，express 有相關說明及建議:

• Content-Security-Policy 標頭，以防範跨網站 Scripting 攻擊和其他跨網站注入。
• 移除 X-Powered-By 標頭。
• Public Key Pinning 標頭，來防範使用偽造憑證的中間人攻擊。
• Strict-Transport-Security 標頭，以施行安全的 (HTTP over SSL/TLS) 伺服器連線。
• X-Download-Options（適用於 IE8+）。
• Cache-Control 和 Pragma 標頭，以停用用戶端快取。
• X-Content-Type-Options，以阻止瀏覽器對脫離所宣告內容類型的回應進行 MIME 探查。
• X-Frame-Options 標頭，以提供 clickjacking 保護。
• X-XSS-Protection，以便在最新的 Web 瀏覽器中啟用跨網站 Scripting (XSS) 過濾器。

交換資料再加上鑰匙，也就是伺服器端可以產生伺服器的 cookies 或是短時效性的 token，client 端能做的就是把自己的資訊跟伺服器講，像是產生 fingerprint，這樣伺服器至少可以保證每次的請求都是當下這個環境來的，把這兩種訊息做結合判斷，應該可以擋掉部分偽裝的請求。

登入流程的 Auth 和 Token 原理

cookies 的使用，一來可以辨認身分，二來也可以用來儲存狀態，最後就是因為會跟著請求回到伺服器，所以廣告業也可以用這樣的方式在目標對象按按鈕的時候得到相關資訊，那每次的無痕都會是一個新的環境，fingerprint 會不一樣，當然最快的絕對不是記錄環境，而是直接讓使用者按按鈕，把該打的東西一起傳回伺服器像是 facebook pixel，這樣下次就可以在臉書打到使用者了，最近因為 GDPR 的關係，很多東西變得比較嚴格，原則上只有自己的網域可以使用，那子網域怎麼辦，當然設計上沒有這麼死板，設定一下還是一樣可以使用的，畢竟是同個域名。

如果沒有實作 cookies? sessionStorage 和 localStorage 的組合技也是一個可以保持登入狀態的方式，token 就需要有交換機制，當然最好的也是配合儲存一下使用者的環境，架構如下圖，資料來源(https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/)。

FAQ：前端資訊安全常見問題

Q1：XSS 與 CSRF 攻擊的主要區別是什麼？

A：XSS 攻擊防範 關注的是「信任惡意腳本」，即攻擊者將程式碼植入您的網頁並執行。而 CSRF (跨站請求偽造) 則是「信任惡意請求」，攻擊者利用您在瀏覽器中已登入的身份（Cookies），在您不知情的情況下代表您發送請求。高品質的防禦應同時包含 XSS 淨化（如 DOMPurify）與 CSRF Token 驗證。

Q2：將 Auth Token 存儲在 LocalStorage 還是 HttpOnly Cookie 比較安全？

A：LocalStorage 容易受到 XSS 攻擊，因為 JavaScript 腳本可以直接讀取其中的內容。HttpOnly Cookie 則是更安全的高品質選擇，因為它禁止 JavaScript 存取，能有效防止 Token 被盜。然而，使用 Cookie 需注意 CSRF 防護。建議採用「短時效 Access Token (存於記憶體)」配合「長時效 Refresh Token (存於 HttpOnly Cookie)」的組合架構。

Q3：Content-Security-Policy (CSP) 的實務價值為何？

A：CSP 是前端資安的「終極守門員」。透過設定高品質的 CSP 標頭，您可以告訴瀏覽器：僅允許執行來自「白名單網域」的腳本、禁止所有內嵌 (inline) 腳本執行。這意謂著即使您的網站存在 XSS 漏洞，攻擊者植入的惡意程式碼也會因不符合 CSP 規則而被瀏覽器攔截，極大降低了 前端專案資訊安全 的風險。

• ← 上一篇
• 下一篇 →