security
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseSecurity — Compliance & Protection
安全——合规与防护
Assume breach. Defense in depth. Least privilege everywhere.
假设已遭入侵。采用纵深防御。全面遵循最小权限原则。
Security Defaults
安全默认配置
Every project ships with:
| Control | Implementation |
|---|---|
| Auth | OAuth 2.0 / OIDC via Auth.js or Supabase Auth |
| Sessions | HTTP-only, Secure, SameSite=Strict cookies |
| Passwords | bcrypt/argon2, min 12 chars, no max limit |
| API auth | Bearer tokens with expiry, refresh rotation |
| CORS | Explicit allowlist, never |
| HTTPS | Everywhere. No exceptions. HSTS headers. |
| CSP | Content-Security-Policy header on all pages |
| Rate limiting | Auth endpoints: 5/min. API: 100/min. Adjust per use. |
每个项目默认包含以下控制措施：
| 控制项 | 实现方式 |
|---|---|
| 身份验证 | 通过Auth.js或Supabase Auth实现OAuth 2.0 / OIDC |
| 会话管理 | 使用HTTP-only、Secure、SameSite=Strict属性的Cookie |
| 密码处理 | 采用bcrypt/argon2算法，最小长度12字符，无最大长度限制 |
| API身份验证 | 带过期时间的Bearer令牌，支持刷新令牌轮换 |
| 跨域资源共享（CORS） | 显式允许列表，生产环境绝不使用 |
| HTTPS | 全域启用，无例外。配置HSTS头部。 |
| 内容安全策略（CSP） | 所有页面均设置Content-Security-Policy头部 |
| 速率限制 | 身份验证端点：5次/分钟。API：100次/分钟。可根据使用场景调整。 |
OWASP Top 10 Quick Reference
OWASP Top 10 速查指南
| Vulnerability | Prevention |
|---|---|
| Injection (SQL, NoSQL, OS) | Parameterized queries, ORMs, never string concat |
| Broken Auth | MFA, session timeouts, account lockout |
| Sensitive Data Exposure | Encrypt at rest + transit, minimize data collection |
| XXE | Disable external entity processing |
| Broken Access Control | Check permissions server-side on every request |
| Security Misconfiguration | Defaults off, hardened configs, no debug in prod |
| XSS | Output encoding, CSP headers, sanitize HTML |
| Insecure Deserialization | Validate and type-check all serialized data |
| Known Vulnerabilities | |
| Insufficient Logging | Log auth events, access denied, input validation failures |
| 漏洞类型 | 预防措施 |
|---|---|
| 注入攻击（SQL、NoSQL、操作系统） | 使用参数化查询、ORM，绝不使用字符串拼接 |
| 身份验证机制缺陷 | 启用多因素认证（MFA）、会话超时、账号锁定 |
| 敏感数据暴露 | 静态和传输过程中均加密，最小化数据收集 |
| XML外部实体（XXE）注入 | 禁用外部实体处理 |
| 访问控制失效 | 每个请求均在服务器端检查权限 |
| 安全配置错误 | 禁用默认配置，使用强化后的配置，生产环境不启用调试模式 |
| 跨站脚本（XSS） | 输出编码、配置CSP头部、清理HTML内容 |
| 不安全的反序列化 | 验证并类型检查所有序列化数据 |
| 已知漏洞依赖 | 使用 |
| 日志记录不足 | 记录身份验证事件、访问拒绝、输入验证失败情况 |
HIPAA Compliance (Health-Tech)
HIPAA合规（医疗科技领域）
Required if handling PHI (Protected Health Information):
| Requirement | Implementation |
|---|---|
| Encryption at rest | AES-256 for databases and file storage |
| Encryption in transit | TLS 1.2+ everywhere |
| Access controls | Role-based, audit-logged, least privilege |
| Audit trail | Every PHI access logged with who, what, when |
| BAA | Business Associate Agreement with every vendor touching PHI |
| Data minimization | Collect only what's clinically necessary |
| Breach notification | 60-day notification requirement — have a plan |
| Employee training | Annual security awareness training |
PHI includes: Names, dates, phone numbers, emails, SSN, medical record numbers, device IDs, biometric data, photos, and any data that could identify a patient.
Vendor checklist:
- Does your cloud provider sign BAAs? (AWS, GCP, Azure: yes. Many others: no.)
- Does your analytics tool see PHI? If yes, need BAA or strip PHI first.
- Does your error tracking capture PHI in stack traces? Strip it.
处理受保护健康信息（PHI）时必须满足以下要求：
| 要求 | 实现方式 |
|---|---|
| 静态数据加密 | 数据库和文件存储采用AES-256加密 |
| 传输数据加密 | 全域启用TLS 1.2+ |
| 访问控制 | 基于角色的访问控制、审计日志、最小权限原则 |
| 审计跟踪 | 记录所有PHI访问的人员、内容和时间 |
| 业务关联协议（BAA） | 与所有接触PHI的供应商签订BAA |
| 数据最小化 | 仅收集临床必需的数据 |
| breach通知 | 需在60天内通知相关方——提前制定预案 |
| 员工培训 | 年度安全意识培训 |
**PHI包括：**姓名、日期、电话号码、电子邮件、社保号码、病历号、设备ID、生物特征数据、照片，以及任何可识别患者身份的数据。
供应商检查清单：
- 你的云服务商是否签署BAA？（AWS、GCP、Azure：是。其他多数服务商：否。）
- 你的分析工具是否会接触PHI？如果是，需签订BAA或先剥离PHI。
- 你的错误跟踪工具是否会在堆栈跟踪中捕获PHI？需剥离此类数据。
SOC 2 Basics
SOC 2 基础
| Trust Principle | What to Implement |
|---|---|
| Security | Access controls, encryption, firewalls, IDS |
| Availability | Uptime monitoring, incident response, backups |
| Processing Integrity | Input validation, error handling, QA |
| Confidentiality | Encryption, access logging, data classification |
| Privacy | Consent, data retention, deletion, privacy policy |
Start with: Security + Availability. Add others when customers require it.
| 信任原则 | 需实现的内容 |
|---|---|
| 安全性 | 访问控制、加密、防火墙、入侵检测系统（IDS） |
| 可用性 | uptime监控、事件响应、备份 |
| 处理完整性 | 输入验证、错误处理、质量保证 |
| 保密性 | 加密、访问日志、数据分类 |
| 隐私性 | 同意机制、数据保留、删除、隐私政策 |
**起步建议：**先实现安全性+可用性。当客户有需求时再添加其他原则。
Security Review Checklist
安全审查清单
When reviewing code for security:
- Auth on every endpoint? — Not just the route, but the data query too
- Input validated at boundary? — Zod/Pydantic before any processing
- Secrets in env vars? — Never in code, git, or client bundles
- SQL parameterized? — No string concatenation, no template literals
- Error messages safe? — No stack traces, no internal paths to users
- Deps up to date? — /
npm auditcleanpip audit - Logging sufficient? — Auth events, permission failures, anomalies
- Data minimized? — Only collecting what's needed, only retaining as long as required
审查代码安全性时需检查：
- 每个端点都有身份验证吗？——不仅是路由，数据查询也需要
- 边界处是否验证输入？——在任何处理前使用Zod/Pydantic验证
- 密钥是否存储在环境变量中？——绝不要存放在代码、git或客户端包中
- SQL是否参数化？——不使用字符串拼接，不使用模板字面量
- 错误信息是否安全？——不向用户暴露堆栈跟踪、内部路径
- 依赖是否为最新版本？——/
npm audit无风险提示pip audit - 日志是否充分？——记录身份验证事件、权限失败、异常情况
- 数据是否最小化？——仅收集所需数据，仅保留必要时长