这是给谁看的？
给任何用 AI 搭过应用、正准备发布它的人——你不需要会编程。如果你的应用会保存用户的数据（账户、消息、订单，随便什么），那么在上线之前，这是必做项。每一节都带一个比喻、风险说明，以及一段让 AI 替你配置好的提示词。你只管点头批准就行。
这件事什么时候做？（精确的时机）
时机很清楚，也没得商量：就在你发布应用、或把它交给真实用户之前。 当你只是一个人在自己电脑上测试时，什么都不会发生。但在你的应用连上互联网、装着别人数据的那一秒，没有这几把锁，你就是把一切都暴露了出去。而由于 AI 不会自己去做这件事（它想的是让应用能跑，而不是保护它），所以得由你明确地提出要求。
这份指南是从怎样的痛苦中诞生的
这是用 AI 搭应用的人最可怕的一次惊吓：你上线了应用，有人改了一改 URL 里的一个数字……然后就看到了另一个用户的数据。或者更糟：一个安全漏洞把你整个数据库都暴露了出去。搭建时你感觉不到——一切都「跑得起来」——但它是一颗定时炸弹。这 3 把锁能在几分钟内把它拆除。
第 1 把锁 · RLS（让每个人只看到属于自己的东西）
这样想象它
想象一个巨大的玩具箱，所有人都把自己的东西放进去。没有锁，任何人都能拿走所有人的东西。RLS（Row-Level Security，「行级安全」）就是一把神奇的锁，它知道每个人是谁：每个用户只能看到、只能碰属于自己的数据，哪怕所有东西都在同一个箱子里。
没有 RLS，一个恶意用户只需要在 URL 或一个请求里改一改某个 ID，就能看到另一个人的数据。这是在使用 Supabase 和 PostgreSQL 的应用里最常见的漏洞——也是最容易被利用的。这就是为什么它是第 1 把锁。
我在用 Supabase 搭配 PostgreSQL。我有这些表：[列出你的表和它们的用户列，例如：posts (user_id)、comments (post_id, user_id)]。 请配置 Row-Level Security，让每个用户只能查看/编辑/删除属于自己的记录。请遵循 Supabase 的官方最佳实践： - 在所有表上启用 RLS（ENABLE ROW LEVEL SECURITY）。 - 为 SELECT、INSERT、UPDATE 和 DELETE 分别创建独立的策略（不要用 FOR ALL）。 - 对性能很重要：把用户函数包装成 (SELECT auth.uid())，而不是裸用 auth.uid()，这样 Postgres 每次查询只求值一次，而不是每行求值一次。 - 把策略限制到 authenticated 角色（TO authenticated），而不是 public，这样匿名访客根本碰不到这张表。 - 绝对不要在策略里用 user_metadata（用户可以修改它）。 - 在策略用到的列上加索引（例如 user_id）。 - 记住：要让 UPDATE 生效，还需要一个 SELECT 策略。 - 给我完整的、可以直接贴到 Supabase SQL Editor 里的 SQL，并用一行话解释每个策略做什么。
那个会把你应用拖到超级慢的错误（「init-plan 陷阱」）
几乎所有教程都告诉你在策略里直接用
auth.uid()。但这会让 Postgres 每一行都求值一次——在一张 100.000 行的表里，差别就是一次 5 毫秒的查询和一次足足 5 秒的查询之间的差距！技巧（由 Supabase 官方文档记载）是：把它写成 `(SELECT auth.uid())`。这样它只会求值一次。这就是为什么上面的提示词里明确地要求了这一点。我怎么知道它已经生效了？
- 在你的应用里创建两个测试用户。
- 用用户 A 登录，创建一条记录。
- 用用户 B 登录：他不应该看到 A 的记录。
- 查看 Supabase 的 Security Advisor：如果你有哪张表忘了开 RLS，它会提醒你。
第 2 把锁 · CORS（谁可以调用你的 API）
这样想象它
CORS 是你 API 的门卫。它决定哪些网页有权敲门。没有门卫，全世界任何一个网站都能从你用户的浏览器里调用你的后端，并趁机利用他们的会话。
请在我的后端配置 CORS，让**只有**我的生产域名（https://mi-app.com）和开发环境的 localhost 能够发起请求。 - 生产环境中不要用 "*" 作为允许的来源。 - 只允许我真正用到的方法（例如 GET、POST、PUT、DELETE）。 - 只允许我需要的请求头。 - 根据我的技术栈准确告诉我每样东西该放在哪里：[告诉它你的框架/后端]。
绝对不能犯的错误
在启用凭据的同时保留
Access-Control-Allow-Origin: *。这就像敞着门，还挂了块牌子写着「请进，钥匙我留在里面了」。如果你的 AI 为了「让它快点跑起来」给你这样配置了，在发布前把它改掉。第 3 把锁 · Security Headers（给浏览器的防御指令）
这样想象它
安全 headers 就是你的网站在浏览器进门时交给它的家规：「别把我塞进别的网站的框架里」、「别加载我没授权过的网站的脚本」、「只通过安全连接跟我说话」。没有这些规则，浏览器会为所欲为——而这就给常见的攻击敞开了门。
请给我的应用添加推荐的安全 headers：Content-Security-Policy、X-Frame-Options、X-Content-Type-Options、Referrer-Policy、Strict-Transport-Security (HSTS) 和 Permissions-Policy。 - 用一行简单的话解释每一个是做什么的。 - 给我针对我的框架、可以直接用的配置：[告诉它你用哪个，例如 Next.js、Express]。 - 先以 report-only 模式启动 Content-Security-Policy，这样不会弄坏任何东西，再告诉我之后怎么把它收紧。 - 告诉我怎么验证结果。
免费给你的评分验一验
配置好之后，把你网站的 URL 贴到 securityheaders.com，它会给你一个从 A+ 到 F 的评分。这是确认它们都配置正确的最快方式——目标是拿到 A。
习惯 · 每次发布前都过一遍
你的发布前安全清单
- 在所有存有用户数据的表上启用 RLS（并用 2 个账户测试过）。
- CORS 限制到你自己的域名，绝不在启用凭据时用
*。 - Headers 配置好了，并在 securityheaders.com 上拿到 A 评分。
- 你的密钥（.env、API 密钥）从不上传到 GitHub（见本系列的 GitHub 指南）。
- 你查看了 Supabase 的 Security Advisor，没有红色的告警残留。
把它和 C-A-R 结合起来
安全恰恰是 AI 的建造者模式会忽略的那类东西。所以它完美契合 [C-A-R 协议](/recursos/protocolo-car-construir-sin-bugs)的审计阶段：当你在发布前做审计时，把这 3 把锁列进清单。建造想的是让它能跑；审计想的是它会怎样被攻击。
在 NeuralOS，安全是出厂自带的
在 NeuralOS 里，你搭建的应用生来就默认带好了这些防护——RLS、受限的来源和 headers——你根本不用记着去配置它们。这个理念就是：让你不会因为一时忘记而发布出不安全的东西。这个愿景已经在我们所搭建的路上。