MVC框架安全
MVC是Model-View-Controller的缩写，它将web应用分为三层，view层负责用户视图、页面展示等工作；controler负责应用的逻辑实现，接收view层传入的用户请求，并转发给对应的model做处理；model层负责实现模型，完成数据的处理。
从数据的流入来看，用户提交的数据先后流经了view层、controller、model层，数据的流出则是反过来。在设计安全方案时，要牢牢把握住数据这个关键因素。在MVC框架中，通过切片、过滤器等方式，往往能对数据进行全局处理，这为设计安全方案提供了极大的便利。
一些主要的web安全威胁，如XSS、CSRF、SQL注入、访问控制、认证、URL跳转等不涉及业务逻辑的安全问题，都可以集中放在MVC框架中解决。放在框架中统一解决，能够大大节省程序员的工作量，节约人力成本。有可能解决“遗掉漏洞”的问题。，可以使所有基于框架开发的业务都能受益。
模板引擎与XSS防御
在view层可以解决XSS问题。XSS攻击是在用户的浏览器上执行的，其形成过程则是在服务器端页面渲染时，注入了恶意的HTML代码导致的。从MVC架构来说是发生在view层，因此使用“输出编码”的防御方法更加合理，这意味着需要针对不同的XSS攻击场景使用不同的编码方式（HTML标签、属性、script标签、事件、CSS、URL）针对不同的情况，使用不同的编码函数。
在velocity提供的处理机制，与Django的auto-escape所提供的机制是类似的，都只进行了HTMLencode，而为未细分编码使用的具体场景，但是在模板引擎中，可以实现自定义的编码函数，应用于不同的场景。在Django中是使用自定义filters，在velocity中则可以使用“宏”（velocimacro）。
通过自定义的方法，使得XSS防御的功能得到完善；同时在模板系统中，搜索不安全的变量也有了依据，甚至在代码检测工具中，可以自动判断出需要使用那一种安全的编码方法，这在安全开发中是非常重要的。
Web框架与CSRF防御
在web框架中可以使用security token解决CSRF攻击问题。CSRF攻击的目标一般都会产生“写数据”操作的URL（例：增删改），而“读数据”的的操作并不是CSRF的攻击目标，因为在CSRF的攻击过程中攻击者无法获取到服务器端返回的数据，攻击者只是借用户之手触发服务器动作。
完整的CSRF防御方案，对于Web框架来说有以下建议：
1.在session中绑定token，如果不能保存在服务端session中，则可以替代为保存在cookie中。
2.在form表单中自动填入token字段。
3.在Ajax请求中自动添加token，这可能需要已有的Ajax封装实现的支持。
4.在服务器端对比post提交参数的token与session中绑定的token是否一致，以验证CSRF攻击。
HTTP Headers管理
在web框架中，可以对HTPP头进行全局化的处理，因此一些基于HTTP头的安全方案可以更好的实施。比如针对HTTP返回头的CRLF注入，因为HTTP头实际上可以看成是key-value对。因此对抗CRLF的方案只需在“value”中编码所有的\r\n即可。这里没有提到在“key”中编码\r\n,是因为让用户能够控制“key”是极其危险的事情。
并不是所有的web服务器、web容器、脚本语言提供的API都支持设置HTTPonly cookie，所以很多时候需要由框架实现一个功能：对所有的cookie默认添加HTTPonly，不需要此功能的cookie则单独在配置文件中列出。
一般来说，框架会提供一个统一的设置cookie函数，HTTPonly的功能可以在此函数中实现；如果没有这样的函数，则需要统一在HTTP返回头中配置实现。
数据持久层与SQL注入
使用ORM（object/relation mapping）框架对SQL注入是有积极意义的。对抗SQL注入的最佳方法是使用“预编译绑定变量”。在实际解决SQL注入时，还有一个难点就是应用复杂后，代码数量庞大，难以把可能存在SQL注入的地方不遗漏的找出来，而利用ORM框架解决此问题是一个便捷的途径。
web框架自身安全
凡是在web框架中可能实现的安全方案，只要对性能没有太大的损耗，都应该考虑实施。在设计整体安全方案时，比较科学的方法是：首先建立威胁模型，然后再判断那些威胁是可以在框架中得到解决的。web框架就像一层外衣，为web应用提供了足够的保护和控制力。
小结
在web框架中可以实施一些安全方案。web框架本身也是应用程序的一个组成部分，只是这个组成部分较为特殊，处于基础和底层的位置。web框架为安全方案设计提供了便利，但是很多web框架提供的解决方案有时并不可靠，同时web框架自身的安全性也不能忽视。
