安全与可靠性审计报告

test/fixture/sample-app · 已扫描 9 个文件 · 生成于 2026-08-21

审计对象test/fixture/sample-app
扫描文件数9
报告日期2026-08-21
引擎引擎 0.9.0 · 源版本 fixture
报告编号AD30E-F19FC-5F7EF-18EBE
VIBEAUDIT

安全与可靠性审计报告

test/fixture/sample-app · 2026-08-21

审计对象test/fixture/sample-app
扫描文件数9
报告日期2026-08-21
引擎引擎 0.9.0 · 源版本 fixture
报告编号AD30E-F19FC-5F7EF-18EBE
0/100
评级 F
AD30E-F19FC-5F7EF-18EBE
vibeaudit.vip

本报告由自动化安全与可靠性扫描器 VibeAudit 生成,由 AI 智能体 Volt 运营。业务所有权、生产授权以及任何承诺中的人工复核,仍由人类伙伴负责。

保密——仅面向报告接收方。转发须获得所有者许可。

vibeaudit.vip

执行摘要

自动扫描结果:总体评分与各严重度的发现数量。

0/100
VibeScore
评级 F
总体评级
严重6
高危2
中危6
低危0
信息1

覆盖状态

本次扫描能够与无法覆盖的范围。零发现不代表未测试区域是安全的。

仓库完整10 checks
线上未执行0 checks
代码包未执行0 checks
人工未执行0 checks

发现索引

#严重度发现类别
01 严重 Stripe live secret key 暴露在代码仓库中 secrets
02 严重 OpenAI API key 暴露在客户端代码中 secrets
03 严重 Supabase service_role 密钥位于客户端代码中 secrets
04 严重 表“orders”未启用行级安全 database
05 严重 浏览器代码直接调用 OpenAI API abuse
06 严重 OpenAI SDK 被打包进客户端代码 abuse
07 高危 Resend API key 暴露在代码仓库中 secrets
08 高危 环境文件“.env”包含真实值并已提交 config
09 中危 仓库中未找到访问策略 database
10 中危 .gitignore 未排除 .env 文件 config
11 中危 通配符 CORS(cors({ origin: "*" })) config
12 中危 管理员风格路由“/admin/users”——请验证服务端保护 auth
13 中危 管理员风格路由“/admin/settings”——请验证服务端保护 auth
14 中危 仓库中的 AI 端点均未限流 abuse
15 信息 应用指纹:Lovable · React + Vite · Supabase 后端 stack

详细发现

严重

发现 01Stripe live secret key 暴露在代码仓库中

secrets

.env

sk_live_…y000 (29 chars)

影响: Stripe 线上秘密密钥可让攻击者退款、修改价格,最坏情况下可盗取账户资金。

修复方法: 立即在 Stripe 控制台轮换密钥,仅存于服务端,并改用只授予集成所需权限的受限密钥。

严重

发现 02OpenAI API key 暴露在客户端代码中

secrets

src/lib/openai-client.ts

sk-proj-…r8s9 (46 chars)

影响: 任何访问者都能从浏览器包中读取此密钥,并在几分钟内耗尽你的 OpenAI 额度。

修复方法: 将密钥移至服务端环境变量,并通过后端或 Supabase Edge Function 代理 OpenAI 调用。立即在 platform.openai.com 轮换已暴露密钥。

严重

发现 03Supabase service_role 密钥位于客户端代码中

secrets

src/lib/supabase.ts

eyJhbGci…ghij (106 chars)

影响: service_role 密钥会绕过所有行级安全策略。若位于客户端,任何访问者都能完全读写数据库中的每一行。

修复方法: service_role 密钥只能存在于 Edge Functions 或服务端环境变量中。浏览器应使用 anon 密钥,由 RLS 执行访问规则。请在 Supabase 控制台 → Settings → API 中轮换密钥。

参考资料

严重

发现 04表“orders”未启用行级安全

database

supabase/migrations/0001_init.sql

CREATE TABLE orders — no matching "ENABLE ROW LEVEL SECURITY"

影响: 没有 RLS 时,任何使用 anon 密钥的访问者都能读取、修改或删除“orders”中的每一行,包括其他用户的数据。这是 Lovable/Bolt 应用最常见的数据泄露原因。

修复方法: 执行:ALTER TABLE orders ENABLE ROW LEVEL SECURITY;然后创建按 auth.uid() 限制访问的策略。即使表应公开只读,也应明确编写 FOR SELECT 策略。

参考资料

严重

发现 05浏览器代码直接调用 OpenAI API

abuse

src/lib/openai-client.ts

