原则1 最小攻击面
在一些web安全防护建议中经常会提到“关闭不必要对外开放的端口”，这就是最小攻击面的一项措施。在网络攻击的生命周期中一个重要环节就是信息收集，这个环节往往也是黑客耗费时间精力最大的一个环节，对最终黑客的攻击成果起了至关重要的影响，越是有经验的黑客，会花更多的时间和精力在信息收集上面，这步做的好，后面就能一击命中。
当我们最小化攻击面这个安全原则做的好，就会大大影响黑客信息收集的成果，最终挫败黑客的攻击。
原则2 默认设置安全性
系统的默认配置带来的安全问题，比如早期一些路由器出厂默认的帐号是admin密码也是admin，使用默认帐号密码扫描类似的这些系统，当你扫描的基数逐渐增多时，一定会有意想不到的收获。
原则3 权限最小化
这也是很多人常犯的错误，一个root账号搞定所有系统，虽然维护方便了，但是当黑客攻破任意一个系统就直接拿到了最高权限。
原则4 纵深防御
不要把所有的精力只用在一点的防御上，一点防御的再强，也可能会出现0day漏洞，无法保证100%的安全。 层层设防，多样化，多层次、纵深的防御措施。攻破一层或一类防护后，无法破坏整个信息基础设施或应用系统。
比如：SQL注入攻击的直接原因是拼接SQL参数导致的，因此防止SQL注入攻击我们首先想到的就是SQL语句预编译的方法，除此之外部署WAF系统在外围首先进行拦截，数据库的敏感数据加密保存使得即便被黑客攻入，窃取出去的数据也无法还原出原始信息等多重防御方法结合使用，就是纵深防御。
原则5 失败安全
当异常发生时，异常处理代码处理不当，可以导致意想不到的问题，比如权限提升、信息泄露等。这也是不懂安全的开发人员经常忽视的，而在黑客攻击kill chain的信息收集阶段，又是被黑客经常利用的，黑客对攻击目标故意输错url参数或者路径、构造异常post数据，导致服务器出错，如果开发人员对这里的错误处理不当，就会导致敏感甚至重要的信息被泄露，为黑客的下一步攻击提供重要的线索和思路。这些都是在真实案例中见到过的。
另外，漏洞挖掘中的fuzz模糊测试，其实也是通过各种非常规数据的输入设法把程序给搞崩溃，进而发现可能存在的漏洞。
原则6 不信任第三方系统
现在的系统越来越复杂，很多都是模块化、组件化的，需要引入第三方的模块或者和第三方的业务系统对接并使用其提供的数据，我们无法掌控第三方系统的安全性，如果其存在漏洞被攻击，需要保证我们自己的系统不会因此而受到影响。这个威胁也排进了OWASP Top 10：“使用含有已知漏洞的组件”。
原则7 业务隔离
简单一句话就是不要把所有鸡蛋都放在一个篮子里，不至于一个系统被攻破就让黑客拿到了一把“万能钥匙”，可以操作所有的业务功能。
原则8 公开设计
如果是初次接触这个安全原则，可能会很难理解。通常会认为不要让我们的源代码泄露，更不能让加解密相关的重要源码泄露。但依据“公开设计”的安全原则，我们可以开放源代码后、我们的系统依然是安全的。一个典型相悖于“公开设计”原则的例子就是私有加密算法，误以为使用自己设计的加密算法更加安全。正确的做法是使用标准的RSA、AES等对称或非对称加密算法，我们数据的安全性不应该依赖于算法的保密性，而是确保加密密钥的安全，只要我们的密钥位数足够长，密钥不被泄露，那我们加密的数据就是安全的。 而在我接触到的真实黑客渗透中，黑客收集目标系统的信息，首先使用常规手段无法攻破系统后，如果这个系统因为是开源或者通过其他手段能拿到全部或者部分源码，经常黑客就会深入去研究系统的源代码，而常常能找到系统的漏洞或者突破口，进而发起进一步的攻击。这也是违反了“开放原则”。完全做到“开放设计”在实际中还不太多，也比较困难。但我们应该逐渐形成这样的意识，尽可能从保护源代码的思维转化为开放设计的思维 ，理想的目标就是做到把所有源代码开放给黑客，黑客也无法攻破系统。
原则9 简化系统设计
做安全不久后，以前一直有个疑问困扰着我，就是安全防御技术越来越强，防御手段越来越多，漏洞被不断发现和修补，是不是以后安全问题就越来越少，最终就能几乎消灭所有安全问题？ “简化系统设计”原则从侧面一定程度解答了这个疑问，随着信息技术、互联网技术的高速发展，系统功能变得强大的同时，系统也变得越来越复杂。越复杂的系统就越容易出现漏洞，特别像是逻辑漏洞这种，漏洞没有固定的模式、固定的特征，很难通过安全设备来防御。复杂度的提高通常也会导致攻击面变大。所以我们尽量简化系统设计，当有多种系统设计方案时，应该尽量选择最简单的那种方案。
原则10 使用白名单
与白名单相对的就是黑名单，白名单机制可能导致“误杀”，而黑名单机制可能导致“误放”。在平衡“误杀”与“误放”时，通常更倾向于“误杀”，因为一旦“误放”我们系统就被黑客攻破，而“误杀”带来的其他问题可以设计诸如手动添加白名单等机制来解决，同时白名单机制还有可能能够防御各种未发现的安全隐患。