1. 课程导入与安全编码全景
安全编码不是“写代码时顺手注意一下”，而是一套贯穿需求、设计、实现、测试与运维的工程约束。它的核心目标可以概括为三点：让系统在正常输入下正确工作，在恶意输入下不产生越权、泄露或崩溃，在出现缺陷时能够被快速定位与修复。换句话说，安全编码追求的是“可预期的行为边界”——无论输入来自用户、网络、文件还是其他服务，程序都应当只做被授权的事。
把安全编码放回软件开发生命周期（SDLC）来看，它并不是测试阶段才介入的补丁。需求阶段要明确数据分类、合规要求与信任边界；设计阶段要确定认证、授权、加密与错误处理策略；实现阶段要落实输入校验、输出编码、参数化查询与最小权限；测试阶段要通过静态分析、动态测试与人工审计验证假设；运维阶段则依赖日志、监控与补丁管理维持安全状态。越早引入安全活动，修复成本越低——业界常引用的经验是：需求阶段修复缺陷的成本约为编码阶段的十分之一，而生产环境修复可能高出数十倍。这一数量级关系虽因项目而异，但方向是稳定的。
1. 所有外部输入都不可信，包括HTTP参数、请求头、文件内容、第三方接口返回；
2. 任何安全控制都可能在某个环节失效，因此需要纵深防御；
3. 权限必须显式授予，默认拒绝；
4. 错误信息不应泄露内部结构、路径、SQL或堆栈细节。
常见安全漏洞类型可以按“缺陷来源”来梳理，这样比死记清单更容易迁移。第一类是注入类，如SQL注入、命令注入、LDAP注入，根因是“把数据当成了代码或指令”。第二类是身份与访问控制类，如越权访问、会话固定、弱口令策略，根因是“信任了未经校验的身份或权限判断不完整”。第三类是数据暴露类，如敏感信息明文存储、日志打印密码、传输未加密，根因是“未对数据分级并施加相应保护”。第四类是逻辑与状态类，如竞态条件、支付金额篡改、验证码可复用，根因是“业务规则未在服务端强制校验”。第五类是组件与配置类，如使用含已知漏洞的依赖、调试接口未关闭、CORS配置过宽。OWASP Top 10 与 CWE 是两套常用的分类参考，前者偏风险场景，后者偏缺陷类型，实践中常结合使用。
下面这张图把“不可信输入—处理链—安全控制点—结果判定”串成一条信号链，帮助建立整体视角。图中每个控制点都对应后续章节会展开的具体技术。
工程实践与综合项目的整体流程，可以理解为把上述控制点落到一个可运行的系统里。一个典型的综合项目会包含：确定一个带用户、数据存储和外部接口的小型应用；画出数据流图并标注信任边界；针对每条跨越信任边界的数据流写出威胁与对策；在代码中实现输入校验、参数化查询、密码哈希、会话管理与访问控制；用静态扫描和手工测试验证；最后输出一份包含风险清单与修复记录的工程报告。这个过程不追求功能规模，而追求“每个安全决策都有依据、每个缺陷都有闭环”。
为了让后续章节有统一的参照，这里给出一个贯穿课程的最小示例场景：一个“课程作业提交系统”，学生登录后上传文件，教师查看并评分。它的信任边界至少有三处：浏览器到Web服务器、Web服务器到数据库、Web服务器到文件存储。示例参数可以设定为：用户名长度3–20字符，仅允许字母数字下划线；上传文件限制为PDF且不超过5MB；会话空闲超时30分钟；数据库连接使用最小权限账号，仅具备作业表的增删改查权限。这些参数是教学假设，实际项目应按业务与合规要求调整。
本课程后续将围绕这条信号链逐段展开：先讲输入校验与输出编码，再讲认证授权与数据保护，然后进入依赖管理与配置安全，最后通过综合项目把各控制点组装起来，并用测试与复盘验证效果。学习时建议始终带着一个具体系统来对照，把每个知识点映射到自己的代码或设计上，这样安全编码才会从“知道”变成“做到”。