尧图网页设计 
ECC 仓库 Swift 安全规范实战密钥管理、传输安全与输入验证的完整落地指南【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本指南以 ECC 仓库中的 docs/ja-JP/rules/swift/security.md英文原文见 rules/swift/security.md为骨架结合通用安全基线 rules/common/security.md 与安全审查 Agent agents/security-reviewer.md 的源码级证据系统讲解 Swift 代码库中必须落实的三大安全主题机密数据管理、传输层安全与输入验证。读完本文你将能够在 ECC 的项目规则框架下写出不泄密、防注入、可审计的 Swift 代码并知道如何在提交前借助仓库内置工具完成安全自查。ECCThe agent harness performance optimization system将语言相关的工程规范以分层规则文件的形式沉淀在仓库中rules/common/保存与语言无关的通用约束rules/swift/则在通用约束之上叠加 Swift 特有内容并通过 YAML frontmatter 声明这些规则生效的路径范围。其中security.md是每个 Swift 文件**/*.swift与**/Package.swift都必须遵守的安全底线。规则文件的结构与作用域rules/swift/security.md的开头通过 frontmatter 声明了规则的适用路径--- paths: - **/*.swift - **/Package.swift ---这意味着凡是以.swift结尾的源文件以及 Swift 包清单文件Package.swift都属于该安全规则的管辖范围。文件正文第一句就点明了它与通用规则的关系此文件以 Swift 特有内容扩展 common/security.md。也就是说Swift 安全规则的完整语义 通用安全指南所有语言通用 Swift 特有补充本文主题。因此在使用时不能只读 Swift 规则还要把通用基线中的“提交前必须检查”清单一并纳入考量通用清单包括无硬编码机密API 密钥、密码、令牌所有用户输入均经过验证SQL 注入防护参数化查询XSS 防护HTML 消毒CSRF 保护已启用认证/授权已验证所有端点均有速率限制错误消息不泄露敏感数据Swift 规则正是在这一基线上针对 Apple 平台与 Swift 语言的特性做了三项关键补充。一、机密数据管理用 Keychain 而非 UserDefaultsSwift 规则对机密数据token、密码、密钥的第一条铁律是必须使用 Keychain Services绝不使用UserDefaults。这一约束背后是两者的本质差异UserDefaults以明文 plist 形式存储于应用沙盒内任何获得设备访问权或通过备份提取数据的人都能直接读取而 Keychain Services 由操作系统负责加密存储并受到设备级安全机制如 iOS 的 Secure Enclave保护是 Apple 平台上存放凭据的标准方案。凡涉及账号密码、刷新令牌、API 密钥等持久化场景都应通过SecItemAdd/SecItemCopyMatching/SecItemUpdate/SecItemDelete这组 API 或封装它们的库来读写。第二条铁律针对构建期build-time机密使用环境变量或.xcconfig文件而不是写死在源码里。.xcconfig是 Xcode 的配置描述文件可配合$(VAR)替换在构建设置中注入值并建议将真实的.xcconfig排除出版本控制仅提交不含机密的模板。第三条铁律解释了“为什么绝不能硬编码”反编译工具可以轻而易举地提取源码中的字符串字面量。即使代码经过编译、混淆字符串常量依然以可读形式存在于二进制中攻击者用strings之类的工具即可扫描出密钥。规则给出了一个在应用启动时读取并校验密钥的参考实现let apiKey ProcessInfo.processInfo.environment[API_KEY] guard let apiKey, !apiKey.isEmpty else { fatalError(API_KEY not configured) }这段代码的要点有三个一是通过ProcessInfo.processInfo.environment从进程环境读取确保机密不落盘于源码二是利用 Swift 的 optional bindingguard let apiKey解包三是启动即失败fail fast——缺少密钥时直接fatalError避免应用带着缺失的配置运行到真正调用网络请求时才崩溃。这与通用安全基线中“启动时验证必需机密是否存在”的要求完全一致。补充说明guard let apiKey, !apiKey.isEmpty是 Swift 5.7 支持的 shorthand optional binding 写法在同一guard中同时完成解包与空值校验。示例中在进程退出前直接终止的做法适用于 CLI 工具、测试夹具或服务端 Swift 程序在 iOS/macOS 客户端中更稳妥的做法是向用户呈现错误状态并优雅降级而不是直接崩溃具体取舍应与 rules/swift/patterns.md 中“结构化错误处理”的约定保持一致。二、传输安全ATS、证书固定与证书验证Swift 规则在传输层给出三条约束App Transport SecurityATS默认强制开启不要禁用。ATS 是 Apple 平台自 iOS 9 / macOS 10.11 起默认生效的机制强制所有URLSession请求使用 HTTPS 并满足最低 TLS 版本与密码套件要求。绕过它的唯一方式是编辑Info.plist中的NSAppTransportSecurity例外项——规则明确禁止这样做。即使是开发期的临时 http 端点也应尽量通过本地回环例外或受控的白名单处理而不是全局关闭 ATS。对关键端点使用证书固定certificate pinning。仅依赖系统信任链仍可能受到受信 CA 签发的中间人证书威胁对支付、鉴权等关键端点应在客户端内置服务端证书的公钥或 SPKI 指纹并在URLSessionDelegate的urlSession(_:didReceive:completionHandler:)中做比对拒绝与固定值不匹配的连接。验证所有服务器证书。默认实现下URLSession会做系统级证书校验但若出于测试目的自定义了ServerTrustEvaluator或实现URLSessionDelegate的信任回调就必须手动完成证书链、有效期、主机名三项校验绝不能无条件放行。这三条共同构成纵深防御ATS 保证“必须走 HTTPS”证书固定保证“即使 HTTPS 也要认准服务端身份”证书验证保证“每次握手都重新核实身份”。通用基线中“Sensitive Data — HTTPS enforced?”的检查项在 Swift 侧的落点正是本小节。三、输入验证消毒、安全构造 URL、警惕外部数据源Swift 规则把输入验证拆成三个具体动作1. 展示前消毒所有用户输入防止注入。无论数据来自表单、URL 参数还是剪贴板在渲染到 UI如Text、WKWebView、NSAttributedString之前都必须清洗防止 XSS 与富文本注入。对于 WebView 场景尤其严格因为 Swift 代码与 JS 的桥接WKScriptMessageHandler可能成为注入通道。2. 使用带验证的URL(string:)而不是强制解包。规则给出的反例是URL(string: rawString)!这类强制解包写法——一旦传入非法字符串含空格、非法字符、畸形 scheme运行时就会崩溃。正确做法是先校验再使用guard let url URL(string: userInput), let scheme url.scheme, [https, http].contains(scheme) else { // 拒绝非法或非预期协议的输入 return }从源码结构看ECC 的安全审查 Agent 在 agents/security-reviewer.md 中把“fetch(userProvidedUrl)→ 白名单允许的域名”标记为 HIGH 级问题这一思路同样适用于 Swift即使URL(string:)校验通过也应进一步把主机名限定在白名单内防范 SSRF 与开放重定向。3. 处理外部数据源之前先验证。规则明确点名的三类外部来源是API 响应、深度链接deep link、粘贴板pasteboard。深度链接尤其值得警惕——恶意 App 可以构造带参数的 URL 唤起你的应用若直接信任其中的参数去做导航、执行动作或拼接请求就可能导致任意操作粘贴板数据同样可能被其他 App 恶意写入。统一的做法是为这三类数据定义严格的 DTO 与校验器先解码、校验类型与取值范围再进入业务逻辑。四、在 ECC 中落地安全审查 Agent 与提交前检查ECC 将上述规则与 security-reviewer Agent 打通形成“规则约束 → Agent 审查 → 提交前自查”的完整闭环。该 Agent 的核心职责包括检测 OWASP Top 10 漏洞、发现硬编码密钥、校验输入消毒、核对认证/授权、检查依赖安全并维护了一张高风险代码模式表。其中与 Swift 安全规则直接对应的审查模式包括模式严重级别修复方式硬编码机密CRITICAL改用环境变量或 Keychain使用用户输入构造 URLHIGH白名单允许的域名明文密码比较CRITICAL使用安全哈希比对记录密码/机密到日志MEDIUM消毒日志输出Agent 还提示了常见误报场景值得在自查时参考.env.example中的环境变量占位符非真实机密、测试文件中明确标注的测试凭据、本意就是公开的 API Key 等均不应误报为漏洞——“Always verify context before flagging.”当安全规则被触发时通用基线 rules/common/security.md 规定了响应协议立即停止当前工作 → 使用 security-reviewer Agent → 继续前先修复 CRITICAL 问题 → 轮换可能已暴露的机密 → 在整个代码库中排查同类问题。这套协议与 Swift 规则中“不硬编码、及时轮换”的条目互为表里。五、与 Swift 工程实践的协同Swift 安全规则并非孤立存在它与同目录下的其他规则共同构成完整的工程约束使用时建议联动阅读rules/swift/patterns.md推荐用actor管理共享可变状态、用Sendable值类型跨越隔离边界——这直接关系到并发场景下共享密钥/会话状态时能否安全传递而不被竞态条件破坏rules/swift/coding-style.md要求优先let、使用带类型化错误的throws(LoadError)模式——错误处理若写得粗糙如吞掉错误、打印完整堆栈就可能违反通用基线中“错误消息不泄露敏感数据”的要求rules/swift/hooks.md 与 rules/swift/testing.md可将“无硬编码机密、输入均已验证”等检查项固化到提交前钩子与测试夹具中把安全规则从“人读”升级为“机器强制”。小结ECC 仓库的 Swift 安全规则虽然精炼但每一行都对应着可执行的工程动作机密一律进 Keychain 或环境变量ProcessInfo.processInfo.environment构建期配置走.xcconfig传输层依赖 ATS 默认强制并叠加证书固定与证书校验输入侧先消毒、用带校验的URL(string:)、对外部来源数据先验证再处理。将这三组动作与 rules/common/security.md 的提交前清单、security-reviewer Agent 的审查流程配合使用即可在 ECC 的 Swift 代码库中建立可复制、可审计、可自动化的安全防线。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ECC 仓库 Swift 安全规范实战：密钥管理、传输安全与输入验证的完整落地指南
ECC 仓库 Swift 安全规范实战密钥管理、传输安全与输入验证的完整落地指南【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本指南以 ECC 仓库中的 docs/ja-JP/rules/swift/security.md英文原文见 rules/swift/security.md为骨架结合通用安全基线 rules/common/security.md 与安全审查 Agent agents/security-reviewer.md 的源码级证据系统讲解 Swift 代码库中必须落实的三大安全主题机密数据管理、传输层安全与输入验证。读完本文你将能够在 ECC 的项目规则框架下写出不泄密、防注入、可审计的 Swift 代码并知道如何在提交前借助仓库内置工具完成安全自查。ECCThe agent harness performance optimization system将语言相关的工程规范以分层规则文件的形式沉淀在仓库中rules/common/保存与语言无关的通用约束rules/swift/则在通用约束之上叠加 Swift 特有内容并通过 YAML frontmatter 声明这些规则生效的路径范围。其中security.md是每个 Swift 文件**/*.swift与**/Package.swift都必须遵守的安全底线。规则文件的结构与作用域rules/swift/security.md的开头通过 frontmatter 声明了规则的适用路径--- paths: - **/*.swift - **/Package.swift ---这意味着凡是以.swift结尾的源文件以及 Swift 包清单文件Package.swift都属于该安全规则的管辖范围。文件正文第一句就点明了它与通用规则的关系此文件以 Swift 特有内容扩展 common/security.md。也就是说Swift 安全规则的完整语义 通用安全指南所有语言通用 Swift 特有补充本文主题。因此在使用时不能只读 Swift 规则还要把通用基线中的“提交前必须检查”清单一并纳入考量通用清单包括无硬编码机密API 密钥、密码、令牌所有用户输入均经过验证SQL 注入防护参数化查询XSS 防护HTML 消毒CSRF 保护已启用认证/授权已验证所有端点均有速率限制错误消息不泄露敏感数据Swift 规则正是在这一基线上针对 Apple 平台与 Swift 语言的特性做了三项关键补充。一、机密数据管理用 Keychain 而非 UserDefaultsSwift 规则对机密数据token、密码、密钥的第一条铁律是必须使用 Keychain Services绝不使用UserDefaults。这一约束背后是两者的本质差异UserDefaults以明文 plist 形式存储于应用沙盒内任何获得设备访问权或通过备份提取数据的人都能直接读取而 Keychain Services 由操作系统负责加密存储并受到设备级安全机制如 iOS 的 Secure Enclave保护是 Apple 平台上存放凭据的标准方案。凡涉及账号密码、刷新令牌、API 密钥等持久化场景都应通过SecItemAdd/SecItemCopyMatching/SecItemUpdate/SecItemDelete这组 API 或封装它们的库来读写。第二条铁律针对构建期build-time机密使用环境变量或.xcconfig文件而不是写死在源码里。.xcconfig是 Xcode 的配置描述文件可配合$(VAR)替换在构建设置中注入值并建议将真实的.xcconfig排除出版本控制仅提交不含机密的模板。第三条铁律解释了“为什么绝不能硬编码”反编译工具可以轻而易举地提取源码中的字符串字面量。即使代码经过编译、混淆字符串常量依然以可读形式存在于二进制中攻击者用strings之类的工具即可扫描出密钥。规则给出了一个在应用启动时读取并校验密钥的参考实现let apiKey ProcessInfo.processInfo.environment[API_KEY] guard let apiKey, !apiKey.isEmpty else { fatalError(API_KEY not configured) }这段代码的要点有三个一是通过ProcessInfo.processInfo.environment从进程环境读取确保机密不落盘于源码二是利用 Swift 的 optional bindingguard let apiKey解包三是启动即失败fail fast——缺少密钥时直接fatalError避免应用带着缺失的配置运行到真正调用网络请求时才崩溃。这与通用安全基线中“启动时验证必需机密是否存在”的要求完全一致。补充说明guard let apiKey, !apiKey.isEmpty是 Swift 5.7 支持的 shorthand optional binding 写法在同一guard中同时完成解包与空值校验。示例中在进程退出前直接终止的做法适用于 CLI 工具、测试夹具或服务端 Swift 程序在 iOS/macOS 客户端中更稳妥的做法是向用户呈现错误状态并优雅降级而不是直接崩溃具体取舍应与 rules/swift/patterns.md 中“结构化错误处理”的约定保持一致。二、传输安全ATS、证书固定与证书验证Swift 规则在传输层给出三条约束App Transport SecurityATS默认强制开启不要禁用。ATS 是 Apple 平台自 iOS 9 / macOS 10.11 起默认生效的机制强制所有URLSession请求使用 HTTPS 并满足最低 TLS 版本与密码套件要求。绕过它的唯一方式是编辑Info.plist中的NSAppTransportSecurity例外项——规则明确禁止这样做。即使是开发期的临时 http 端点也应尽量通过本地回环例外或受控的白名单处理而不是全局关闭 ATS。对关键端点使用证书固定certificate pinning。仅依赖系统信任链仍可能受到受信 CA 签发的中间人证书威胁对支付、鉴权等关键端点应在客户端内置服务端证书的公钥或 SPKI 指纹并在URLSessionDelegate的urlSession(_:didReceive:completionHandler:)中做比对拒绝与固定值不匹配的连接。验证所有服务器证书。默认实现下URLSession会做系统级证书校验但若出于测试目的自定义了ServerTrustEvaluator或实现URLSessionDelegate的信任回调就必须手动完成证书链、有效期、主机名三项校验绝不能无条件放行。这三条共同构成纵深防御ATS 保证“必须走 HTTPS”证书固定保证“即使 HTTPS 也要认准服务端身份”证书验证保证“每次握手都重新核实身份”。通用基线中“Sensitive Data — HTTPS enforced?”的检查项在 Swift 侧的落点正是本小节。三、输入验证消毒、安全构造 URL、警惕外部数据源Swift 规则把输入验证拆成三个具体动作1. 展示前消毒所有用户输入防止注入。无论数据来自表单、URL 参数还是剪贴板在渲染到 UI如Text、WKWebView、NSAttributedString之前都必须清洗防止 XSS 与富文本注入。对于 WebView 场景尤其严格因为 Swift 代码与 JS 的桥接WKScriptMessageHandler可能成为注入通道。2. 使用带验证的URL(string:)而不是强制解包。规则给出的反例是URL(string: rawString)!这类强制解包写法——一旦传入非法字符串含空格、非法字符、畸形 scheme运行时就会崩溃。正确做法是先校验再使用guard let url URL(string: userInput), let scheme url.scheme, [https, http].contains(scheme) else { // 拒绝非法或非预期协议的输入 return }从源码结构看ECC 的安全审查 Agent 在 agents/security-reviewer.md 中把“fetch(userProvidedUrl)→ 白名单允许的域名”标记为 HIGH 级问题这一思路同样适用于 Swift即使URL(string:)校验通过也应进一步把主机名限定在白名单内防范 SSRF 与开放重定向。3. 处理外部数据源之前先验证。规则明确点名的三类外部来源是API 响应、深度链接deep link、粘贴板pasteboard。深度链接尤其值得警惕——恶意 App 可以构造带参数的 URL 唤起你的应用若直接信任其中的参数去做导航、执行动作或拼接请求就可能导致任意操作粘贴板数据同样可能被其他 App 恶意写入。统一的做法是为这三类数据定义严格的 DTO 与校验器先解码、校验类型与取值范围再进入业务逻辑。四、在 ECC 中落地安全审查 Agent 与提交前检查ECC 将上述规则与 security-reviewer Agent 打通形成“规则约束 → Agent 审查 → 提交前自查”的完整闭环。该 Agent 的核心职责包括检测 OWASP Top 10 漏洞、发现硬编码密钥、校验输入消毒、核对认证/授权、检查依赖安全并维护了一张高风险代码模式表。其中与 Swift 安全规则直接对应的审查模式包括模式严重级别修复方式硬编码机密CRITICAL改用环境变量或 Keychain使用用户输入构造 URLHIGH白名单允许的域名明文密码比较CRITICAL使用安全哈希比对记录密码/机密到日志MEDIUM消毒日志输出Agent 还提示了常见误报场景值得在自查时参考.env.example中的环境变量占位符非真实机密、测试文件中明确标注的测试凭据、本意就是公开的 API Key 等均不应误报为漏洞——“Always verify context before flagging.”当安全规则被触发时通用基线 rules/common/security.md 规定了响应协议立即停止当前工作 → 使用 security-reviewer Agent → 继续前先修复 CRITICAL 问题 → 轮换可能已暴露的机密 → 在整个代码库中排查同类问题。这套协议与 Swift 规则中“不硬编码、及时轮换”的条目互为表里。五、与 Swift 工程实践的协同Swift 安全规则并非孤立存在它与同目录下的其他规则共同构成完整的工程约束使用时建议联动阅读rules/swift/patterns.md推荐用actor管理共享可变状态、用Sendable值类型跨越隔离边界——这直接关系到并发场景下共享密钥/会话状态时能否安全传递而不被竞态条件破坏rules/swift/coding-style.md要求优先let、使用带类型化错误的throws(LoadError)模式——错误处理若写得粗糙如吞掉错误、打印完整堆栈就可能违反通用基线中“错误消息不泄露敏感数据”的要求rules/swift/hooks.md 与 rules/swift/testing.md可将“无硬编码机密、输入均已验证”等检查项固化到提交前钩子与测试夹具中把安全规则从“人读”升级为“机器强制”。小结ECC 仓库的 Swift 安全规则虽然精炼但每一行都对应着可执行的工程动作机密一律进 Keychain 或环境变量ProcessInfo.processInfo.environment构建期配置走.xcconfig传输层依赖 ATS 默认强制并叠加证书固定与证书校验输入侧先消毒、用带校验的URL(string:)、对外部来源数据先验证再处理。将这三组动作与 rules/common/security.md 的提交前清单、security-reviewer Agent 的审查流程配合使用即可在 ECC 的 Swift 代码库中建立可复制、可审计、可自动化的安全防线。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考