嗨，各位路過的探險家！今天來聊聊我們網站的超級門神 ── WAF 防火牆。

這個系統就像是一個戒備森嚴的城堡，為了不讓壞人進來搗亂，門神阿福手上有一張點名簿，也就是所謂的白名單。只要你的 IP 位址不在這張點名簿上，阿福就會直接把你塞進小黑屋，連大門口都進不來。

最厲害的是，阿福非常有個性，他只保護特定的城堡。就算隔壁的系統不小心被圍攻，我們 Project Name 這邊依然穩如泰山。

阿福的點名簿現況

目前只有拿到特別通行證的網段才能順利通行：

• 某神秘機房專區： 192.168.1.0/24
• 核心團隊的秘密基地： 192.168.2.0/24
• 測試專用通道： 192.168.3.0/24
• 管理員的個人特權 IP： 203.0.113.89

前置作業：請出管理員鑰匙

在指揮阿福修改點名簿之前，請先確認你已經切換到正確的管理帳號，不然阿福是絕對不會理你的。

指令如下：

az account set –subscription “請輸入你的雲端帳號萬用鑰匙代碼”

新增特權 IP 的四大步驟

假設今天有兩組好朋友，一組是 192.168.99.0/24 的新同學，另一組是 198.51.100.6 的外包夥伴，想要加入點名簿。請跟著以下步驟做：

步驟 1：偷看目前的點名簿

先把阿福現在手上到底登記了誰調查清楚。

az network application-gateway waf-policy custom-rule show –policy-name 門神名稱 –resource-group 城堡名稱 –name 規則名稱 –query “matchConditions[0].matchValues” -o json

步驟 2：大家排排站，準備新名單

請把剛剛查出來的舊名單複製出來，然後把新朋友的名字加進去，排成一列。

步驟 3：大手一揮，整張蓋過去

超級重要： 阿福很健忘，你不能只跟他說我要加兩個人，你要給他一張全新的完整名單，否則舊的人會被他通通忘光光。

我們會用一個腳本把新舊名單綁在一起，然後直接覆蓋：

$allIPs = @(

“192.168.1.0/24”,

“192.168.2.0/24”,

“192.168.3.0/24”,

“203.0.113.89”,

“192.168.99.0/24”, # 這是新朋友一號

“198.51.100.6” # 這是新朋友二號

)

（接下來把這串名單打包成 JSON 格式後，用雲端指令送給阿福更新。因為指令比較長，這裡就不贅述，重點是名單要帶齊。）

步驟 4：檢查阿福有沒有認真工作

更新完之後，再次叫阿福把名單拿出來核對，看看剛才加的新朋友是不是都在上面了。

如果想踢掉某個 IP 呢

方法完全一樣。先去步驟 1 看名單，在步驟 2 的時候拿橡皮擦把不想看到的人擦掉，最後用步驟 3 的覆蓋大法，這個人就被阿福除名了。

實地測試：看看阿福有沒有偷懶

名單改完之後，我們一定要來測試看看阿福是不是真的有在認真抓壞人：

• 叫沒拿通行證的朋友點網址： 如果畫面跳出 403 錯誤，代表被阿福成功攔截，阿福好棒。
• 自己人從白名單點網址： 如果正常顯示網頁，代表通行無阻。

筆記小重點

• 隔壁鄰居很安全： 這個點名簿設定只針對我們 Project Name ，完全不會影響到同一個伺服器底下的其他系統。
• 覆蓋完請稍等： 阿福收到新名單後，大概需要 1 到 2 分鐘的時間來認熟面孔，請給他一點時間。
• 附贈隱形護盾： 除了不讓陌生人進來，阿福同時還開啟了國際防禦標準，一般的網路流氓就算換了白名單 IP 進來，只要手腳不乾淨一樣會被抓走喔。

如果你想使用 Azure Portal 網頁畫面來操作，步驟非常直覺，請跟著以下步驟點選。

第一步、登入與尋找策略

首先打開瀏覽器登入 Azure Portal 網站。在網頁最上方的搜尋欄輸入 Web Application Firewall policies 或是 WAF 策略，然後點選進入。

第二步、選擇特定的策略

在列表中找到並點選你正在使用的 WAF 策略名稱。

第三步、進入自訂規則

進入該策略的頁面後，查看左側的選單，在設定區塊中，點選自訂規則。

第四步、修改名單

在自訂規則的列表中，點選你用來管制 IP 的那一條規則。點開之後，你會看到比對條件，找到比對變數為 RemoteAddr 的那一項，你就可以直接在下方的數值列表中，新增或刪除你要異動的 IP 位址。

第五步、儲存更新

修改完成後，點選畫面最上方的儲存按鈕。系統大約需要 1 到 2 分鐘的時間將新名單同步到防火牆。

在 Azure 的網路安全性群組（NSG）世界裡，有時候我們會遇到一個很像「既要又要」的邊緣狀況：你想要同時把好幾個 Port 關起來，不讓壞人進來，但同時又希望特定幾位好朋友（白名單 IP）可以大搖大擺地走進去。

