随着互联网应用的创新脚步加快，越来越多的开发者选择“vibe coding”——快速编码、快速上线，以求在激烈的市场竞争中抢占先机。然而，这种高速迭代的开发模式虽然极大提升了效率，却往往伴随着安全风险。本文将讲述一位开发者在仅用三天时间开发完成并上线一款聚合安全研究者资料的应用，却连续遭遇两次安全入侵的经历，剖析背后的安全漏洞，并提炼出宝贵的安全教训。该案例不仅进一步提醒广大开发者必须重视安全设计，也为快速迭代开发中的安全保障提供了实用参考。 该应用是一款目录型产品，旨在汇总来自多个安全研究平台如HackerOne、Bugcrowd和GitHub等的研究者资料。前端使用Lovable和Cursor，数据存储及访问则依托Supabase被管理的PostgreSQL数据库，此外数据的自动获取和写入都由后台自动化任务负责。
应用的早期设计允许用户通过Supabase Auth自注册并提交想要聚合的资料，但在实施中，开发者发现这无疑增大了身份验证与权限管理的复杂度和潜在风险，因而决定取消该功能。 然而，问题并未就此终结。第一个重大漏洞是电子邮件泄露。初步测试中，由于用户认证使用真实邮箱地址，发现查询资料表时响应数据中包含了用户邮箱字段。用户的隐私数据暴露显然是不被允许的。为解决这一问题，开发者创建了一个PostgreSQL视图，过滤掉敏感字段，只查询所需展示的信息，同时前端切换为查询这一视图。
表面上看，这是朝着更安全的方向迈进的一步，却不料造成了更严重的安全漏洞。 这一漏洞的根源在于PostgreSQL视图的权限行为。默认情况下，视图是以视图拥有者的身份执行查询操作，而这位拥有者通常是数据库管理员。在本案例中，当视图被设计为通过该身份访问数据时，就绕过了底层表上激活的行级安全策略（Row-Level Security，简称RLS）。这意味着即便前端不暴露任何写操作接口，认证用户依然可以通过数据库接口进行插入、更新和删除操作。攻击者利用此漏洞在上线24小时内成功对数据库中的数据进行了非法修改。
幸运的是，一位安全研究者及时发现了这一情况，并进行了负责任的漏洞披露，从而促使开发者修复该漏洞。 修复的措施包括撤销视图的高权限访问，重新设计查询逻辑，确保RLS策略得以有效执行。此外，明确设置视图的执行权限为安全调用者（SECURITY INVOKER）或者调整其他安全防护机制，成为避免类似问题的关键。如此深刻的教训警示开发者不要轻视数据库视图与安全策略间的微妙关系。 第二次攻击则源于认证机制的配置缺陷。尽管前端已关闭了用户自注册的功能，后台Supabase的认证服务依然未被完全禁用，这导致攻击者仍可通过邮箱密码方式进行注册，并以认证用户身份访问数据库。
由于RLS策略仍然允许新用户创建新资料记录，攻击者成功制造了新数据，尽管无法修改或删除已有资料。关闭后台用户注册功能后，问题得以根本解决。 总结此次两次安全事件，开发者进一步认识到快速开发固然重要，但安全漏洞几乎是快速上线的默认“副产品”。尤其是在使用Supabase和PostgreSQL这类强大数据库服务时，对其安全模型的深入理解缺失极易导致致命配置错误。数据库视图不自动继承RLS策略的设计细节必须高度警惕，同时不应忽略任何后台未被前端调用但依然开放的认证接口。 这一经历也强调了威胁建模的重要性。
该应用仅涉及公开数据，安全事件的负面影响较低，若涉及个人身份信息（PII）或受保护健康信息（PHI），类似疏忽将带来极具破坏力的后果。对开发者而言，除技术修复外，加强安全意识，合理设计认证与授权流程，使用安全基线配置，并积极响应安全社区的反馈，显得尤为关键。 总之，三天极速开发上线的应用两次被攻破的经历，为软件安全提供了生动的案例教材。它提醒开发者：在拥抱高效开发带来速度优势的同时，切莫忽视安全防护，合理配置数据库与认证服务，强化权限控制，才是保障用户数据安全和应用稳定运行的根本保障。通过此案例的反思，期许更多开发团队能在快速迭代架构中，融入更完善的安全策略，共同构建可靠的数字生态。
