你有没有遇到过这样的情况？花了几周时间写好的程序，刚上线没几天就被爆出安全问题，用户数据差点被偷走。一查原因，竟然是因为一段漏掉的输入验证。这其实就是典型的源代码漏洞，看似不起眼，却可能成为黑客突破的入口。
常见的源代码漏洞长什么样
很多漏洞并不是什么高深的技术难题，反而是开发时的一些“习惯性忽略”。比如最常见的 SQL 注入，就是程序员图省事，直接把用户输入拼接到数据库查询语句里。
String query = "SELECT * FROM users WHERE name = '" + userName + "'";只要用户输入一个 ' OR '1'='1，就能绕过登录。这种写法在早些年的项目里太常见了，现在虽然大家都知道要用预编译，但老旧系统或者赶工期的项目里还是时不时能挖出这类问题。
跨站脚本（XSS）也是重灾区
用户提交的内容直接输出到页面，不做任何转义，结果别人贴一段 <script>alert('hacked')</script> 就能执行。更危险的是，这段脚本可能偷偷收集你的 Cookie，传到别人的服务器上。
<div>欢迎你，<%= userInput %></div>正确的做法是把用户输入里的特殊字符转义，比如 < 变成 <，> 变成 >，这样浏览器就不会当成标签解析。
修复不是改完就完事
改完代码只是第一步。得确认这个漏洞是不是在别的地方也存在。比如今天修了一个 SQL 拼接的问题，就得用工具扫一遍整个项目，看看还有没有类似的写法。很多团队会用 SonarQube 这类静态分析工具，在提交代码时自动检查已知的漏洞模式。
另外，补丁发布后还得盯着日志看。有没有异常请求突然增多？有没有用户反馈登录异常？有时候黑客已经进来了，只是还没动作，监控到位才能及时止损。
别等出事才想起修复
就像家里防盗，不能等到被撬了才装锁。开发阶段就要加入安全检查。写完功能代码，顺手想想：这里会不会被恶意输入利用？要不要加个长度限制？要不要过滤特殊字符？这些习惯比事后补救靠谱得多。
有些团队会在代码评审时专门列一条“安全项”，每个人都要过一遍。哪怕只是一个简单的表单提交，也要有人问一句：这地方防注入了吗？防刷了吗？权限校验做了吗？久而久之，安全意识就落地了。
源代码漏洞修复不是一次性的任务，而是贯穿整个开发周期的常态工作。一个小疏忽可能不会立刻出事，但只要一直留着，迟早会撞上懂行的人。