要同時做到阻擋大家又放行自己人，最乾淨也最聰明的作法，就是利用兩條規則的「優先順序（Priority）」差來玩一場網路版的邏輯遊戲。

因為 Azure NSG 這個門神在檢查規則時，是採取「由上到下」比對的。數字越小的規則越優先執行，而且只要一比對成功，它就會直接定案，懶得再看下面的規則了。

核心邏輯大公開

簡單來說，你只需要左右開弓，建立以下兩條規則：

重要提醒：允許（Allow）規則的 Priority 數字（例如 300）必須小於阻擋（Deny）規則的 Priority 數字（例如 301）。如果把阻擋數字寫得太小，門神就會先把大家都趕走，你的好朋友就再也進不來了。

詳細設定步驟（Azure Portal 傳送門操作）

請直接移駕到你的 NSG （azure vmptstgjpe001-nsg）的「輸入安全性規則（Inbound security rules）」頁面，深呼吸之後點選「新增（Add）」：

步驟 1：建立白名單允許規則

1. Source（來源）：下拉選單請選 IP Addresses。
2. Source IP addresses（來源 IP 位址）：輸入你想放行的白名單 IP。如果好朋友有點多，可以用半形逗號隔開，例如： 1.1.1.1, 2.2.2.0/24。
3. Source port ranges（來源連接埠範圍）：維持預設的 * 號就好。
4. Destination（目的地）：選 Any 或是直接指定那一台 VM 的內網 IP。
5. Destination port ranges（目的連接埠範圍）：輸入你想控制的多個 Port，中間記得用半形逗號隔開，例如： 80, 443, 8080。
6. Protocol（通訊協定）：看你心情與需求，選 TCP、UDP 或是 Any。
7. Action（動作）：大方地選擇 Allow。
8. Priority（優先順序）：給它一個比較小的數字，例如 300。
9. Name（名稱）：取一個好辨識的名字，像是 Allow_Whitelist_MultiPorts。

步驟 2：建立其餘全部阻擋規則

再次點選「新增（Add）」來建立第二道關卡：

1. Source（來源）：這次要選 Any，代表任何路人甲乙丙。
2. Source port ranges：一樣維持 * 號。
3. Destination：選 Any。
4. Destination port ranges：請輸入與步驟 1 完全一模一樣的多個 Port，例如： 80, 443, 8080。
5. Protocol：請與步驟 1 保持同步。
6. Action（動作）：這次要狠下心選擇 Deny。
7. Priority（優先順序）：數字必須比步驟 1 還要大，例如 301。
8. Name（名稱）：給它一個威武的名字，像是 Deny_All_MultiPorts。

進階管理小技巧

如果你的白名單 IP 常常像天氣一樣變來變去，或者你手底下的 VM 越來越多，每次都要手動來改 NSG 規則真的會讓人想砸鍵盤。

這時候建議可以利用「應用程式安全性群組（Application Security Group, ASG）」或者 Azure 的「IP Groups」功能。這就像是把所有好朋友的名字直接打包進一個群組懶人包，以後 NSG 規則的來源直接指定這個群組就可以了，管理起來輕鬆到可以提早下班！

以下為你整理出最流暢的申請 4 大步驟：

第一步：建立新專案

1. 前往 Google Cloud Console。
2. 登入你的 Google 帳號。
3. 點擊左上角的專案下拉選單，選擇 「新建專案」 (New Project)。
4. 輸入專案名稱（例如：MyAwesomeApp），然後點擊 「建立」。

第二步：設定 OAuth 同意畫面 (OAuth Consent Screen)

這是使用者在登入你的 App 時會看到的授權畫面，必須先設定它。

1. 點擊左側選單的 「API 和服務」 > 「OAuth 同意畫面」。
2. 選擇 User Type：
   • 外部 (External)： 開放給所有 Google 帳號（一般應用程式選這個）。
   • 內部 (Internal)： 僅限你 Google Workspace 組織內的成員（企業內部工具選這個）。
3. 填寫基本資料：應用程式名稱、使用者支援電子郵件 以及 開發人員聯絡資訊，完成後點擊「儲存並繼續」。
4. 範圍 (Scopes)： 設定你想拿到的權限（如 email, profile）。初次測試可以先不選，直接跳過。
5. 測試使用者 (Test Users)： 如果你的專案還在「測試中」階段，必須在這裡新增你自己的測試 Email，否則其他帳號會無法登入。

第三步：建立憑證 (Credentials) 取得密鑰

這一步會生成你的 Client ID 和 Client Secret。

1. 點擊左側選單的 「憑證」 (Credentials)。
2. 點擊上方的 「+ 建立憑證」 > 「OAuth 用戶端 ID」。
3. 選擇你的 應用程式類型（例如：網頁應用程式、Android、iOS 等）。
4. 填寫核心網址（以網頁應用程式為例）：
   • 已授權的 JavaScript 來源： 你的網站首頁（例如：http://localhost:3000 或 https://yourdomain.com）。
   • 已授權的重新導向 URI： 使用者登入成功後，Google 把 Code 送回你網站的後端路由（例如：http://localhost:3000/auth/google/callback）。※ 注意：這裡一定要設定精準，否則會噴 redirect_uri_mismatch 錯誤。
