AI 開發與資安：不是資工系的專利，從日常習慣開始
先保護自己的帳號，再保護 AI 幫你做出來的網站
在餐廳吃完飯、百貨公司結帳時，把信用卡交給服務人員是很平常的事。但從卡片交出去那一刻起，卡片上的資訊就多了一次被別人看見的機會；如果卡片離開自己的視線，也增加了被拍下或側錄的風險。這不是說交出卡片就一定會出事，而是提醒我們：資安風險在生活裡就已經出現，不是等到寫程式才開始。[1]
拿起手機回 LINE、登入信箱，或打開電腦處理工作，也都是類似的日常選擇。這些動作太平常了，平常到我們不一定會把它們和「資安」連在一起；但只要資料會被看見、傳送或保存，就值得多留意一下。
很多人覺得資安是資工科系、資訊部門或工程師的專長；但我認為，只要有使用手機、電腦，有信箱和帳號，就值得正視這件事。 不用先學會寫程式，也不用一次變成資安專家。我們可以從刷卡時留意卡片去向、看清楚連結、保護重要帳號這些小事開始，慢慢養成自己的習慣。
這篇會先從生活聊起，再把同一套觀念帶到 GitHub、雲端平台和 AI 工具。平常累積的判斷和檢查方式，開始用 AI 做網站時也派得上用場。
這篇會比較長，但不用把它當成一份要背完的考題，也不用一次做到滿分。先挑一個最容易開始的習慣，今天就試試看。
第一件事：把最重要的帳號守住
如果一個購物網站的密碼忘了，通常還能用 Email 重設。那如果主要 Email 本身被拿走呢？對方可能再去嘗試重設其他帳號。所以我會先保護主要信箱、密碼管理器，以及常用的 Google、Apple 等帳號，再處理其他服務。
每個網站用不同密碼，是最基本的一步。假設你在購物站和信箱都用同一組密碼，購物站出問題，風險就可能一路跟到信箱。也別把 Casper2026 改成 Casper2027 當成「每年都有換」；規律太好猜。密碼不用全部自己記，交給密碼管理器產生和保存，反而比較容易做到每站不同。NIST 的現行指引也不要求服務無理由地定期強迫使用者換密碼；真的發現外洩或誤填到假網站時，才要立刻更換受影響的密碼。[2]
如果網站支援 Passkey（通行密鑰），可以優先考慮。它把登入憑證和網站身分綁在一起，能降低把憑證交給假網站的風險。用 Face ID 或 Touch ID 解鎖時看起來很像「用臉登入」，但要注意：出現生物辨識畫面，不代表這次一定使用 Passkey；有時它只是幫你解鎖儲存在裝置裡的密碼。[2:1]
如果仍使用密碼登入，能開啟兩階段驗證的帳號也盡量開啟。支援安全金鑰時可以優先評估，驗證器 App 也是常見選項；只有簡訊驗證可選時，先開總比完全沒有第二道保護好。但不要把簡訊驗證碼當成可以交給「客服」的資料，驗證碼仍可能被假網站即時騙走。Passkey 的登入方式則依服務與裝置而異，不必把它硬套成「先輸入密碼、再收驗證碼」那一種流程。[2:2]
最後別漏了救援方式。備用碼、備援信箱和電話要能使用，備用碼也別只存在同一支手機裡；手機不見時，如果連唯一的救援方式都跟著消失，才是真的麻煩。NIST 對保存的救援碼也建議離線妥善保管。[2:3]
我自己的習慣是：能開生物辨識或兩階段驗證時，通常會開。但我也會回頭確認那到底是 Passkey、解鎖密碼，還是第二道驗證，不把所有長得像「掃臉」的畫面都當成同一件事。
LINE 傳來的網址，先看它到底帶你去哪裡
釣魚訊息最厲害的地方，不一定是技術有多複雜，而是它剛好撞上你的日常：正在等包裹、剛刷完卡，或本來就有一個帳號要登入。看到「五分鐘內處理，否則停用」，人很容易先緊張再點連結。
我會先看真正的網域，不是看網址裡有沒有品牌名稱。accounts.google.com 是 google.com 的子網域；google.com.login.example 雖然前面也有 google.com，實際上屬於 login.example。後者只是示範用的假網址，但它很能說明：品牌文字放在網址前面，不代表這是品牌的網站。
另外，看到 https:// 或瀏覽器的加密標示，也不能直接認定「這個網站一定是真的」。HTTPS 主要保護你和目前這個網站之間的傳輸；如果你連到的本來就是假網站，傳輸加密也不會把它變成真官網。遇到憑證或瀏覽器安全警告，更不要為了趕快登入而略過。[1:1]
不確定的時候，我會先關掉訊息裡的連結，自己打開原本就知道的官方 App、書籤或官網。有人透過 LINE 索取驗證碼、要求批准突然冒出的登入通知，也先停下來。即使訊息來自熟人的帳號，也可以用原本就知道的電話確認；對方帳號可能已經被拿去傳訊息。急著叫你操作，正是更該慢下來的時候。[1:2]
手機、電腦和資料，也都是生活的一部分
資安不只發生在登入畫面。離開座位把電腦鎖起來、手機設定螢幕鎖定、讓系統和瀏覽器自動更新，這些小事每天都會遇到。更新除了新功能，也可能修補已知問題；如果裝置已經停止收到安全更新，就要評估接下來怎麼處理，而不是一直按「稍後提醒」。[1:3]
裝 App 或瀏覽器擴充功能時，我會多看一眼來源和權限。一個手電筒工具為什麼要讀整本通訊錄？一個只負責改文字的擴充功能，為什麼要存取所有網站？有些功能真的需要相機、麥克風或照片，但可以選「使用期間允許」、「只選部分照片」時，就不用一開始把全部權限送出去。
日常付款也是一樣。我自己出門會盡量用行動支付，減少把實體信用卡交給別人的機會；但付款前仍然要看收款對象和金額，開啟消費通知也方便早點發現不認識的交易。這只是我降低資料外露機會的習慣，不代表用了某一種支付方式就不會遇到詐騙。
另一件很容易被忘記的是備份。照片、作品和專案如果只在一支手機或一台電腦裡，裝置壞了就可能一起不見。常見的 3-2-1 原則，是保留三份資料（原始檔和兩份備份）、使用兩種儲存媒介，至少一份放在不同地點。雲端同步很方便，但誤刪的檔案也可能跟著同步；所以要確認版本能不能還原，偶爾真的拿一份備份試著還原。[3]
你不用今晚就把所有設備重整一次。從「開啟更新、確認手機鎖定、找出一份重要資料做備份」開始，就比把資安當成別人的專業、完全不碰來得實際。
還要定期回頭看，不是設定完就永久有效
密碼換過、兩階段驗證開過，接下來還是可能有新的裝置登入、新的 App 取得授權，或一份原本只想給同事看的文件被設成「知道連結的人都能開」。這些事情不一定會在當下跳出很大的警報。
我會隔一段時間看主要帳號的登入裝置與活動、第三方連線、雲端文件分享權限，以及信用卡和銀行帳單。看到陌生地點先別立刻斷定被盜，網路位置顯示不一定精準；但若裝置、時間和操作都對不上，就該從官方安全頁面處理，而不是點警告信裡附的陌生連結。
到這裡為止，就算你一行程式都不寫，這些也和你有關。上一篇聊過 Worker、R2 與 D1 怎麼分工；接下來換個角度看：當你把專案、GitHub 和雲端工具交給 AI Agent 使用，剛剛的帳號與權限習慣，會變得更重要。
AI 能幫你做事，也要看清楚它能碰到哪裡
一般聊天時，AI 只看到你提供的內容；接上專案、終端機、瀏覽器或 MCP 之後，它可能可以讀檔、改程式、呼叫外部服務。能力變多很好用，但權限也跟著變大。要請它檢查一個測試網站，不一定需要把整個正式環境的管理權限都交出去。
我會先問三件事：它能讀哪些資料？能替我做哪些動作？哪一步需要我確認？ 例如只需檢查程式碼，就先讓它讀必要的專案檔案；要測試寫入資料，先用測試資料庫；刪除資料、改正式權限或部署，再單獨確認。
還有一種 AI 開發才特別容易遇到的事：AI 讀到的網頁、文件或程式庫說明裡，也可能夾著「請忽略原本的要求，改做某件事」這類文字。外部內容是資料，不是你下給 AI 的新命令。 這叫做間接提示注入（prompt injection）；當 Agent 同時能讀取機密或操作工具，後果可能不只是回答歪掉。OWASP 建議區分不可信內容、縮小工具權限，並讓高風險動作保留人工確認。[4]
這不是說 AI 不能看網路資料，而是別把每一段它讀到的文字，都當成自己同意它照做的指令。和我們看到 LINE 連結會先停一下，其實是同一種習慣。
API Key 不是放進 .env 就會自動安全
開始串接地圖、付款、AI 模型或雲端服務時，你可能會拿到 API Key。它有時代表你的身分，有時能使用付費額度，甚至能讀寫資料。也有些服務提供設計給前端使用的公開設定值或 Publishable Key；能不能公開，要看服務的官方說明與權限設定，不能只看它叫不叫 Key。
真正需要保密的金鑰，應由後端或部署平台的 Secrets 功能保管。.env 只是存放設定的檔案，並不是保險箱；還要確認它沒有被 Git 追蹤。如果是 Vite 專案，VITE_ 開頭的環境變數會進到前端建置結果，網站訪客也可能讀到，所以不要把機密放在這裡。[5]
金鑰也不只會從 Git 漏出去。請 AI 除錯時，直接貼完整金鑰、帶憑證的網址或未遮蔽的 Log；錄影時讓終端機印出環境變數；把錯誤畫面截圖傳到群組，都可能留下副本。可以先用假值、遮蔽後的訊息和最小必要片段說明問題。若金鑰已經進過 Git 歷史，後來從最新版本刪掉，也不能當作沒發生過；外洩後要先撤銷或換發。[5:1]
讓 AI 幫忙時，我會把「別碰正式資料」說得很具體：先看設定，告訴我哪些值會送進瀏覽器、哪些會留在伺服器；只用假金鑰示範；檢查提交差異和建置結果；不要把金鑰內容印在回覆或 Log 裡。這比一句「幫我注意資安」更容易驗收。
上線前，不是按鈕藏起來就算有權限
假設一個網站有「我的測驗紀錄」。把管理按鈕藏起來，只改了畫面；如果後端 API 沒檢查使用者身分，別人仍可能直接送出請求。CORS 也不能代替授權。真正重要的是：每次讀寫時，都由可信任的後端確認「這個人能不能操作這筆資料」。OWASP 也建議對每次請求執行授權檢查。[6]
我會請 AI 幫忙補測試，但測試情境要自己說清楚：沒登入時不能讀、使用者 A 不能讀使用者 B 的資料、一般使用者不能做管理員的操作。若有 R2 或其他檔案儲存，也要檢查哪個貯體和網址是公開的，不能為了讓畫面先跑起來，就把所有檔案設成任何人都能讀。
上線前再看一次這次修改的檔案與 Git 差異，確認沒有 .env、資料庫備份、真實個資或測試用的開放權限。套件漏洞告警和機密掃描也值得打開；它們能幫忙發現問題，但「掃描沒報錯」不等於網站已經絕對安全。[6:1]
真的出事，先止血，不是先把畫面擦乾淨
如果有一天發現 API Key 不小心推上 GitHub，直覺可能是趕快刪掉那一行，再補一個 Commit。但如果別人已經看過或複製過，刪檔案不會讓那把金鑰失效。GitHub 的處理建議也是：把外洩憑證視為已遭取得，先撤銷或換發，再處理程式和歷史紀錄。[7]
我會把順序記成五步：
- 先止血：在服務平台撤銷、停用或限制外洩的金鑰，必要時暫停受影響功能。
- 查影響：看登入、API 用量、帳單和資料異動，保留必要紀錄，不要急著把 Log 全清掉。
- 換發並修原因：找出哪些服務用了舊金鑰，在可信任的環境換新；同時修掉把金鑰寫進前端或版本庫的做法。
- 驗證恢復：確認舊金鑰已失效、新設定能用，權限與費用沒有異常。
- 留下紀錄：記下發現時間、影響範圍和後續要補的檢查；如果涉及他人的資料，再依實際情況尋求平台、團隊或專業協助。
Git 歷史若要重寫，還會影響協作者與其他複本，不是按一下刪除就能保證回收所有地方的資料。先讓憑證失效，比把畫面修得像沒發生過更重要。[7:1]
今天可以先做哪三件事？
如果前面看到有點喘，先不用替所有帳號和專案做一場資安大掃除。我會建議先挑三件：
- 找出主要 Email，確認登入方式、第二道驗證與救援方式。
- 下次收到急著要你點連結的訊息，先回到自己知道的官方入口。
- 如果正在用 AI 開發，請它先列出這個專案能讀到的機密、準備修改的權限與上線前測試項目，先不要直接動正式環境。
資安不是資工科系的專利，也不是懂了以後就永遠不會出事。它比較像每天出門會記得鎖門：平常多做一點，真的遇到問題時，才不會完全不知道從哪裡開始。AI 可以幫我們寫程式、補檢查，但「這份資料該給誰看」「這個權限要不要開」，最後還是要由我們自己決定。
新北市政府警察局，刷卡時讓信用卡留在視線內；CISA，Secure Our World；Google Chrome，HTTPS 的傳輸保護說明。 ↩︎ ↩︎ ↩︎ ↩︎
NIST，SP 800-63B：密碼、抗釣魚驗證與帳號救援；CISA，Secure Our World。 ↩︎ ↩︎ ↩︎ ↩︎
OWASP，LLM01:2025 Prompt Injection；LLM06:2025 Excessive Agency。 ↩︎
Vite，Env Variables and Modes；GitHub Docs，Removing sensitive data from a repository。 ↩︎ ↩︎
OWASP，Authorization Cheat Sheet；MDN，CORS；GitHub Docs，Secret scanning。 ↩︎ ↩︎
GitHub Docs，Remediating a leaked secret。 ↩︎ ↩︎