1. 打包进前端 JavaScript 的 API key
这是危害最大、也最容易犯的错误。你让 AI 工具「加上 Stripe 支付」或「接入 OpenAI」，它就把 secret key 直接接进了一个客户端组件。应用能跑——而你的 secret key 现在会发送到每个访客的浏览器，任何打开 DevTools 或在你 JS 打包文件里搜索的人都能读到它。
任何带 NEXT_PUBLIC_（或 VITE_、REACT_APP_）前缀的变量，都会在构建时嵌入客户端打包文件。secret key——Stripe 的 sk_live_、OpenAI 的 sk-、数据库 URL、service role key——只应在服务端代码中读取：API route、服务端组件或 edge 函数。
快速检查：打开你已上线的网站，查看页面源码和打包后的 JS，搜索 sk_live、sk- 以及你 .env 中各密钥的开头几个字符。只要出现任何一个，就先轮换密钥，再把调用移到服务端。
2. .env 或 .git 直接从 web root 对外提供
数量惊人的已上线应用，只要你去请求，就会乖乖返回它们的 .env 文件——甚至整个 .git 目录。一个配置错误的静态文件服务器，或一个把所有东西都复制进 public 目录的框架模板，就足以造成这种情况。
影响是彻底的：数据库凭据、认证密钥、API key，全都在一个文件里。暴露的 .git 目录几乎同样糟糕，因为攻击者可以还原出你完整的源代码历史，包括那些曾被提交、后来又「删掉」的密钥。
快速检查只需十秒钟：
curl -i https://yourapp.com/.env
curl -i https://yourapp.com/.git/config
# Both should return 404 (or 403) — never 200.3. 没有 Content-Security-Policy
AI 工具几乎从不添加安全响应头，而 CSP 是其中最重要的一个。没有它，你应用中任何一处的 HTML 注入或 XSS 漏洞，都能让攻击者在你用户的浏览器中运行任意 JavaScript——窃取会话、外泄数据。
对大多数应用来说，一个不错的起步策略是：default-src 'self'，阻止 object 和页面嵌入，只允许你实际用到的第三方脚本源。先从严格开始，再谨慎放宽——绝不要反过来。
// next.config.js
const csp = [
"default-src 'self'",
"script-src 'self'",
"style-src 'self' 'unsafe-inline'",
"img-src 'self' data:",
"base-uri 'none'",
"frame-ancestors 'none'",
"object-src 'none'",
].join("; ");
module.exports = {
async headers() {
return [{ source: "/:path*", headers: [{ key: "Content-Security-Policy", value: csp }] }];
},
};4. 缺少 Secure、HttpOnly 和 SameSite 的会话 cookie
如果你的认证库是 AI 工具用默认选项接起来的，那就值得检查一下会话 cookie 的标志。没有 HttpOnly 的 cookie 能被任何注入脚本读取（把一个小小的 XSS 变成完整的账户接管），没有 Secure 的会在明文 HTTP 上泄露，没有 SameSite 的则会让跨站请求伪造容易得多。
在你已上线的应用上打开 DevTools → Application → Cookies。每个会话或认证 cookie 都应显示这三项：Secure、HttpOnly 和 SameSite=Lax（或 Strict）。
5. HTTP 从不跳转到 HTTPS（且没有 HSTS）
大多数托管平台会自动为你提供 HTTPS——但仍有不少应用在明文 HTTP 上乖乖响应而不做重定向，或者做了重定向却从不发送 Strict-Transport-Security 响应头。无论哪种情况，在地址栏里输入你域名的用户，第一个请求都是未加密的，而这个请求可能在你的重定向发生之前就被拦截或降级。
修复只需两行配置：一个从 HTTP 到 HTTPS 的永久 301 重定向，再加一个 HSTS 响应头（max-age=31536000; includeSubDomains），让浏览器再也不肯降级。
6. CORS 被设成允许一切
当 AI 生成的前端在开发时连不上自己的 API，生成出来的「解决办法」几乎总是 Access-Control-Allow-Origin: *——有时还顺带允许了凭据。这等于告诉互联网上的每一个网站：它们都可以从访客的浏览器里调用你的 API。
对一个服务于你自己前端的 API 来说，允许的源应当恰好是你自己的域名，别无其他。通配符 CORS 只对真正公开、无需认证、只读的 API 才可以接受。
7. 你的域名没有 SPF 或 DMARC
这一条和你应用的代码完全无关——它关乎你的域名。没有 SPF 和 DMARC 这两种 DNS 记录，任何人都能发送声称来自 [email protected] 的邮件，而接收邮件服务器无从得知它是伪造的。这就是打着你品牌旗号、针对你自己用户的钓鱼。
两条 DNS TXT 记录就能解决。如果你通过 Resend、Postmark 或 SES 之类的服务商发邮件，它们的文档会给你确切的 SPF 值；在它旁边再加一条 DMARC 策略，并在确认合法邮件都能通过后，把它从 p=none 收紧到 p=quarantine。
一次过一遍这七项
这份清单上的每一项都能从外部检测到，也就是说你不必逐条手动排查。AppSafe 一次扫描就能跑完所有这些检查——外加 SSL/TLS、subdomain takeover、source map 等等——把结果评为 A 到 F，并为每个发现的问题给你一条可直接粘回 Cursor 或 Claude Code 的 AI 修复提示词。
首页上的快速扫描无需注册。完整扫描（包括暴露密钥的检查）只在你已验证所有权的域名上运行——这是有意为之，因为我们不会去别人的 JS 打包文件里搜索密钥。