5. 點擊 「建立」。

恭喜！ 畫面上會跳出你的 用戶端 ID (Client ID) 和 用戶端密鑰 (Client Secret)。請立刻複製並妥善保管，密鑰絕對不能外流！

第四步：切換為「生產模式」（選填）

在開發測試階段，你的專案狀態會是「測試中 (Testing)」，只有你在第二步設定的測試小夥伴能登入，且可能會有不安全應用的警告。

• 當你的 App 準備好上線時，回到 「OAuth 同意畫面」，點擊 「發布應用程式」 (Publish App) 切換為正式生產模式。
• 備註：如果你申請了敏感權限（如讀取使用者的 Gmail 私訊），Google 會需要人工審查，可能需要幾天到幾週的時間。

我有測試環境 domain name 與正式環境 domain name 要申請2組 OAuth 2.0 用戶端 ID 嗎? 還是同一組ID即可。

建議申請「2 組獨立的 OAuth 2.0 用戶端 ID (Client ID)」。

雖然在技術上，Google 允許你在同一組 Client ID 的「已授權的重新導向 URI」中，同時填入測試環境與正式環境的網址，但非常強烈建議分開申請。原因如下：

1. 安全性考量（最重要的原因）

• 憑證外流風險： 測試環境通常防護較弱，可能會有較多開發人員、測試人員接觸到設定檔。如果測試環境的 Client Secret（用戶端密鑰）不小心外流，且你兩邊用同一組 ID，攻擊者就能利用外流的密鑰去染指或偽造正式環境的登入請求。
• 網址白名單污染： 萬一測試環境網址被惡意劫持或存在漏洞，它與正式環境共享同一個 OAuth 信任圈，會帶來額外的安全隱患。

2. Google 審查與「發布狀態」限制

Google Cloud 專案的 OAuth 同意畫面有分兩種狀態：

• 測試中 (Testing)： 只有白名單內的「測試使用者」可以登入，且登入時會跳出「未經驗證的應用程式」警告。
• 生產模式 (In Production)： 開放給所有 Google 帳號登入。如果使用了敏感權限（Scopes），還需要通過 Google 的人工驗證。

如果你只用一組：

當你的專案為了正式環境切換成「生產模式」並送交審查時，如果你的網址白名單裡還夾帶了 project-name.test.example.com.tw（而且通常測試環境在外網無法被 Google 審查官順利連上），這可能會導致你的 Google 審查被拒絕 (Rejected)，因為 Google 要求生產模式下的網址必須是公開、真實且符合規範的。

最佳實作做法 (Best Practice)

為了架構清晰與安全，你可以選擇以下兩種配置方式：

方案 A：在同一個 Google Cloud 專案下，建立 2 個 Client ID（推薦，最方便）

在同一個專案的「憑證」頁面中，點擊兩次「建立憑證 > OAuth 用戶端 ID」：

• 第一組 ID（命名：Project Name – Test）：
  • 重新導向 URI 填：https://projectname.test.example.com.tw/oauth2/callback
• 第二組 ID（命名：Project Name – Prod）：
  • 重新導向 URI 填：https://projectname.example.com.tw/oauth2/callback

這樣你在程式碼的環境變數（.env）中，測試機就讀取測試的 ID/Secret，正式機就讀取正式的 ID/Secret，彼此互不干擾。

方案 B：建立 2 個獨立的 Google Cloud 專案（最嚴謹）

• 專案一：PorjectName-Test（專案狀態保持在 Testing，方便開發隨時測試）
• 專案二：PorjectName-Prod（專案狀態切換為 Production，專門用來跑正式上線與 Google 審查流程）

總結： 為了維護系統的安全防線與後續維護的便利性，請務必為測試與正式環境分開申請獨立的憑證！

應用程式是哪種類型, Vue 3 + Vite

既然你的前端技術棧是 Vue 3 + Vite，在架構設計上你首先需要釐清一個關鍵問題：你的應用程式有沒有後端（Backend，如 Node.js, Python, Go）？

這會直接決定你如何實作 Google OAuth。以下為你說明這兩種情境與實作方式：

情境一：有後端（推薦，最安全）

這是最正統的做法。Vue 3 只負責顯示「登入按鈕」，使用者點擊後會引導到 Google 登入，登入成功後 Google 會把驗證碼（Authorization Code）傳給你的後端，由後端去跟 Google 交換 Token，並簽發你網站自己的 JWT 給 Vue 3。

在這種模式下，你的 OAuth 2.0 用戶端 ID 類型要選擇：「網頁應用程式」 (Web Application)。

Vite / Vue 3 前端實作步驟：

目前社群上最推崇、封裝最完整的套件是 vue3-google-signin。

安裝套件：Bash

npm install vue3-google-signin

在 main.js 或 main.ts 中初始化：

import { createApp } from 'vue'
import App from './App.vue'
import GoogleSignInPlugin from 'vue3-google-signin'

const app = createApp(App)

app.use(GoogleSignInPlugin, {
  // Vite 的環境變數必須以 VITE_ 開頭
  clientId: import.meta.env.VITE_GOOGLE_CLIENT_ID,
})

