一个应用必须完成预期的多种需求，主要包括功能性需求(即应该做什么，比如各种存储、检索、搜索和处理数据)和一些非功能性需求(如性能、安全、可靠性、合规性、可伸缩性、兼容性、可维护性，等)。本章我们着重梳理讨论下安全。
安全概述
安全是指系统或软件保护信息和数据的能力，使个人或其他产品拥有与其授权类型和级别相适应的数据访问权限，并抵御恶意行为者的攻击模式。注意：除产品或系统中存储的数据或由产品或系统存储的外部数据，安全还适用于传输中的数据。高安全性的系统或软件，在以下方面表现出极大的优势：
(1) 保护数据及隐私，保障数据可信
高安全性的系统能有效防止数据泄露、篡改和丢失，保护用户的个人信息和企业商业机密，避免造成不可弥补的损失。避免数据被篡改（Security）或意外损坏（Safety），确保业务决策依据真实可靠（如金融交易记录、医疗诊断数据）。
(2) 防止系统被攻击和破坏
安全性高能够让系统抵御各种网络攻击（如黑客入侵、病毒植入、拒绝服务攻击等），保证系统的正常运行和业务连续性，避免服务中断和故障造成的经济损失。
(3) 遵守法律法规和行业标准
许多行业（如金融、医疗、政务等）对系统安全有强制合规要求。高安全性能够帮助企业符合相关法律法规，避免因违法违规而被处罚或被收回许可。
Security和Safety
在学习系统或软件的安全时，要严格区分Security和Safety。尽管Security和Safety都可翻译成安全，但两个特性的关注点不同。
Security指产品保护信息和数据的能力，使个人或其他产品拥有与其授权类型和级别相适应的数据访问权限，并抵御恶意行为者的攻击模式。如确保只有获得授权的人才能访问数据的能力(保密性:confidentiality)、不会因恶意行为或计算机错误而被擅自修改或删除的能力(完整性:integrity)、在受到恶意攻击时维持运行的能力，如恶意攻击可包括拒绝服务攻击、勒索软件攻击或其他恶意行为(耐受性:resistance)。
Safety指产品在规定条件下避免危及人的生命、健康、财产或环境的能力。在本文中，"Safety"被定义为描述产品能够避免不可容忍的暴露的能力。注意，该定义不同于其他有关safety的标准，后者将safety定义为免于不可接受的风险。如产品对操作或内部控制不可接受的风险发出警告的能力，使其能够在足够的时间内作出反应，以维持安全操作(危险警告:hazard warning)、产品识别可能使生命、财产或环境面临不可接受风险的事件或操作过程的能力(风险识别:risk identification）。
由此可见，Security关注的是抵御恶意攻击或非法访问，保护系统免受外部或内部威胁，其核心目标是防止数据泄露、篡改、服务中断等。而Safety关注的是功能安全，当系统在故障或异常情况下能否避免对人员、环境或设备造成危害，其核心目标是防止非故意的系统失效导致的灾难。
安全定义
在ISO/IEC-25019:2023标准中，对安全进行了如下定义：安全(Security)是指产品保护信息和数据的能力，使个人或其他产品拥有与其授权类型和级别相适应的数据访问权限，并抵御恶意行为者的攻击模式。
安全组成
在ISO/IEC 25019:2023标准中，安全由保密性（confidentiality）、完整性（integrity）、抗抵赖性（non-repudiation）、 可核查性（accountability）、真实性（authenticity）组成。
(1) 保密性（confidentiality）。产品确保只有获得授权的人才能访问数据的能力。
(2) 完整性（integrity）。产品确保其系统和数据状态不会因恶意行为或计算机错误而被擅自修改或删除的能力。
(3) 抗抵赖性（non-repudiation）。产品证明行动或事件已经发生的能力，使事件或行动事后无法推翻。
(4) 可核查性（accountability）。产品使实体的行为能被唯一地追踪到该实体的能力。
(5) 真实性（authenticity）。产品证明主体或资源的身份与所声称的身份一致的能力。
(6) 耐受性（resistance）。产品在受到恶意攻击时维持运行的能力： 恶意攻击可包括拒绝服务攻击、勒索软件攻击或其他恶意行为。注意，可以采用以下方法来提高产品耐受性：
(a) 使用安全工具，如安全诊断工具、漏洞扫描仪和静态分析工具，消除产品的潜在缺陷或弱点，从而不断保护自己免受众所周知的攻击；
(b) 通过安全软件编码、加入安全增强功能或机制，最大限度地降低产品的脆弱性；
© 出于安全考虑，在产品生命周期内保持产品更新。
安全度量
针对系统或软件安全，没有统一的方法论，相对来说，安全只能相对量化，不能绝对。零风险是不存在的。安全指标应结合系统场景、行业标准和业务实际定制。
系统和软件安全虽然很难完全"量化"，但业界常用安全漏洞数及风险等级、合规审查(ISO、等保)等作为核心可量化指标，可以根据具体业务场景选择适合的指标，建立持续的数据统计和监控机制，动态评估和提升安全水平。
安全编码规范
准则1：身份认证与会话管理
● 身份认证和权限控制逻辑在后端实现，防止前端绕过。
● Session ID难以预测，且在HTTPS下传输。
准则2：权限校验
● 对每个资源访问点实施权限校验，防止越权访问。
● 前后端均需做校验，服务器端为主。
准则3：关键操作记录日志
● 针对核心对象的处理，需要记录操作日志。
● 针对安全类操作，需要记录安全日志。
准则4：敏感信息保护
● 密码要加密存储，不可明文（建议使用盐值+哈希，如bcrypt, scrypt）。
● 用户敏感数据禁止直接展示，必须对展示数据进行脱敏。 如中国大陆个人手机号码显示为:137****0969，隐藏中间4位，防止隐私泄露。
准则5：输入有效性校验
● 所有外部输入都要进行严格校验，拒绝非法数据。
● 使用白名单校验优于黑名单。
● 不要信任客户端输入，所有数据（如表单、URL参数、文件、HTTP头等）都需验证。
● page size过大导致内存溢出。
准则6：错误处理与日志
● 不向用户泄露堆栈、敏感路径等详细系统错误信息。
● 日志中不能记录敏感信息（如密码、银行卡号等）。
● 捕获异常并妥善处理，防止"程序崩溃=信息泄露"。
准则7：外部依赖管理
● 及时跟踪并升级第三方库和框架，避免使用有已知高危漏洞的依赖。
准则8：针对常见漏洞，建立稳态处理规范
● 针对注入攻击，不使用用户输入拼接SQL(SQL注入)、隔离上传文件(脚本注入)
● 正则输入拒绝服务ReDoS 说明：Java代码用正则来验证客户端的输入，有些正则写法验证普通用户输入没有问题，但是如果攻击人员使用的是特殊构造的字符串来验证，有可能导致死循环的结果。
● 表单、AJAX提交必须执行CSRF安全验证。 说明：CSRF(Cross-site request forgery)跨站请求伪造是一类常见编程漏洞。对于存在CSRF漏洞的应用/网站，攻击者可以事先构造好URL，只要受害者用户一访问，后台便在用户不知情的情况下对数据库中用户参数进行相应修改。
● 在使用平台资源，譬如短信、邮件、电话、下单、支付，必须实现正确的防重放的机制，如数量限制、疲劳度控制、验证码校验，避免被滥刷而导致资损。 说明：如注册时发送验证码到手机，如果没有限制次数和频率，那么可以利用此功能骚扰到其它用户，并造成短信平台资源浪费。
参考
https://courage007.blog.csdn.net/article/details/145972296 系统或软件的可靠性(Reliability)
阿里巴巴Java开发手册（华山版）
各种大模型，如DeepSeek、Qwen、Chatgpt、GLM等