specsfy-specialist-application-security

应用安全

适用场景

• 当变更引入或涉及信任边界、身份、外部输入（上传、URL、查询、反序列化）或敏感数据时触发。
• 在设计具有新攻击面的功能（新的公共端点、新的集成、新的用户类型）之前也应触发，以便进行预防性威胁建模。
• 不要用它替代对流水线/部署凭据的审查——这类工作应使用 $specsfy-specialist-delivery-engineering；此处关注的是应用及其数据，而非交付流水线。
• 当风险涉及按行或租户建模数据访问时，应与 $specsfy-specialist-postgres/$specsfy-specialist-supabase 配合使用。

流程

1. 在考虑控制措施之前，梳理资产、参与者、信任边界、外部输入和影响（哪些状态会发生变化）。
2. 在选择控制措施之前，明确合理的威胁及其实际影响——不要针对系统上下文中并不存在的威胁实施防御。
3. 对每项读取或修改数据的操作，检查身份验证、对象级授权（而不仅是路由级授权）以及租户隔离。
4. 根据预期类型、大小和用途验证所有输入；根据渲染上下文规范化输出；在适用时保护可变操作免受重放和 CSRF 攻击。
5. 审查密钥管理、传输中和静态数据的加密、会话生命周期、易受攻击的依赖项以及生产环境配置。
6. 针对已识别的关键边界，编写正向测试（已授权的流程可以正常运行）和负向测试（未授权的流程会失败）。
7. 记录剩余风险、负责人、相关的可观测性信号和响应计划——没有任何系统能做到“100% 安全”，只有风险已知且受到监控的系统。

模式

• 默认拒绝访问，并为每种身份和操作授予所需的最小权限。
• 对每项操作和访问的每个对象，都在服务器端进行授权——绝不只依赖客户端检查，也不应信任来自客户端的对象 ID，必须重新验证其所有权/租户。
• 默认将文件上传、用户提供的 URL、使用外部数据渲染的模板、动态查询以及外部数据反序列化视为恶意输入。
• 不要自行实现加密；使用成熟的原语和库。绝不记录密钥、令牌、密码或敏感数据，即使在调试环境中也不例外。
• 定期轮换凭据，并优先使用临时身份（短期令牌、STS/OIDC），而非长期静态密钥。
• 按参与者和资源限制滥用（按用户/API 密钥/租户进行速率限制），而不仅仅按 IP 限制——共享 IP（NAT、代理）会影响合法用户，而分布式攻击者可以绕过仅按 IP 设置的限制。
• 修复漏洞时，应修复根本原因并添加回归测试；除非修复或验证所必需，否则不要披露利用细节。

反模式

• 仅按路由检查授权（保护 /admin/*），却不检查路由中访问的具体对象：以租户 A 身份通过身份验证的用户，只需更改 URL 中的 ID，就能访问租户 B 的 /api/orders/123（IDOR — 不安全的直接对象引用）。
• 只在客户端（浏览器中的 JavaScript）验证输入，却不在服务器上重新验证：任何直接发往 API 的请求都能完全绕过客户端验证。
• 依赖客户端声明的 Content-Type 或文件扩展名来决定如何处理上传内容：这会让恶意文件伪装成无害类型。
• 将应用机密（API 密钥、数据库密码）存储在环境变量中，却不控制对进程或日志的访问；或者记录包含身份验证令牌的完整请求负载——即使源头使用了正确的“保险库”，机密仍会通过间接渠道泄露。
• 未通过具体的负向测试证明原始攻击向量已失效，就宣称“系统安全”或“漏洞已修复”。

验证

• 负向测试用例：未经过身份验证、身份不正确、租户不正确，以及重放已处理请求的访问都必须以受控方式失败。
• 使用项目已采用的工具分析存在漏洞的依赖项并扫描泄露的机密，将其纳入正常工作流，而非仅在大型版本发布前手动执行。
• 安全的生产环境配置：安全标头（例如 Content-Security-Policy、Strict-Transport-Security）、Cookie 属性（HttpOnly、Secure、SameSite），以及仅允许真正必要来源的 CORS 策略。
• 为每项声称已落实的控制措施及其残余风险提供具体证据——没有相应测试证明时，绝不要用绝对措辞宣称某项内容“安全”。

相关技能

• $specsfy-specialist-ansible 和 $specsfy-specialist-docker 实施主机、容器和运行时加固；此技能定义威胁、权限和控制措施，并明确配置需要证明的内容。
• $specsfy-specialist-laravel、$specsfy-specialist-nextjs 和 $specsfy-specialist-shadcn-ui 实施应用层；授权、服务器端验证和数据暴露仍由此技能负责。
• $specsfy-specialist-code-review 执行全面审查，$specsfy-specialist-observability 记录滥用迹象，同时避免泄露敏感数据。
• $specsfy-specialist-postgres 和 $specsfy-specialist-supabase 用于在数据层对行/租户进行授权建模（RLS、约束）。
• $specsfy-specialist-delivery-engineering 用于加固流水线凭据、签署制品和保障供应链安全。
• 当风险源于 API 契约设计（动词、版本控制、敏感字段暴露）时，使用 $specsfy-specialist-web-api-design。

阅读 references/standards.md，获取按边界划分的威胁建模检查清单、ASVS、API 安全和供应链安全相关内容，以及一手来源。