後端的守門員：權限驗證、防火牆與資安基礎

更新日期： 2025 年 4 月 3 日

在《進擊的巨人》裡，人類建起了三道巨大的城牆——瑪利亞、羅塞、希娜，來抵禦外面未知且危險的巨人入侵。

每一層城牆代表不同程度的防線，越往內越安全、越關鍵。

而作為後端開發者，我們開發的系統就像那座城市，而 API 就是城市的大門。

當你把系統部署上線、開放 API 給外部使用的那一刻，就等於對全世界說：「歡迎進來。」

可是你準備好了嗎？每一扇 API 的門，如果沒有設下正確的防線與守衛，那等於直接讓「巨人」從缺口湧入。

本篇文章將用「三層資安防線 = 三道城牆」的概念，帶你理解後端開發中不可忽視的資安關鍵任務，讓你從 API 開發者，進化為 API 的守護者。

API 的暴露風險你知道嗎？

在現代的後端架構中，API 是你系統的門口，是前端、手機 App，甚至其他外部服務與你溝通的主要途徑。

每支 API 就像是在城市牆上開的一扇門，方便資料交換、功能執行。

但問題也正是出在這裡——任何開放的門，都可能成為敵人入侵的缺口。

當你的系統上線、API 開放給外界使用時，你不只是在服務使用者，也同時在吸引駭客注意。這些 API 很可能被掃描、被測試，甚至被當作進攻目標。

如果沒有妥善保護，它們會像沒有門鎖的房間，只要知道門的位置，就能隨意進出。

常見的攻擊手法：

🔸 SQL Injection（SQL 注入）

攻擊者透過在表單、查詢欄位或 URL 中輸入惡意語法，例如：

' OR 1=1 --

來欺騙後端執行非預期的資料庫查詢，進而讀取、竄改甚至刪除整張資料表。

👉 沒有使用參數化查詢？就像把資料倉庫的大門敞開。

🔸 暴力破解（Brute Force）

像是試密碼的巨人，一直敲門直到打開為止。這類攻擊會自動產生大量帳號密碼組合，不停嘗試登入，直到猜對為止。

👉 沒有登入次數限制？攻擊者就能持續嘗試直到成功。

🔸 XSS / CSRF 攻擊

• XSS（跨站腳本）：透過注入惡意 JavaScript 代碼，讓其他使用者瀏覽時被竊取 Cookie 或執行非預期操作。
• CSRF（跨站請求偽造）：誘導使用者在不知情的情況下，對網站發出有權限的操作（如轉帳、修改密碼）。

👉 若沒防範，就像讓敵人潛入城市內部操控市民自相殘殺。

🔸 資訊洩漏（Information Disclosure）

很多初學者會在開發階段留下詳細的錯誤訊息、除錯訊息，例如：

"error": "SQL syntax error near 'users' at line 1"

這類訊息會直接暴露後端使用的資料表、語法結構甚至框架版本，給駭客留下線索。

👉 好比把地圖、軍事配置都公開給敵人。

🔸 Zero Day Attack（零日攻擊）

最難防的是你「根本還不知道它存在」的漏洞。

駭客比你更早發現這個漏洞，並在你還沒來得及修補前就進行攻擊。

這種攻擊可以發生在：

• 第三方函式庫（如圖片處理、上傳模組）
• 開源框架（如 Express、Django）
• 自己沒察覺的錯誤邏輯漏洞

👉 這就是潛伏在城牆陰影處、等待出現破口的「超大型巨人」。

為什麼初學者常常忽略這些風險？

因為這些攻擊看不到、也不容易在本地測試時出現。

只有當你上線、面對真實流量、打開城市大門時，你才會意識到敵人早已伺機而動。

所以我們不能等到巨人出現才修牆，而是要事前建立好資安防線，從一開始就設計好城牆結構。

接下來，就讓我們用《進擊的巨人》的三層牆概念，來打造一座穩固的 API 城市。

延伸閱讀：OWASP Top 10：最新的 Web 安全風險與防範措施（2021 版）

第一層城牆：防火牆（WAF）＝瑪利亞之牆

守住邊界，讓外部流量先過一關

在《進擊的巨人》裡，牆瑪利亞是圍繞整個人類世界的最外層防線，是城鎮與未知荒野之間的分界線。

當巨人從四面八方襲來時，這道牆就是第一道承受衝擊的屏障，守住的不只是土地，還是人心的安全感。

對後端工程師而言，這道牆的角色，就是——防火牆（Firewall）。

防火牆的角色是什麼？

防火牆是部署在伺服器前端的「網路哨站」，負責篩選進出系統的流量，就像守門的憲兵團，根據預先設定的規則，判斷哪些請求該放行、哪些直接阻擋於門外。