app.mount('#app')

在畫面上建立登入按鈕 (Login.vue)：

<script setup>
import { GoogleLogin } from 'vue3-google-signin'

const handleLoginSuccess = (response) => {
  // 這裡會拿到 Google 回傳的 code 或 credential
  console.log("Google 登入成功:", response);

  // 【關鍵】將這個 response (含 code) 用 axios 傳送給你的後端
  // axios.post('https://projectname.example.come.tw/api/auth/google', { code: response.code })
}

const handleLoginError = () => {
  console.error("Google 登入失敗")
}
</script>

<template>
  <div class="login-container">
    <h2>入口網登入</h2>
    <GoogleLogin :callback="handleLoginSuccess" :popup-type="'CODE'" @error="handleLoginError" />
  </div>
</template>

情境二：純前端（SPA 單頁應用，無後端）

如果你的 Vue 3 是一個完全靜態的網站，沒有任何自己的後端資料庫，單純只想確認「他是誰」或者想在前端呼叫 Google API（例如讀取他的 Google Calendar）。

在這種模式下，你的 OAuth 2.0 用戶端 ID 類型一樣選擇：「網頁應用程式」。但流程會走「隱含授權 (Implicit Flow)」，直接在前端取得 access_token。

安全警告： 因為純前端沒有秘密可言，你的 Client Secret 絕對不能寫在 Vue 3 的原始碼或 .env 裡（因為打包後任何人都能看光）。在 Google Console 建立憑證時，這種模式通常不需要用到 Client Secret。

前端設定差異：

如果你是用上面提到的 vue3-google-signin，在按鈕上就不要加 :popup-type="'CODE'"，它預設會直接在前端回傳一串 JWT（身分憑證），你可以直接解開它來取得使用者的 Email 和姓名：

JavaScript

import { decodeCredential } from 'vue3-google-signin'

const handleLoginSuccess = (response) => {
  // 直接在前端解密 Google 回傳的使用者資訊
  const userData = decodeCredential(response.credential)
  console.log("使用者資料:", userData) // 包含 email, name, picture
}

搭配你上一題的測試/正式環境，Vite 該如何設定？

因為你有兩個環境，請在 Vue 3 專案根目錄建立兩個環境變數檔案：

1. .env.development (測試環境用)程式碼片段VITE_GOOGLE_CLIENT_ID=你的測試環境_CLIENT_ID.apps.googleusercontent.com
2. .env.production (正式環境用)程式碼片段VITE_GOOGLE_CLIENT_ID=你的正式環境_CLIENT_ID.apps.googleusercontent.com

當你執行 vite preview 或 vite build 時，Vite 就會自動根據環境抓取正確的 Client ID，完美對應到正式環境與測試環境了！

這裡幫大家整理了 4 個超實用的方法，不管是想要神級的操作體驗，還是懶得安裝任何軟體的速成法，這篇通通有。

方法 1 ： VS Code 神級流暢體驗（強烈推薦）

如果你平常就在用 Visual Studio Code 寫程式，這絕對是最頂的選擇，可以享受一邊打字、旁邊畫面一邊即時更新的快感。

1. 打開 VS Code ，到擴充功能市場搜尋並安裝 PlantUML 這個套件。
2. 注意，這裡有一個重要的小跟班需要安裝。因為 PlantUML 畫圖需要 Graphviz 的協助，請打開命令提示字元輸入 winget install Graphviz 來快速搞定它。
3. 如果真的懶得在電腦安裝 Graphviz 怎麼辦？也可以直接到 VS Code 的設定裡搜尋 plantuml.server ，把它改成連到官方的線上伺服器來幫你畫圖。
4. 萬事俱備後，打開 .puml 檔案，按下 Alt + D ，右邊就會跳出即時預覽畫面。

方法 2 ： JetBrains 宇宙（ IntelliJ 、 PyCharm 專屬）

如果你是 JetBrains 系列 IDE 的忠實粉絲，根本不用離開視窗，裡面就自帶強大功能。

1. 點選 File 進入 Settings ，接著找到 Plugins 區塊。
2. 搜尋 PlantUML Integration 並點擊安裝。
3. 把 IDE 重新啟動。
4. 接下來只要打開任何 .puml 檔案，右邊就會自動長出專屬的預覽視窗，完全不用操心。

方法 3 ： 獨立 Java 檔案（免安裝開發工具）

如果不想為了看張圖就開啟笨重的開發工具，也可以用官方提供的輕量級 Java 小工具。

1. 請先確保電腦裡有安裝 Java 執行環境。
2. 到 PlantUML 官方網站 下載 plantuml.jar 檔案。
3. 打開命令提示字元，切換到下載的資料夾，輸入 java -jar plantuml.jar -gui 這一行指令。
4. 畫面上就會跳出一個小巧的視窗，只要選好放 .puml 檔案的資料夾，每次只要存檔，它就會自動幫你刷新圖片。

方法 4 ： 線上免安裝（終極懶人法）

如果只是臨時要看一下檔案，連一秒鐘都不想浪費在安裝上，那就直接交給瀏覽器吧。

