讀完這一章，你會知道如何用 Lovable 的 Security view、Basic scan、Deep scan、Security center、Sensitive data scanning、Secrets overview、Audit logs 和 workspace（工作區）privacy settings，替你的 app 建立發布前與發布後的安全治理流程。你會分清楚 app-level security、data-level security 和 workspace（工作區）-level governance，並知道哪些事情可以交給 Lovable 掃描，哪些事情必須由團隊負責審查。
這章的核心態度很簡單：
AI 可以幫你找風險，但不能替你承擔風險。
LaunchNote 到現在已經有資料庫、登入、RLS（Row Level Security，列層級安全）、Paddle 金流、Email、AI、GitHub sync、測試和 debug 流程。這已經是會碰到真實使用者資料和商業流程的 app。
這時候安全不是最後加上的 checkbox。安全會影響：
Lovable 提供很多安全工具，但這些工具不是保證。文件也明確說明，security scanners 可以找出常見問題，但不能取代完整安全審查。處理敏感資料或 critical functionality 的 app，仍然需要更嚴格的專業 review。
你可以把 Lovable app 的安全分成三層：
應用程式層安全 = 程式碼、路由、Edge Functions、輸入處理、相依套件
資料層安全 = RLS、資料庫 Schema、Storage、PII、Secrets
工作區層治理 = 專案存取、發布控制、Connectors、成員、稽核紀錄
這三層要一起看。
只修 app code，但 workspace（工作區）任何 editor 都能 publish externally，仍然有風險。
只開 Security scan，但 RLS（Row Level Security，列層級安全） 沒有用多使用者測試，仍然有風險。
只把 API key（API 金鑰） 放 Secrets，但 connector access 開給整個 workspace（工作區），仍然有治理問題。
開始第 15 章前，請先確認：
本章仍以 LaunchNote 為例。它的安全目標：
公開訪客：
- 只能讀取已發布的更新日誌項目。
通過身分驗證的專案成員：
- 只能存取自己所屬的專案。
專案管理員：
- 可以管理成員、帳務和發布設定。
Secrets：
- Resend、AI、Paddle、Slack 憑證絕不能暴露在前端。
PII：
- 使用者電子郵件和團隊成員邀請必須視為個人資料。
發布：
- 公開上線前不得有重大安全發現。
Lovable 的 Security view 有 security memory，可以提供 scanner 和 agent 專案背景。這不是拿來忽略真正問題的地方，而是讓掃描更懂你的 app。
你可以請 Lovable 產生安全記憶草稿：
請為 LaunchNote 建立安全記憶草稿。
應用程式概述：
LaunchNote 是讓軟體團隊管理和發布公開更新日誌項目的 SaaS。
存取模型：
- 公開訪客只能讀取已發布項目。
- 通過身分驗證的使用者只能存取自己具有成員關係之專案的儀表板。
- 管理員可以管理成員和帳務。
- 編輯者可以建立草稿和編輯項目。
- 檢視者可以讀取儀表板內容，但不能編輯。
敏感資料：
- 使用者電子郵件。
- 團隊邀請。
- 帳務狀態。
- API Key 和 Webhook Secret。
絕不能發生的事情：
- 公開訪客讀取草稿。
- 使用者讀取其他團隊的專案資料。
- Secrets 暴露在前端程式碼中。
- 未通過身分驗證就存取管理員操作。
- 只信任前端狀態判斷付款狀態。
不要使用這份記憶排除真正的安全發現。
Security memory 的價值，是讓 Deep scan 和 Lovable agent 在評估 access control 時有產品上下文。
圖 15-1：Security 總覽把 Basic scan、Deep scan、RLS、secrets 與發布防護放在同一套安全流程中。
Basic scan 是比較快的 configuration 和 dependency check。Lovable 文件說它涵蓋：
這是發布前最低限度。
提示詞：
請為 LaunchNote 執行 Basic Security Scan。
掃描後，請摘要：
- RLS Policy 發現。
- 資料庫 Schema 發現。
- 相依套件漏洞。
- 所有應阻擋發布的錯誤等級發現。
暫時不要自動修正任何項目。
請用產品語言說明每個發現。
先不要急著 Try to fix all。安全 finding 要先理解：
Deep scan 會做更完整的 agentic code review。文件說它會在 Basic scan 的基礎上，加上：
Deep scan 不會在你工作時自動一直跑。你可以從 Project（專案） Security view、Security center 或 publish dialog 觸發。
適合 Deep scan 的時機：
提示詞：
LaunchNote 公開上線前，請執行 Deep Security Scan。
重點區域：
- 身分驗證和受保護路由。
- RLS 和專案成員關係邊界。
- Edge Functions。
- Paddle 權益邏輯。
- Resend 信件工作流程。
- AI 摘要函式。
- Storage Bucket 存取。
- Secrets 暴露。
- 錯誤訊息和紀錄。
掃描後：
- 優先處理錯誤等級的發現。
- 說明每個發現。
- 建議修正計畫。
- 未經審查，不要套用大範圍變更。
Deep scan 結果要搭配第 13 章和第 14 章的方法驗證。安全修正如果沒測，可能會修掉功能。
圖 15-2：Project Security view 集中呈現 findings、掃描狀態與修正入口，適合依風險逐項處理。
Project（專案） Security view 會把 findings 分成：
處理順序：
錯誤
-> 高影響警告
-> 相依套件漏洞
-> 資訊等級的強化建議
提示詞：
請檢查目前 Security View 的發現。
請建立修正計畫：
- 依嚴重程度分組。
- 說明每個發現為何重要。
- 指出哪些發現會阻擋公開上線。
- 指出哪些修正可能影響身分驗證、RLS、付款或整合。
- 建議每項修正後的驗證步驟。
暫時不要忽略或修正任何發現。
如果你要修特定 finding：
請修正這個特定的 Security View 發現：
[發現標題或參照]
編輯前：
- 說明問題。
- 說明預計的修正方式。
- 列出受影響的檔案和 Policy。
- 列出驗證步驟。
編輯期間：
- 不要修改無關區域。
- 不要放寬 RLS。
- 不要暴露 Secrets。
安全 findings 可以用 automated remediation，但你一定要 review changes。
RLS（Row Level Security，列層級安全） 是資料安全核心。Basic scan 可以 lint 常見錯誤，Deep scan 可以看 access control 風險，但它不能取代你的產品權限測試。
LaunchNote 至少要測：
公開訪客：
- 可以讀取已發布項目。
- 不能讀取草稿。
- 不能存取儀表板。
使用者 A：
- 專案 A 的管理員。
- 可以讀取專案 A 的草稿。
- 不能讀取專案 B 的草稿。
使用者 B：
- 專案 B 的編輯者。
- 可以編輯專案 B 的草稿。
- 不能管理專案 B 的帳務。
- 不能讀取專案 A 的草稿。
使用者 C：
- 已通過身分驗證，但沒有成員關係。
- 不能存取任何專案儀表板。
提示詞：
請使用角色測試案例驗證 RLS。
角色：
- 公開訪客。
- 使用者 A：專案 A 的管理員。
- 使用者 B：專案 B 的編輯者。
- 使用者 C：沒有成員關係。
資料：
- 專案 A 有草稿和已發布項目。
- 專案 B 有草稿和已發布項目。
檢查：
- 公開讀取權限。
- 儀表板存取權限。
- 草稿可見性。
- 項目編輯權限。
- 成員管理權限。
回報：
- 哪些檢查通過。
- 哪些檢查失敗。
- 問題出在使用者介面、查詢、Policy 或測試設定。
不要為了讓測試通過而放寬 Policy。
最後一句很重要。安全測試失敗時，不能用「放寬 policy」當第一反應。
第 9 和第 11 章已經講過 Secrets 和 VITE_ 的差異。第 15 章要把它升級成治理問題。
要盤點：
Business / Enterprise 的 Security center 有 Secrets overview，可以跨 workspace（工作區）看 secret names、associated projects、type、publish status、creation date 和 project（專案）-level findings，但不會顯示 secret values。
提示詞：
請為這個工作區建立 Secrets 稽核計畫。
重點：
- 含有 Secrets 的已發布專案。
- 舊的或未使用的憑證。
- 同時有安全發現和 Secrets 的專案。
- 正式環境和預備環境的連線隔離。
- 可能需要輪替的 Secrets。
針對 LaunchNote，請驗證：
- 前端程式碼中沒有 Secret。
- 私人金鑰沒有儲存為 VITE_ 變數。
- Edge Functions 從 Secrets 讀取私人憑證。
- Connector 憑證的權限範圍合理，而且仍有使用需求。
Secrets 治理不是只看有沒有藏好。還要看 scope、owner、rotation、使用中的 project（專案）。
圖 15-3：Sensitive Data Scanning 可檢查對話、附件、Cloud database 與 storage 中的敏感資料。
Sensitive data scanning 是 Enterprise 功能，用來偵測 PII。它可以掃：
它使用 Google Cloud DLP 偵測常見格式，例如 email、phone、address、credit card、government ID、medical data、passwords、API keys 等。
它有幾個模式：
建議採用流程：
初期：僅記錄，了解工作區裡會出現哪些 PII
團隊穩定後：傳送前詢問，讓使用者可以遮蔽資料
高風險環境：封鎖原始內容，禁止原始 PII 進入聊天
發布前：執行隨選掃描
提示詞：
請為 LaunchNote 建立敏感資料審查計畫。
檢查：
- 聊天紀錄。
- 上傳的檔案。
- Lovable Cloud 資料庫。
- Lovable Cloud Storage。
優先處理：
- 高敏感度發現。
- 身分驗證 Secrets。
- 信用卡或財務資料。
- 政府核發證件或醫療資料。
- 出現在非預期位置的使用者電子郵件。
針對每個發現，請建議：
- 遮蔽。
- 刪除。
- 附上理由並標記為「非 PII」。
- 移除底層資料庫資料列並重新掃描。
不要在未說明理由的情況下排除發現。
限制也要知道：
所以乾淨 scan 不等於完全沒有 PII，只代表掃描範圍內沒有找到。
Privacy & security settings 裡有幾個發布相關控制：
對團隊 workspace（工作區），建議至少考慮：
首次發布前要求執行 Basic Security Scan：啟用
有重大安全發現時阻擋發布：啟用
預設網站存取權限：依應用程式類型決定
誰可以對外發布：受監管團隊僅限管理員和擁有者
有 PII 時阻擋發布：Enterprise 且使用敏感資料掃描時啟用
提示詞：
請檢查正式環境 SaaS 工作區的發布控制。
請為以下項目建議設定：
- 預設網站存取權限。
- 誰可以對外發布。
- 首次發布前要求執行 Basic Security Scan。
- 有重大安全發現時阻擋發布。
- 有 PII 時阻擋發布。
- 應用程式登入方式。
背景：
- 工作區包含具有身分驗證、付款和使用者資料的 SaaS 應用程式。
- 編輯者可以建置專案，但公開上線應要求更嚴格的審查。
請說明每項設定的取捨。
這些不是 app code，卻會直接影響安全。
Connectors 能讓 app 存取 Slack、Resend、Notion、Airtable、Google Maps、GitHub 等外部系統。這些 connection 通常是 workspace（工作區）-level。
你要管理：
Lovable 文件提醒，connection access 在 Lovable build/collaboration 階段會被 enforced，但 project（專案）published 後 live app 是否可訪問，不由 connection access 控制。
提示詞：
請稽核 LaunchNote 的 Connector 治理。
Connectors：
- Resend.
- Slack.
- Notion.
- Airtable.
- Google Maps.
- GitHub API（如有使用）。
檢查：
- 誰可以建立連線。
- 誰可以存取每個連線。
- 是否有任何連線在沒有必要的情況下與整個工作區共用。
- Scope 是否已最小化。
- 預備環境和正式環境是否隔離。
- 外部協作者是否應存取使用這些連線的專案。
公開上線前，請建議必要變更。
外部 API 權限太大，是常見安全問題。不要讓 convenience 變成全 workspace（工作區）風險。
單一 project（專案）用 Security view。多 project（專案）workspace（工作區）用 Security center。
Security center 可看：
Enterprise 還可有 Workspace（工作區） insights 和 scheduled Deep scans。
適合 Security center 的工作：
提示詞：
請建立每週 Security Center 審查工作流程。
對象：
工作區管理員和擁有者。
請包含：
- 優先檢查哪些篩選條件。
- 如何優先處理已對外發布的專案。
- 如何處理有重大錯誤的專案。
- 如何審查相依套件漏洞。
- 如何稽核舊的 Secrets。
- 何時開啟個別專案的 Security View。
- 內部報告應匯出哪些內容。
這把安全從單次發布檢查，變成 workspace（工作區）operation。
Enterprise Audit logs 可搜尋 workspace（工作區）activity。它能顯示誰在何時做了什麼，影響哪個 resource。
常見用途：
Audit logs 保留約 13 週，約 90 天。
提示詞：
請使用 Audit Logs 建立事故調查檢查清單。
情境：
某個專案帶著非預期變更被發布到外部。
檢查：
- 專案發布事件。
- 事故時間前後的提示詞送出事件。
- 協作者變更。
- 工作區設定變更。
- Secrets 或整合變更。
- 專案移動或刪除事件。
針對每個事件，記錄：
- 操作者。
- 時間戳記。
- 資源。
- 需要檢查的 JSON 詳細資料。
- 後續操作。
Audit logs 不是用來日常寫功能，但當事故發生時，它能讓你回答「誰、何時、做了什麼」。
安全修正常會影響正常使用。
例如：
所以每個 security fix 都要接 verification：
套用這項安全修正後，請驗證：
- 公開更新日誌仍可正常運作。
- 儀表板成員仍可讀取允許的資料。
- 非成員仍被阻擋。
- Paddle Webhook 或付款流程在測試模式下仍可運作。
- Resend 信件仍從後端發送。
- AI 摘要仍可運作。
- 前端程式碼中沒有出現 Secret。
安全不是「越鎖越好」。安全是「正確的人能做正確的事，不正確的人不能做」。
請為這個專案建立安全記憶草稿。
請包含：
- 應用程式概述。
- 使用者角色。
- 資料敏感度。
- 存取控制規則。
- 絕不能發生的事情。
- 可接受的風險，如有。
不要使用這份記憶排除真正的漏洞。
為什麼有效：
請檢查最新的 Security View 發現。
請提供：
- 依嚴重程度分組的發現。
- 每個發現的重要原因。
- 是否阻擋公開上線。
- 建議修正方式。
- 可能受影響的檔案、Policy 或設定。
- 修正後的驗證步驟。
暫時不要修正或忽略任何項目。
為什麼有效：
請使用測試角色驗證 RLS 存取規則。
角色：
- 公開訪客。
- 使用者 A：專案 A 的管理員。
- 使用者 B：專案 B 的編輯者。
- 使用者 C：沒有成員關係的已驗證使用者。
請驗證：
- 公開訪客只能讀取已發布項目。
- 成員可以讀取自己所屬專案的資料。
- 使用者不能讀取其他專案的草稿。
- 編輯者不能管理帳務或成員。
- 非成員不能存取儀表板。
不要為了讓測試通過而放寬 Policy。
為什麼有效：
請建立敏感資料審查計畫。
掃描來源：
- 聊天紀錄。
- 上傳的檔案。
- Cloud 資料庫。
- Cloud Storage。
優先處理：
- 高敏感度發現。
- 身分驗證 Secrets。
- 財務資料。
- 政府核發證件或醫療資料。
- 出現在非預期位置的使用者 PII。
針對每個發現，請建議遮蔽、刪除、標記為「非 PII」，或修正底層資料庫內容後重新掃描。
為什麼有效：
請檢查正式環境應用程式的工作區治理設定。
檢查：
- 預設專案存取權限。
- 預設網站存取權限。
- 誰可以對外發布。
- 外部協作者。
- 應用程式登入方式。
- 首次發布前要求執行 Basic Security Scan。
- 有重大安全發現時阻擋發布。
- 有 PII 時阻擋發布。
- Connector 建立和存取權限。
- 自動修正安全設定。
請提供建議設定和取捨。
為什麼有效：
替 LaunchNote 做一次發布前安全 review。
使用 Pattern 1 建立 security memory。
預期結果：
跑 Basic scan，再跑 Deep scan。
預期結果：
使用 Pattern 3 驗證多角色資料存取。
預期結果：
使用 Pattern 5 檢查 workspace（工作區）settings。
預期結果：
No issues found 不代表沒有風險。它只代表目前 scan 沒有找到問題。
Ignore 是治理決策，不是清空紅點。每個 ignored finding 都要有明確理由。
RLS（Row Level Security，列層級安全） 失敗要先查原因，不要直接讓 policy 更寬。
Publish permission、external collaborators、connectors、default website access 都可能造成風險。
Secrets 需要 owner、scope、rotation、usage review。
PII finding 不會自己消失。Chat 可以 redact，file 可以 delete，database row 要從 database 修。
安全修正可能破壞 auth（驗證）、payment、email、AI 或 public page。修完一定要驗證。
以下情境不要只靠 Lovable 自動掃描：
Lovable 的工具能幫你早期發現常見問題，但專業 security review 或 pentest 可以補上更完整的攻擊視角。
讀完本章後，建議用自己的專案情境繼續追問 Lovable 或本書作者：
嗨！我是 Wolke，曾任 Google Developer Expert（GDE，2019–2023） 與 LINE API Expert。我熱衷於研究 AI Agent、n8n 自動化工作流及全端開發架構，致力於將 AI 技術轉化為實際的生產力工具。
如果你喜歡這篇文章，歡迎透過以下方式與我交流，獲取更多技術實戰內容：
📚 技術著作：《實用的 Gemini API 開發點子書》，帶你運用 Gemini App、Google AI Studio、Gemini CLI 與 Antigravity IDE，打造 AI Agent 與實用產品。
📝 技術部落格：歡迎追蹤我的 Medium，我會持續分享 Agentic Automation、架構設計與實際開發的踩坑心得。
🎤 技術講座：我持續受邀至技術社群及研討會，分享 AI Agent、自動化工作流、DevOps 與全端開發實戰。曾於 2026 年 6 月 26 日的 DevOpsDays Taipei 2026 主講「不再只是寫腳本！讓 AI 代理人成為你的 SRE 最佳夥伴」工作坊。
如果你的企業、社群或學校正在尋找相關主題講者，歡迎私訊與我聯繫、洽談講座合作！
🎁 免費送 Lovable 額度給讀者！
我每個月會開放 10 個名額，每人 50 點 Lovable 額度，讓大家實際動手打造自己的網站或 App。
參加方式：
確認後，我會邀請你加入 Lovable workspace 並設定 50 點額度。名額有限，送完為止！
iThome鐵人賽
看影片追技術