常見功能包括：

• 封鎖可疑 IP：防止來自匿名代理、惡意地區或黑名單 IP 的請求。
• 限制通訊埠（Port）：只開放必要的埠（例如 443 for HTTPS），其餘一律封鎖，避免側門被入侵。
• 過濾協定與來源：只允許使用 HTTPS 的流量，並限制請求來源（Referrer / User-Agent）等。
• 阻止異常請求模式：像是超高頻率的連線、重複請求特定 URL，可能是爬蟲或殭屍網路攻擊（DDoS）前兆。

簡單說，它不會關心你請求什麼資料，但會先判斷你「有沒有資格靠近城門」。

再升級一層防禦：Web Application Firewall（WAF）

如果防火牆像是站在城牆外、檢查旅客身分的巡邏士兵，那 WAF（Web Application Firewall） 就是架在城牆上的高科技自動砲塔。

它不只看你從哪裡來，還會檢查你身上帶了什麼武器，說了哪些可疑的話。

傳統防火牆主要針對網路流量來源（IP、Port）過濾，但 WAF 是針對「請求內容」本身進行分析，判斷你傳進系統的資料是否有危險。

想像一下一個登入表單，正常使用者會這樣輸入：

帳號：jack123
密碼：mypassword

但如果是駭客，可能會輸入：

帳號：' OR 1=1 --

這段看起來像亂碼的東西，其實是想要「欺騙後端資料庫執行錯誤的語法」，這就是所謂的 SQL Injection（SQL 注入）。

🧨 WAF 可以攔截哪些「應用層」的攻擊？

以下是幾種 WAF 擅長防禦的攻擊類型，並搭配具體情境解釋：

🧬 SQL Injection（資料庫注入）

• 舉例：駭客在登入表單輸入惡意語法，試圖繞過驗證或竊取資料庫內容。
• WAF 的做法：發現輸入內容中有像 SELECT *, OR 1=1, DROP TABLE 等可疑語法，就會自動阻擋這筆請求。

🗣️ XSS（跨站腳本）

• 舉例：攻擊者在留言區貼一段 <script>alert("我來了！")</script>，讓其他人一點開就被執行惡意腳本。
• WAF 的做法：發現輸入資料包含 <script> 標籤或其他可疑腳本，立刻封鎖，避免影響使用者。

🕵️ CSRF（跨站請求偽造）

• 舉例：駭客誘導使用者點擊某連結，讓他在不知情的情況下對某個網站發出修改密碼的請求。
• WAF 的做法：檢查請求是否缺少合法來源驗證，或是否被植入可疑表單，主動阻止。

📁 檔案上傳攻擊

• 舉例：使用者上傳看似圖片的 .jpg，其實是帶有執行程式的偽裝檔案。
• WAF 的做法：設定可接受的檔案類型與大小，並偵測副檔名與實際內容是否吻合，避免惡意上傳。

🤖 為什麼說 WAF 是「自動防禦炮塔」？

最大的優勢在於：

你不需要在程式裡逐一檢查這些細節，WAF 會自動幫你辨識、分析、阻擋。

就像你不用每次都檢查訪客包包裡有沒有炸彈，WAF 幫你裝了一個「自動偵測機器人」，發現有問題就直接鳴警報並阻擋，完全不打擾正常使用者。

對初學者來說，這不只是資安進階裝備，更是避免一不小心寫出可被攻擊的程式碼的最佳補強。

sequenceDiagram
    actor User as 使用者
    participant FW as 傳統防火牆
    participant WAF as Web應用防火牆
    participant Web as 網站應用

    Note over User,Web: 情境一：正常訪問網站
    User->>FW: 請求 (目標IP:211.123.45.67, 埠:443)
    FW->>WAF: 通過 (允許到443埠的HTTPS流量)
    WAF->>Web: 通過 (合法的網頁請求)
    Web->>User: 回應 (網頁內容)

    Note over User,Web: 情境二：IP封鎖攻擊
    User->>FW: 請求 (來自被封鎖的IP)
    FW--xUser: 拒絕 (IP來源不允許)
    
    Note over User,Web: 情境三：SQL注入攻擊
    User->>FW: 請求 (目標IP:211.123.45.67, 埠:443)
    FW->>WAF: 通過 (允許到443埠的HTTPS流量)
    WAF--xUser: 拒絕 (SQL注入特徵偵測)

小結：這層牆守住的是「數量型」的攻擊

有些開發者會以為：「我系統又不大，沒人會來攻擊我吧？」

但事實是，大部分駭客攻擊都是自動化進行的，不分目標、不挑平台。