• 官方線上伺服器：直接把程式碼複製貼上到 PlantUML Web Server 就能立刻看到結果。
• 網頁編輯器： PlantText 是一個非常受歡迎的線上即時編輯器，畫面好看而且專為 PlantUML 設計，非常適合臨時救急。

在 Windows 執行 ssh 顯示錯誤訊息

C:\Users\max>ssh 4.216.213.123
Bad permissions. Try removing permissions for user: BUILTIN\\Users (S-1-5-32-545) on file C:/Users/max/.ssh/vm-max-pc-key.pem.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'C:\\Users\\max/.ssh/vm-max-pc-key.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "C:\\Users\\max/.ssh/vm-max-pc-key.pem": bad permissions
azureuser@4.216.213.123: Permission denied (publickey).

在使用 Windows 系統連線到遠端伺服器的時候，是不是常常遇到 SSH 跟你鬧脾氣？

畫面跳出一大串警告，寫著 WARNING UNPROTECTED PRIVATE KEY FILE ，然後無情地拒絕連線。這其實不是你的伺服器壞掉，而是 SSH 的安全機制太過傲嬌。它覺得你的金鑰檔案太過公開，像是把家裡鑰匙直接貼在大門口一樣危險，所以故意裝作不認識你。

這個問題通常是因為金鑰檔案的權限開太大，導致系統內的其他使用者也能讀取。要解決這個尷尬的狀況，有兩種快速的方法可以馴服它。

第一種方法是使用命令提示字元。

請開啟命令提示字元，並依序輸入以下指令。記得將路徑換成自己的金鑰檔案路徑。

第一步是取消繼承權限，指令為

icacls C:\Users\your_username\.ssh\my_key.pem /inheritance:r

第二步是重新給予自己完整的控制權限，指令為

icacls C:\Users\your_username\.ssh\my_key.pem /grant:r your_username:F 

第二種方法是使用圖形介面，適合喜歡用滑鼠點擊的人。

請打開檔案總管，找到金鑰檔案。在檔案上按右鍵選擇內容，切換到安全性標籤，接著點擊進階。

在進階安全性設定視窗中，點擊停用繼承，並選擇將繼承的權限轉換為此物件的明確權限。

最後在權限項目清單中，找到 Users 這個群組並將它移除，只留下自己的使用者帳號擁有存取權限。點擊套用並確定就完成了。

設定完成之後，再次嘗試原本的連線指令，應該就能順利連上伺服器。如果還是失敗，可以嘗試在指令中明確加上減 i 參數，例如

ssh -i C:\Users\your_username.ssh\my_key.pem user@1.2.3.4 

這樣就能成功登入了。

如果你現在用的是 Vue 3 搭配 Element Plus，而你在拿掉的瞬間，你的網頁基本上就半身不遂了。

• 短期（建議）： 維持 Element Plus，接受 unsafe-inline Medium 風險，專注業務功能。
• 中期： 若資安掃描壓力大，評估 Naive UI 替換（相同 Vue 生態、學習成本低）。
• 長期： 新專案直接選 React + shadcn/ui 或 React + Mantine，避免此問題。

兩大資安大哉問： 到底能不能直接拔掉？

我們先把問題拆成兩個層面來看。

1. 在 FastAPI 設定 CSP 跟在 Nginx 設定，有差嗎？

答案是： 完全沒有差別。

瀏覽器是很單純的，它只看最後收到的 HTTP response header。 不管這個資安政策是後端框架 FastAPI 吐出來的，還是前端大門 Nginx 塞給它的，對瀏覽器來說都長得一樣。

目前專案只有在 FastAPI 設定，那就繼續留在那邊就好，不需要特地搬家。

2. 移除 unsafe-inline 之後，Element Plus 還能動嗎？

答案是： 絕對會壞掉，而且壞得很難看。

如果你的 CSP 政策直接移除了 unsafe-inline，下面這些畫面上最亮眼的主角會集體罷工：

• el-select / el-dropdown： 下拉選單直接迷路，位置飛到九霄雲外或是乾脆隱形。
• el-tooltip / el-popover： 滑鼠移過去原本該跳出的提示，現在比你的前任還要冷淡，完全沒反應。
• el-dialog： 彈出視窗直接彈歪，跟你的預期完全對不上。
• el-table 固定列： 說好要固定的欄位，現在放飛自我跟著一起滾動。

為什麼會這樣？ 因為這些元件在運作時，JavaScript 會在幕後瘋狂計算畫面的座標，然後直接把 style="top: 200px; left: 150px;" 這種類型的行內樣式塞進 HTML 標籤裡。

當你把 unsafe-inline 拿掉，瀏覽器就會化身鐵面判官，只要看到這種行內樣式，一律當成非法入侵直接封鎖。 結果就是你的 CSP 報告看起來滿分，但使用者的畫面看起來像一場災難。

那難道無解了嗎？ 現代資安的標準解法

好消息是，我們不需要為了資安把整個 Element Plus 換掉（ 畢竟換框架是會出人命的 ）。 在 CSP Level 3 的現代標準中，資安政策已經被細分得更聰明了。

以前的 style-src 是一刀切，但現在我們可以把「 標籤 」和「 屬性 」分開管理。