g) { const res = await fetch('https://api.openai.com/v1/chat/completions', {

影响: 任何访问者都可以用自己的脚本重放此调用;公网与你按量计费的 API 之间没有服务端保护。循环调用可能产生巨额账单。

修复方法: 通过服务端函数(Supabase Edge Function/API 路由)代理所有 OpenAI 调用;密钥存于环境变量,并验证输入、按用户或 IP 限流。

严重

发现 06OpenAI SDK 被打包进客户端代码

abuse

src/lib/openai-client.ts

'openai'

影响: 该 SDK 面向可信的服务端运行环境。打包到浏览器意味着凭据落入访问者手中,且无法在服务端限流或审计调用。

修复方法: 将 OpenAI SDK 的使用移至 API 路由或 Edge Function,前端通过你自己的会话认证调用。

高危

发现 07Resend API key 暴露在代码仓库中

secrets

.env

re_abcde…6789 (35 chars)

影响: 与 SendGrid 相同:攻击者可冒充已验证域名发送钓鱼邮件。

修复方法: 在 Resend 控制台轮换密钥,并仅从服务端代码发信。

高危

发现 08环境文件“.env”包含真实值并已提交

config

.env

VITE_API_URL, RESEND_API_KEY, STRIPE_KEY

影响: 一旦仓库推送到 GitHub 或被分享,其中的所有秘密都会随之泄露。机器人会在新公开仓库出现后的几分钟内扫描 .env 文件。

修复方法: 从 git 中移除该文件(git rm --cached),加入 .gitignore,轮换其中所有密钥,并通过托管平台的环境变量设置分发秘密。

中危

发现 09仓库中未找到访问策略

database

影响: 迁移中存在数据表,但未找到 CREATE POLICY。策略可能只存在于 Supabase 控制台中(代码审查不可见且重新部署时可能丢失),也可能数据根本未受保护。

修复方法: 将所有 RLS 策略移入版本控制的迁移文件,使其可审查、可复现。

参考资料

中危

发现 10.gitignore 未排除 .env 文件

config

影响: 下次“全部提交”时可能意外提交含秘密的环境文件。

修复方法: 将“.env”和“.env.*”加入 .gitignore(保留“!.env.example”)。

中危

发现 11通配符 CORS(cors({ origin: "*" }))

config

api/server.js

影响: 任何网站都能从访问者浏览器向你的 API 发起带凭据请求。与 Cookie 认证结合会导致跨站攻击。

修复方法: 将来源限制为实际域名,例如 origin: ["https://yourapp.com"]。仅对完全公开且不使用凭据的端点保留“*”。

中危

发现 12管理员风格路由“/admin/users”——请验证服务端保护

auth

src/pages/Admin.tsx

path: '/admin/users'

影响: 客户端路由守卫只是表面保护,页面源码和底层 API 仍可访问。此项标记看似仅限管理员的路由;请确认后端确实执行角色检查。

修复方法: 确保每个管理员 API 端点都在服务端检查调用者角色(RLS 中的 auth.uid(),或 Edge Function 中检查角色声明)。隐藏 UI 只能作为辅助,绝不能作为保护机制。

中危

发现 13管理员风格路由“/admin/settings”——请验证服务端保护

auth

src/pages/Admin.tsx

path: '/admin/settings'

影响: 客户端路由守卫只是表面保护,页面源码和底层 API 仍可访问。此项标记看似仅限管理员的路由;请确认后端确实执行角色检查。

修复方法: 确保每个管理员 API 端点都在服务端检查调用者角色(RLS 中的 auth.uid(),或 Edge Function 中检查角色声明)。隐藏 UI 只能作为辅助,绝不能作为保护机制。

中危

发现 14仓库中的 AI 端点均未限流

abuse

api/ai.js

AI calls in 1 server file(s); no rate-limit middleware found

影响: 一个脚本循环即可耗尽 LLM 预算或暴力破解认证端点。限流是 AI 工具通常不会替你添加的关键保护。

修复方法: 为 AI 与认证路由增加按 IP/用户限流(express-rate-limit、@upstash/ratelimit,或在 Supabase Edge Function 中检查计数表)。

信息

发现 15应用指纹:Lovable · React + Vite · Supabase 后端

stack
README.md: lovable\.dev|cdn\.lovable\.dev|Built wit…

影响: 识别为 Lovable 导出项目。审计会优先检查该技术栈的典型缺陷。

修复方法: Lovable 应用的首要风险:Supabase 表未启用 RLS,访问策略仅存在于控制台中(重新导入会丢失)。修复 RLS 后,将每项策略同步到 supabase/migrations。