一、MVC框架安全
从数据的流入来看，用户提交的数据先后流经了View层、Controller、Model层，数据流出则反过来。在设计安全方案时，要牢牢把握住数据这个关键因素。
比如在Spring Security中，通过URL pattern实现的访问控制，需要由框架来处理所有用户请求，在Spring Security获取了URL handler基础上，才有可能将后去的安全检查落实。在Spring Security的配置中，第一步就是在web.xml文件中增加一个filter，接管用户数据。
<filter> <filter-name>springSecurityFilterChain</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> </filter> <filter-mapping> <filter-name>springSecurityFilterChain</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
一些主要的Web安全威胁，如XSS、CSRF、SQL注入、访问控制、认证、URL跳转等不涉及业务逻辑的安全问题，都可以集中放在MVC框架中解决。
二、模板引擎与XSS防御
在View层，可以解决XSS问题。XSS攻击是在用户的浏览器上执行的，其形成过程则是在服务器端页面渲染时，注入了恶意的HTML代码导致的。从MVC架构来说，是发生在View层，因此使用“输出编码”的防御方法更加合理，这意味着需要针对不同上下文的XSS攻击场景，使用不同的编码方式。
三、Web框架与CSRF防御
在Web框架中可以使用security token解决CSRF攻击的问题。
CSRF攻击的目标，一般都会产生“写数据”操作的URL，因为在CSRF的攻击过程中攻击者无法获取到服务器端返回的数据，攻击者只是借用户之手触发服务器的动作，所以读数据对于CSRF来说无直接的意义（但是如果同时存在XSS漏洞或者其他的跨域漏洞，则可能会引起别的问题，在这里，仅仅就CSRF对抗本身进行讨论）。
在Web应用开发中，有必要对“读操作”和“写操作”予以区分，比如要求所有的“写操作”都使用HTTP POST。
实际上POST本身并不足以对抗CSRF，因为POST也是可以自动提交的。但是POST的使用，对于保护token有着积极的意义，二security token的私密性（不可预测性原则），是防御CSRF攻击的基础。
对于Web框架来说，可以自动地在所有涉及POST的代码中添加token，这些地方包括所有的form表单、所有的Ajax POST请求等。
完整的CSRF防御方案，对于Web框架来说有以下几处地方需要改动。
- 在Session中绑定token。如果不能保存到服务器端Session中，则可以代替为保存到Cookie里。
- 在form表单中自动填入token字段，比如<input type=hidden name="anti_csrf_token" value="$token"/>。
- 在Ajax请求中自动添加token，这可能需要已有的Ajax封装实现的支持。
- 在服务器端对比POST提交参数的token与Session中绑定的token是否一致，以验证CSRF攻击。
四、HTTP Headers管理
在Web框架中，可以对HTTP头进行全局化的处理，因此一些基于HTTP头的安全方案可以很好地实施。
比如针对HTTP返回头的CRLF注入。
类似的，针对30X返回好的HTTP Response，浏览器将会跳转到Location指定的URL，攻击者往往利用此类功能实施钓鱼或诈骗。
HTTP/1.1 302 Moved Temporarily (...) Location: http://www.phishing.tld
对于框架来说，管理好跳转地址是很有必要的。一般来说，可以在两个地方这件事情：
- 如果Web框架中提供统一的跳转函数，则可以在跳转函数内部实现一个白名单，指定跳转地址只能在白名单中；
- 另一种解决方式是控制HTTP的Location字段，限制Location的值只能是哪些地址，也能起到同样的效果。
五、数据持久层与SQL注入
使用ORM（Object/Relation Mapping）框架对SQL注入是有积极意义的。对抗SQL注入的最佳方式就是使用“预编译绑定变量”。