你可以試試看這套完美的資安配置：

HTTP

Content-Security-Policy: style-src-elem 'self' https://cdnjs.cloudflare.com; style-src-attr 'unsafe-inline';

這段設定的意思其實就是跟瀏覽器講悄悄話：

• style-src-elem ‘self’： 只要有人想用 <style> 標籤或外掛惡意 CSS 檔案來劫持網頁，一律給我擋掉！ 這招直接封鎖了最危險的 CSS 注入攻擊。
• style-src-attr ‘unsafe-inline’： 至於 HTML 標籤裡面的 style="..." 屬性，我們就開個特權給它過吧。

改前 vs 改後 戰力分析

這樣改到底差在哪裡？ 我們直接看對比：

• <style> 注入攻擊： 改前是允許的（ 超危險 ），改後直接封鎖（ 安全 ）。
• 外掛惡意 CSS 檔案： 改前是允許的（ 超危險 ），改後直接封鎖（ 安全 ）。
• Element Plus 動態定位： 改前正常，改後依然正常運作。
• 資安掃描器的警告： 改前會跳出黃牌警告，改後警告直接消失。

結論

想兼顧資安跟漂亮的 UI，不需要直接把 unsafe-inline 趕盡殺絕。

透過 style-src-elem 和 style-src-attr 的分工合作，你既能把大門關緊防範黑客，又能留個小窗讓 Element Plus 的元件繼續正常跳舞。 這才是現代工程師優雅的解決之道。

結論上來說，改用

簡單來說，如果你的 CSP （ 網頁安全政策 ）開了 unsafe-inline ，就等於是在大門裝了密碼鎖，卻把密碼用便利貼貼在門口一樣。駭客只要找到機會塞一段惡意腳本（ XSS 攻擊 ），你的網站就直接變成他的遊樂場。

但是偏偏像是 Google Tag Manager （ GTM ）這種必裝的分析工具，官方給的程式碼裡面就是有一大段 Inline Script ：

HTML

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXXXX');
</script>

既想要防禦 XSS 攻擊，又不能把 GTM 拔掉，這時候你有兩條路可以走，讓我們來看看這兩個相愛相殺的解決方案。

方案一：使用 Nonce （ 一次性密碼鎖 ）

這個方法就像是去看演唱會，每次進場工作人員都會在你的手上蓋一個當天限定、過期失效的印章。

在 CSP 標頭（ Header ）裡，你可以這樣設定：

HTTP

Content-Security-Policy: script-src 'nonce-每天換的神秘亂數密碼'; img-src www.googletagmanager.com

然後在你的網頁程式碼中，那段 GTM 的標籤也必須帶上相同的密碼：

HTML

<script nonce='每天換的神秘亂數密碼'>
  // GTM 的扣（Code）放這裡
</script>

工程師真心話

• 優點：超級安全。因為駭客根本猜不到你下一個 Request 的亂數密碼是什麼，就算他成功塞了惡意指令，也會因為沒有通關密碼而被瀏覽器直接擋在門外。
• 缺點（ 也就是坑 ）：這非常考驗後端的大腦。你的伺服器必須在「 每次 」收到請求時，都用高強度的加密演算法生出一組全新的隨機字串。最慘的是，你的網頁從此跟「 回應快取 」（ Response Cache ）說再見，因為一旦網頁被快取，密碼就不會變了，那這個鎖就形同虛設。

方案二：使用 Hash （ 驗收指紋認證 ）

如果你的網站是 SPA （ 單頁應用程式 ），或是部署在 GitHub Pages 這種根本沒有後端可以幫忙生密碼的靜態伺服器，那 Hash 就是你的救星。

這個概念是，瀏覽器會直接去核對這段程式碼的「 指紋 」。

步驟非常簡單，把 <script> 到 </script> 之間的程式碼內容，丟到 SHA256 線上計算工具 裡面去跑一下，會得到一串像是 0bbd063b7... 的雜湊值（ Hash ）。

接著把這串指紋放進你的 CSP 設定裡：

HTTP

Content-Security-Policy: script-src 'sha256-計算出來的那串指紋'; img-src www.googletagmanager.com

工程師真心話

• 優點：前端自己就能搞定，不需要後端伺服器配合，而且網頁依然可以開開心心地做快取，提升載入速度。
• 缺點（ 最雷的地方 ）：
  1. 字元敏感度破表：SHA256 是一個極度龜毛的演算法。只要你的程式碼裡面多了一個空格、少了一個換行，甚至不同工程師的電腦存檔時，斷行符號一個是 LF （ \n ）一個是 CRLF （ \r\n ），算出來的指紋就完全不一樣。指紋一對不上，你的 GTM 就會直接被 CSP 射下來。
  2. 維護地獄：哪天行銷團隊突然要求修改 GTM 裡面的參數，只要動到一個字，你就必須重新計算一次 Hash 值、重新更新 CSP 標頭。如果交接沒做好，後續接手的工程師改了程式碼發現網站功能壞掉，可能要在電腦前哭著找兇手找很久。

總結防禦指南

想要高枕無憂、後端架構也撐得住，請選 Nonce 。

