由 dawei 构建网站时，安全不应是上线前的补救措施，而应是贯穿选型与设计全程的核心基因。框架的选择，本质上是安全责任的前置分配。
AI渲染图，仅供参考
优先选用经过长期社区检验、具备活跃安全维护团队的成熟框架。例如，Django 内置 CSRF 防护、SQL 注入过滤、密码哈希机制；Rails 默认启用参数过滤与内容安全策略（CSP）支持；Express 则需配合 Helmet、csurf（已归档，推荐替代方案如 csrf-csrf 或基于 SameSite Cookie 的现代防护）等中间件补齐能力。切忌为追求新颖而采用未经验证的小众框架，其安全边界往往模糊且响应迟缓。
设计阶段须贯彻“最小权限”原则：后端 API 默认拒绝所有未明确声明的请求方法与字段；数据库连接使用低权限账号，禁用 root 或 admin 权限；静态资源独立部署于无执行权限的 CDN 或 Nginx 目录下，杜绝上传文件解析漏洞。
输入即威胁，输出即信标。所有用户输入（含 URL 参数、表单、Header、Cookie）必须进行白名单校验与上下文敏感转义——前端提交前做基础格式限制，服务端执行不可绕过的深度校验。模板渲染严格区分数据与逻辑，禁止拼接 HTML 字符串；JSON 接口返回前自动剥离敏感字段（如 password、token），避免因开发疏忽导致信息泄露。
HTTPS 不是可选项，而是强制基线。从首字节起全程加密，配置 HSTS 头防止降级攻击；Cookie 设置 Secure、HttpOnly 与 SameSite=Strict（或 Lax）属性，阻断窃取与 CSRF 漏洞路径。同时禁用服务器指纹头（如 X-Powered-By），减少攻击面暴露。
自动化是可持续安全的保障。CI/CD 流程中嵌入 SCA（软件成分分析）扫描依赖库漏洞，集成 SAST 工具检测硬编码密钥、不安全函数调用；生产环境启用 WAF（如 ModSecurity）作为纵深防御缓冲层，但绝不依赖其替代代码级防护。
安全不是功能列表里的复选框，而是每次技术决策背后的默认假设：假设输入恶意、假设依赖有缺陷、假设网络被监听。唯有将安全意识内化为设计直觉，框架才能真正成为盾，而非幻觉中的矛。