只要你的伺服器有對外 IP、有開放 Port、有 API 在運作，機器人就會來試探——

就像牆瑪利亞不會因為邊境小村落就不遭巨人襲擊一樣。

• 想壓垮你系統的巨人？擋在牆外
• 想偵測你漏洞的掃描器？攔在關卡
• 想暴力密碼撞庫的殭屍機器？封住 IP

防火牆與 WAF 是你系統的第一道防線，讓絕大多數的攻擊者連靠近 API 的資格都沒有。

這道牆不會完美無缺，但它能讓你只需要對抗真正的威脅，而不是淹沒在垃圾流量中崩潰。

延伸閱讀：初學者必讀：防火牆是什麼？功能、類型與常見問題全解析

第二層城牆：身份與授權 ＝ 羅塞之牆

城門已開，誰能進？能進來的又能走到哪？

如果防火牆是《進擊的巨人》裡最外層的 牆瑪利亞，負責擋住大量的敵人和垃圾流量。

那麼 牆羅塞 就是第二道保護層，負責管理已經「通過城門、走進城市」的人們。

這時候，威脅不是成群的巨人，而是——藏在人群中的偽裝者與內鬼。

這層牆的任務，不只是「讓對的人進來」，還要進一步確保：

• 這個人是誰？（身分驗證）
• 他可以做什麼？（授權控制）
• 他做的事，有沒有超出身分能做的範圍？

否則你不小心讓一位偽裝成士兵的巨人進入了行政中心，後果可想而知。

身分驗證（Authentication）：你是誰？

這是後端每個系統都必須有的第一道邏輯門禁。就像每個市民進入內城前，都要先出示身份證明，確認他是人類而不是巨人。

在系統世界中，常見的身份驗證方式有：

• 帳號密碼登入：最基本的驗證方式，搭配加密儲存（如 bcrypt）保護密碼。
• OTP 驗證碼：常用於雙重驗證（2FA），提高帳號被盜的難度。
• 第三方登入（OAuth）：像是「用 Google 登入」、「用 Facebook 登入」，借助信任機構驗證身份。
• Token 驗證（如 JWT）：登入成功後，發出一組 Token（通行證），之後每個請求都要附上這張證件。

📌 沒有身份驗證，會發生什麼事？

• 任何人都能呼叫你的 API
• 別人可以假裝是別的用戶，竊取資料
• 系統根本不知道「這筆請求是誰下的」

就像城市完全沒有邊防哨站，一個陌生人就能大搖大擺走進市政廳。

授權控制（Authorization）：你能做什麼？

身分確認後，我們不能就放任使用者自由活動。還要根據他的身份，控制他能觸碰的範圍。

這就是「授權控制」的核心任務：分層分權，有限開放。

在《進擊的巨人》裡，平民無法進入中央政廳，軍團也有階級分明的指揮線，這種「職權分明」就是授權的真實寫照。

🧰 常見實作方式：

• 角色權限設計（Role-based Access Control, RBAC）
  每個使用者有一個角色（如 admin、user、guest），程式會根據角色來控制 API 開放範圍。
• Token 中包含權限資訊
  例如 JWT 中加入使用者角色、用戶 ID、有效時間等欄位，後端可解碼後比對。
• 每支 API 驗證權限
  某些 API 僅限管理員呼叫，普通用戶直接返回 403 Forbidden。這通常透過 middleware（中介層）來設計： if (user.role !== 'admin') { return res.status(403).json({ error: '你沒有權限操作這項資源' }); }
• 資料歸屬驗證（Owner Check）
  即使你是登入狀態，也不能修改別人的資料。例如： if (post.user_id !== req.user.id) { return res.status(403).json({ error: '你不能編輯別人的文章' }); }

這層城牆的意義是什麼？

如果沒有身份驗證與授權控制，駭客就能偽裝成合法用戶，一步步深入系統核心。

而你辛苦寫好的功能，將變成他們破壞資料、偷取帳號的工具。

這就是「偽裝成士兵的巨人混入人群」的真實情境。

這層牆不能只建在城市裡，還要貫穿整個 API 系統的邏輯設計中。

這層牆守住的是「信任與邏輯」的風險

• 確認每個請求背後是誰
• 限制他只能做「被允許的操作」
• 防止身分偽冒、越權操作
• 維護資料隱私與歸屬正確性

身分驗證是讓人「進來」的門票，授權控制是規範他「能走到哪裡」的地圖。

沒有這層防線，巨人就會穿上斗篷，混進你的城市，直搗黃龍。

延伸閱讀：API 安全全攻略：從漏洞風險到最佳實踐