如果是靜態網站、追求速度與快取，請選 Hash ，但每次改動程式碼時，請記得去燒香拜拜順便更新指紋。

總之，快把 unsafe-inline 從你的 CSP 裡面拿掉，別再讓你的網站裸奔了。

簡單來說：Vue 3 是核心大腦，Element Plus 是外在的精美皮囊（UI 元件），而 Vite 則是負責把這一切快速組裝、運送到瀏覽器上的「超級工廠（構建工具）」。

以下為你詳細拆解它們之間的深層關係，以及為什麼現在開發 Vue 3 專案時，大家總是把它們綁在一起：

1. 角色定位：元件庫 vs. 構建工具

• Element Plus (UI 框架)： 它是寫好的 Vue 3 組件庫（按鈕、表格、下拉選單等）。它關心的是「畫面好不好看」、「功能好不好用」。
• Vite (前端構建工具)： 它是新一代的前端開發伺服器與打包工具。它不關心你的按鈕是藍色還是綠色，它關心的是「程式碼載入速度夠不夠快」、「打包出來的檔案體積夠不夠小」。

2. 為什麼兩者結合會「快上加快」？

Vite 的核心特點是利用了瀏覽器原生的 ES Modules (ESM)，在開發環境下不需要像舊時代的 Webpack 一樣把幾萬行程式碼全部打包完才開機。而 Element Plus 也是完全基於 ESM 架構重構的。

這帶來了兩個巨大的優勢：

瞬間啟動 (Lightning Fast Dev Server)

當你在 Vite 專案中引入 Element Plus 時，Vite 會利用 Esbuild 對 Element Plus 進行「預構建 (Dependency Pre-bundling)」。這意味著即使 Element Plus 包含幾百個組件，Vite 也能在 1 秒內啟動開發伺服器，完全不會因為組件庫太龐大而卡頓。

完美的自動按需引入 (Tree Shaking)

這是兩者合作最漂亮的亮點。在過去，如果你只用一個 Element Plus 的按鈕 <el-button>，你可能得把幾萬行的整包組件庫都下載到瀏覽器。

但在 Vite 生態圈中，透過官方推薦的 Vite 插件（unplugin-vue-components 和 unplugin-auto-import），Vite 可以在編譯時自動偵測你在程式碼裡寫了什麼。

JavaScript

// vite.config.ts 範例配置
import { defineConfig } from 'vite'
import AutoImport from 'unplugin-auto-import/vite'
import Components from 'unplugin-vue-components/vite'
import { ElementPlusResolver } from 'unplugin-vue-components/resolvers'

export default defineConfig({
  plugins: [
    // Vite 會自動幫你在背後偷偷引入 Element Plus 的組件與樣式
    AutoImport({ resolvers: [ElementPlusResolver()] }),
    Components({ resolvers: [ElementPlusResolver()] }),
  ],
})

有了這個關係，你在寫 Vue 檔案時完全不需要手動 import 元件，直接寫 <el-table>，Vite 就會自動幫你打包對應的 JS 和 CSS，做到極致的效能優化（Tree-shaking）。

3. 樣式與主題定制的橋樑

Element Plus 內建使用了大量的 CSS 變數 (CSS Variables)。而 Vite 對於 CSS、SCSS 的處理速度極快，且原生支援 CSS 變數。

• 開發時： 當你在 Vite 專案中微調 Element Plus 的主題顏色（例如把品牌色從藍色改成綠色），Vite 的 HMR（熱模組替換）能在幾毫秒內讓瀏覽器畫面直接變色，開發體驗非常絲滑。
• 打包時： Vite 底層使用 Rollup，它會把 Element Plus 被你用到元件的 CSS 提取出來，與你自己的 CSS 合併並壓縮，這也是為什麼你在生產環境（Production build）時，預設能拿到乾淨、沒有 unsafe-inline 的獨立 CSS 檔案。

總結

Element Plus 與 Vite 的關係，就像是「優質賽車（Element Plus）」與「頂級賽道/後勤團隊（Vite）」。

Element Plus 專心提供基於 Vue 3 的強大組件，而 Vite 則利用現代瀏覽器的特性，確保這些組件在開發時能秒速渲染、在部署時能被極致壓縮。這也是目前 Vue 3 生態系中最標準、最推薦的官方級主流配置。

為什麼連寫個看起來無害的 CSS 都會被瀏覽器當成恐怖份子。

瀏覽器的大內總管：CSP 到底在嚴格什麼？

各位前端與後端苦力們，有沒有遇過這種慘劇？

當你興高采烈地在網站加上這行內容安全政策（CSP）：

Content-Security-Policy: default-src 'self';

本以為從此高枕無憂，結果下一秒打開網頁，發現自己寫的行內腳本（inline-script）全部陣亡：

<script>console.log('連我都不能跑是怎樣');</script>

好啦，大家都知道 JavaScript 權限大、壞人最愛用，所以瀏覽器預設不讓它亂跑很合理。為了安撫大內總管，我們還得乖乖去算雜湊值（Hash）或是塞個 nonce 安全憑證，像是這樣：

Content-Security-Policy: default-src 'self'; script-src 'sha256-xxx...';

