你有没有过这样的经历？早上打开公司系统，登录页面突然提示“服务不可用”，刷新几次后跳转到一个奇怪的页面，甚至浏览器开始疯狂弹广告。这可能不是简单的卡顿，而是你正在使用的网络应用在架构层面出了问题，给了攻击者可乘之机。
技术栈不是越新越好
现在很多团队追求“高大上”的技术组合：前端用 React，后端是 Node.js，数据库选 MongoDB，部署上 Kubernetes 加 Docker。看起来很酷，但问题是，这些组件之间的安全边界常常被忽略。比如，Node.js 默认不会限制模块加载路径，如果配置不当，攻击者可能通过构造恶意请求读取服务器上的敏感文件。
再比如，React 虽然自带 XSS 防护，但如果开发者图省事，直接用 dangerouslySetInnerHTML 插入用户输入的内容，那再好的框架也救不了你。就像你装了防盗门，却把钥匙放在门口地毯下。
分层架构里的“信任陷阱”
典型的三层架构——前端、API 层、数据库——每一层都默认信任上游。前端传过来的数据，API 层照单全收；API 层发来的查询，数据库直接执行。这种“内部信任”模式，在真实网络环境中非常危险。
举个例子，某电商后台接口接收商品 ID 查询详情，代码写成：
const query = `SELECT * FROM products WHERE id = ${req.params.id}`;
db.query(query);只要攻击者把 ID 改成 1 OR 1=1，就能拖走整张表的数据。即使你用了 Express 这类主流框架，不加防护照样中招。
API 网关不是万能锁
不少团队以为上了 API 网关就安全了，其实不然。网关可以做限流、鉴权，但如果规则配置太松，比如允许任意来源的 CORS 请求，或者 JWT 校验没启用签名验证，等于大门敞开着还挂了个“欢迎光临”的牌子。
有家公司曾把测试环境的网关配置复制到生产环境，结果攻击者通过 OPTIONS 请求探测出所有接口路径，接着批量扫描漏洞，最终导致用户数据泄露。技术栈本身没问题，问题是人没管好配置。
日志和监控别只写进文档
很多项目都有“完善的监控体系”，可真出事时却查不到线索。原因往往是日志级别设成 info，错误细节被吞掉了；或者审计日志只记录成功请求，失败的登录尝试一律不存。
有个实际案例：某 SaaS 平台连续几天出现异常登录，但安全团队一直没收到告警，因为认证服务的日志被重定向到了 /dev/null —— 就为了“减少磁盘占用”。等发现时，攻击者已经用爬虫导出了上万条客户信息。
依赖管理不能靠侥幸
现代应用动辄几百个 npm 或 pip 依赖，没人能记住每个包的作用。但攻击者记得。去年流行的 event-stream 事件就是典型：一个被弃用的小众包被注入恶意代码，顺着依赖链感染了大量知名项目。
建议定期运行 npm audit 或 pip-audit，别看到一堆警告就 ignore。哪怕每天只修一个高危漏洞，也比堆砌新技术强。
技术栈本身没有对错，关键是怎么用。选型时多问一句：这个组件出事了，我能第一时间发现吗？能快速切断影响吗？比单纯追求性能和开发效率更重要。