安全是一个伪命题。

世界上没有绝对的安全，任何试图一劳永逸地解决安全问题的方案，结果都被证明只是一厢情愿。对安全研究越深入，则越有体会。即使如此，不代表我们就可以对安全置之不理。

各个领域对“安全”的定义林林总总，对于我印象最为深刻的一条则是：

当入侵系统所得的利益大于所付出的的代价时，则可认为该系统是安全的。

对于开发人员来说，我们的系统安全会发生在以下几个方面：

前端（浏览器）-后台（开发平台+框架）-数据库（DBMS）-操作系统（Linux/Mac/Win）- 社工（社会工程学）

如果要保障一个系统的安全，则要从以上各个方面制定一整套的安全应对方案，这是一个木桶效应，由短的木板决定所剩水的多少。

对于开发人员来说，我们要关注是的__前端__和__后台__的安全，__数据库__和__操作系统__的安全则由运维人员去保障，而__社工__面对的是安全系统中非常薄弱的一环：人 。当然，这远远超乎我的能力范围。

抛开__社会工程学__不谈，对于其他部分的安全保障，在实践工作中也是苦难重重。我们能做的，也只有祈祷我们编写的代码不会出现什么重大漏洞，同时在开发与部署过程中遵循一些可靠的原则，尽可能地降低安全事件发生的概率。

一个Web应用系统的交互大概如以下流程：

前端浏览器 -> Web容器（->操作系统） -> 后台系统（->操作系统） -> 数据库（->操作系统）

其实这是我硬塞的一条原则，类似与防御式编程。底层的接受者假设上层的调用者都是不可信的。

系统只授予必要的权限，避免不必要的授权，从而减少安全风险。在不信任原则下限制主体的权限范围，例如限定Web容器的权限，那么即使Apache或Struts2又被公布了某致命漏洞，也不至于我们显得过于被动。

安全方法渗透到不同层面，根据不信任原则，对不同层面制定不同的方案。

减少编程过程中产生的危险，例如SQL注入，XSS注入等等。

让攻击者难以对系统的敏感信息进行猜测、预测，从而提高入侵的门槛，例如TOKEN、MD5随机盐、UUID作为资源ID等等。

这是在制定过滤规则时应该遵循的原则，例如过滤IP、过滤XSS等过滤策略中。详见《白帽子讲Web安全》

• 《白帽子讲Web安全》