但是，最讓人傻眼的是，連單純想幫網頁化妝的行內樣式（inline-style）也被一起關進大牢了：

<style>h1 { color: yellow; }</style>

CSS 到底做錯了什麼？它只是個孩子啊！

警匪片現場：當 CSS 變成滲透工具

資安世界有三大神聖支柱：機密性、完整性、可用性。而隨便亂加的 CSS，其實正在默默破壞這一切。

疑犯一號：DOM 元素私生子（破壞完整性）

你可能會想：「這網頁是我寫的，裡面的 CSS 當然也是我寫的啊！」

事情可沒那麼簡單。在 JavaScript 的世界裡，壞人可以用各種神奇手法動態產生元素：

JavaScript

let style = document.createElement('style');
style.innerText = 'h1 { color: blue; }';
document.body.appendChild(style);

這段程式碼一旦被惡意注入，它就能神不知鬼不覺地改掉你的網頁外觀。這就是為什麼瀏覽器乾脆一不做二不休，預設把所有沒登記過的行內樣式全部封鎖。

疑犯二號：假藉美化名義的間諜（破壞機密性）

CSS 裡面有兩個看起來很無辜、但實際上超常被當作間諜的語法： @import 和 url() 。

當你用了背景圖片：

background-image: url(https://example.com/spy.jpg);

瀏覽器看到這行，就會自動發出一個請求去下載圖片。這時候，壞人就可以利用這個機制搞鬼：

• 偷看你的行蹤（Beacon 技術）： 只要把圖片網址加上個人專屬的編碼，當你一打開網頁，壞人的伺服器收到圖片請求，就知道「喔！某某某在幾點幾分看了這個頁面！」
• Cookie 順風車： 如果網站沒設定好，這個請求甚至會順便把你的 Cookie 跨站送出去，直接把你的登入狀態雙手奉上。

所以，想要在有 CSP 的防護下安全地秀出圖片，你還必須跟總管報備圖片的白色名單：

Content-Security-Policy: default-src 'self'; style-src 'sha256-...'; img-src http://信任的圖片來源;

結論

在這個壞人招數層出不窮的時代，網頁開發者真的不能只活在「CSS 只是用來排版」的粉紅泡泡裡。多了解一點 CSP 的龜毛規則，雖然設定時會寫到抓狂，但至少能保住大家的飯碗，不讓網站變成駭客的免費遊樂園！

當我們在開發前端專案時，常常會遇到明明在本地開發測試都好好的，但一打包部署到測試環境（ staging ），某些功能就莫名其妙失蹤的靈異事件！

這次苦主遇到的狀況是：使用 pnpm build:staging 指令打包後，左側導覽列的「管理員選單（ isAdmin ）」居然直接蒸發了！

經過一番鍵盤柯南式的徹查，終於抓到幕後黑手，原來是我們自以為很懂的 Vite 在搞鬼。

案發現場：為什麼選單不見了？

在原本的程式碼中，開發者用了 import.meta.env.PROD 來做判斷。心裡想著：「開發環境（ dev ）是 false ，測試環境（ staging ）應該也是 false ，只有真正的正式環境（ production ）才會是 true 吧？」

結果 Vite 表示：「你想得美！」

我們來看看 Vite 在不同指令下的真實真面目：

執行的指令	MODE 變數	PROD 變數（ 關鍵在這裡 ）	導致的後果
vite (dev)	development	false	順利繞過檢查，選單正常顯示。
vite build –mode staging	staging	true	誤判為正式環境，跑去呼叫真實 API 檢查，結果因為 IP 不對直接被拒絕，選單慘遭隱形。
vite build	production	true	正常的正式環境流程。

破案關鍵：在 Vite 的世界裡，只要你執行了 vite build 這個打包指令，不管後面帶的 –mode 是什麼，它都會偷偷把 NODE_ENV 設定為 production 。因此， import.meta.env.PROD 在測試環境下也會被無情地判定為 true ！

拯救選單：動手修正它

既然知道了 Vite 的脾氣，修正的方法就很簡單了。我們不要再相信傲嬌的 PROD 變數，直接去檢查 MODE 的名字是不是叫做 production 就好了！

程式碼改動

請把原本的防禦邏輯修改如下：

JavaScript

// ❌ 原本的寫法（ 會誤判測試環境 ）
if (!import.meta.env.PROD) { ... }

//  修正後的寫法（ 精準識別是不是真的正式環境 ）
if (import.meta.env.MODE !== 'production') { ... }

同時，別忘了同步更新專案的 README.md 說明文件，讓未來的自己或其他同事不會再踩進同一個坑裡。

修正後的快樂結局

改用 import.meta.env.MODE 來把關之後，判斷邏輯就變得非常聽話了：

• pnpm run dev 模式為 development 順利放行，直接顯示選單！
• pnpm run build:staging 模式為 staging 順利放行，直接顯示選單！
• pnpm run build 模式為 production 嚴格把關，呼叫 API 檢查！

現在重新執行 pnpm build:staging 打包，那個令人朝思暮想的管理員選單終於乖乖下凡，回歸到它該出現的地方囉！