第三層城牆：API 自身安全機制 ＝ 牆希娜

最核心區域，守住每一座資料倉庫

在《進擊的巨人》中，牆希娜是最接近王族與中央政權的城牆，保護的是整個文明的神經中樞。

對後端開發者來說，牆希娜代表的不是流量來源，也不是使用者身分，而是——你自己寫的程式碼。

即使外部攻擊被防火牆擋住，身份被嚴格驗證，只要你的 API 實作邏輯有錯、用錯函式庫、忘記過濾資料，那麼巨人依然會從你打開的門正大光明地走進來。

這層防線不是防「別人」，而是防「你自己沒注意到的錯」。

🔍 API 的三大內部防線：寫好功能，也要防好風險

防止開發錯誤引發漏洞

「不是你被駭，是你自己沒擋住」

有些安全問題並不是因為駭客太強，而是你忘了檢查、沒做驗證，留下了明顯的破口。

🧨 常見錯誤包括：

• 沒驗證使用者輸入 → 被注入惡意資料
• SQL 字串手動拼接 → 發生 SQL Injection
• 檔案上傳不檢查副檔名 → 被上傳執行檔或 Web shell
• 錯誤訊息詳細回傳 → 洩露系統內部結構與邏輯資訊

這些都不是防火牆能解決的問題，而是開發者寫程式時就該做好的事。

✅ 該怎麼改善？

• 使用 ORM / prepared statement 防止注入攻擊
• 強制欄位格式驗證（例如 email 格式、ID 為數字）
• 上傳前檢查 MIME type、限制副檔名
• 錯誤處理不應回傳 Stack trace，只回傳 user-friendly message

控制第三方依賴的風險

「你沒寫錯，但用了會出錯的東西」

即使你寫得很小心，但你所引用的第三方函式庫、套件、CDN，也可能成為破口。

🧨 常見情況包括：

• 套件中藏有漏洞（例如早期上傳套件允許執行任意程式碼）
• 使用開源套件未檢查更新紀錄，包含高風險漏洞
• 透過未驗證的 CDN 載入外部 JS，被植入後門
• 更新版本後防禦邏輯消失，或預設值變更

✅ 該怎麼做？

• 定期更新套件、追蹤官方的安全通報（像是 npm audit、pip check）
• 使用工具自動掃描依賴漏洞（如 Snyk、OWASP Dependency-Check）
• 使用 Subresource Integrity（SRI）驗證 CDN 引入的資源
• 針對高敏感功能，考慮避免使用黑盒函式庫

防止資料洩漏與敏感欄位暴露

「你沒有被偷資料，是你自己送出去了」

API 最大的風險之一不是被入侵，而是自己回傳了不該給的資料，卻渾然不知。

🧨 常見的例子有：

• API 回傳使用者資訊時，包含了 password_hash、isAdmin、auth_token
• 調用某筆資料時未做歸屬驗證，用戶能看到別人的資料
• 上傳資料夾路徑中包含使用者 ID，可猜出其他人路徑
• .env、debug 模式、測試帳號等開發遺留未清除

✅ 該怎麼避免？

• 設定資料回傳白名單（只能顯示指定欄位）
• 資料庫查詢時附帶歸屬條件（如 WHERE user_id = current_user.id）
• 禁用 debug=true，不回傳系統設定資訊
• 上線前進行「敏感資料掃描」與「模擬攻擊檢查」

不是擋人進來，而是防你自己開門

防火牆擋不住你拼接的 SQL 字串；WAF 攔不了你多送出的欄位。

這層防線的核心觀念是：

• 把功能寫對，也要把資料回傳範圍設對
• 不只想「怎麼讓 API 被用」，也要想「怎麼防止被濫用」
• 不怕被駭，而是怕自己寫錯還沒發現

你寫的每一行程式碼，不只是邏輯，而是一道是否能守住的門。

牆希娜守住的，不是外部攻擊，而是開發者可能留下的內部炸彈。

結語

寫 API 的你，其實就是那位在牆上巡邏的士兵。當你按下部署的那一刻，這座城市就對外開放了。

但是否安全、是否能防禦巨人，取決於你有沒有建好這三層城牆：

1. 瑪利亞之牆（防火牆 & WAF）→ 擋住大多數來路不明的威脅
2. 羅塞之牆（身分驗證與授權）→ 控管誰能進來、能做什麼
3. 希娜之牆（API 自身防禦力）→ 即使進來也無法破壞核心資源

後端開發，不只是「把資料傳出去」而已，而是「確保資料只能傳給對的人，用正確的方式，在安全的前提下被使用」。

巨人終將來襲，但你的 API 城牆能不能撐住，從現在開始，就要準備。