diff --git a/public/docs/ts/latest/guide/security.jade b/public/docs/ts/latest/guide/security.jade
index 1148fdce7e..eb27f20252 100644
--- a/public/docs/ts/latest/guide/security.jade
+++ b/public/docs/ts/latest/guide/security.jade
@@ -348,48 +348,80 @@ h3#xsrf 跨站请求伪造（XSRF）
   a different web page (e.g. `evil.com`) with malignant code that secretly sends a malicious request 
   to your application's web server (e.g. `example-bank.com`). 
   
+  在跨站请求伪造（XSRF或CSFR）中，攻击者欺骗用户，让他们访问一个假冒页面(例如`evil.com`)，
+  该页面带有恶意代码，秘密的向你的应用程序服务器发送恶意请求(e.g. `example-bank.com`)。
+  
   Assume the user is logged into the application at `example-bank.com`.
   The user opens an email and clicks a link to `evil.com` which opens in a new tab.
   
+  假设用户已经在`example-bank.com`登录。用户打开一个邮件，点击里面的链接，在新页面中打开`evil.com`。
+  
   The `evil.com` page immediately sends a malicious request to `example-bank.com`.
   Perhaps it's a request to transfer money from the user's account to the attacker's account.
   The browser automatically sends the `example-bank.com` cookies (including the authentication cookie) with this request.
+  
+  该`evil.com`页面立刻发送恶意请求到`example-bank.com`。这个请求可能是从用户账户转账到攻击者的账户。
+  与该请求一起，浏览器自动发出`example-bank.com`的cookie。
 
   The `example-bank.com` server, if it lacks XSRF protection, can't tell the difference between a legitimate request from the application
   and the forged request from `evil.com`.
-
+  
+  如果`example-bank.com`服务器缺乏XSRF保护，就无法辨识请求是从应用程序发来的合法请求还是从`evil.com`来的假请求。
   
   To prevent this, the application must ensure that a user request originates from the real
   application, not from a different site. 
   The server and client must cooperate to thwart this attack.
   
+  为了防止这种情况，你必须确保每个用户的请求都是从你自己的应用中发出的，而不是从另一个网站发出的。
+  客户端和服务器必须合作来抵挡这种攻击。
+  
   In a common anti-XSRF technique, the application server sends a randomly
   generated authentication token in a cookie.
   The client code reads the cookie and adds a custom request header with the token in all subsequent requests.
   The server compares the received cookie value to the request header value and rejects the request if the values are missing or don't match.
   
+  常见的反XSRF技术是服务器随机生成一个用户认证令牌到cookie中。
+  客户端代码获取这个cookie，并用它为接下来所有的请求添加自定义请求页头。
+  服务器比较收到的cookie值与请求页头的值，如果它们不匹配，便拒绝请求。
+  
   This technique is effective because all browsers implement the _same origin policy_. Only code from the website 
   on which cookies are set can read the cookies from that site and set custom headers on requests to that site.
   That means only your application can read this cookie token and set the custom header. The malicious code on `evil.com` can't.
+  
+  这个技术之所以有效，是因为所有浏览器都实现了_同源策略_。只有设置cookie的网站的代码可以访问该站的cookie，并为该站的请求设置自定义页头。
+  这就是说，只有你的应用程序可以获取这个cookie令牌和设置自定义页头。`evil.com`的恶意代码不能。
 
   Angular's `http` has built-in support for the client-side half of this technique in its `XSRFStrategy`. 
   The default `CookieXSRFStrategy` is turned on automatically.
   Before sending an HTTP request, the `CookieXSRFStrategy` looks for a cookie called `XSRF-TOKEN` and 
   sets a header named `X-XSRF-TOKEN` with the value of that cookie. 
   
+  Angular的`http`客户端在其`XSRFStrategy`中具有对这项技术的内置支持。
+  默认的`CookieXSRFStrategy`会被自动开启
+  在发送每个请求之前，`CookieXSRFStrategy`查询名为`XSRF-TOKEN`的cookie，并设置一个名为`X-XSRF-TOKEN`的HTTP请求头，并把该cookie的值赋给它。
+  
   The server must do its part by setting the
   initial `XSRF-TOKEN` cookie and confirming that each subsequent state-modifying request
   includes a matching `XSRF-TOKEN` cookie and `X-XSRF-TOKEN` header.
+  
+  服务器必须要完成自己的任务，设置初始`XSRF-TOKEN`cookie，并确认接下来的每个请求包含了配对的`XSRF-TOKEN`cookie和`X-XSRF-TOKEN`页头。
 
   XSRF/CSRF tokens should be unique per user and session, have a large random value generated by a
   cryptographically secure random number generator, and should expire in a day or two.
+  
+  CSRF令牌对每个用户和session应该是唯一的，它包含一大串由安全的随机数字生成器生成的随机值，并且在一两天之内过期。
 
   Your server may use a different cookie or header name for this purpose.
   An Angular application can customize cookie and header names by providing its own `CookieXSRFStrategy` values.
+  
+  你服务器可能使用不同的cookie或者页头名字。Angular应用可以通过自己的`CookieXSRFStrategy`值来自定义cookie和页头名字。
+  
 code-example(language="typescript").
   { provide: XSRFStrategy, useValue: new CookieXSRFStrategy('myCookieName', 'My-Header-Name') }
 :marked
   Or you can implement and provide an entirely custom `XSRFStrategy`:
+  
+  或者你可以实现和提供完整的自定义`XSRFStrategy`。
 
 code-example(language="typescript").
   { provide: XSRFStrategy, useClass: MyXSRFStrategy }
@@ -400,14 +432,16 @@ code-example(language="typescript").
   <a href="https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet" target="_blank">Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet</a>.
   The Stanford University paper 
   <a href="https://seclab.stanford.edu/websec/csrf/csrf.pdf" target="_blank">Robust Defenses for Cross-Site Request Forgery</a> is a rich source of detail.
-
-  See also Dave Smith's easy-to-understand 
-  <a href="https://www.youtube.com/watch?v=9inczw6qtpY" target="_blank" title="Cross Site Request Funkery Securing Your Angular Apps From Evil Doers">talk on XSRF at AngularConnect 2016</a>.
-
+  
   到开放式Web应用程序安全项目(OWASP)的[这里](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29)
   和[这里](https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet)学习更多关于跨站请求伪造（XSRF）的知识。
   这个[斯坦福大学论文](https://seclab.stanford.edu/websec/csrf/csrf.pdf)有详尽的细节。
-
+  
+  See also Dave Smith's easy-to-understand 
+  <a href="https://www.youtube.com/watch?v=9inczw6qtpY" target="_blank" title="Cross Site Request Funkery Securing Your Angular Apps From Evil Doers">talk on XSRF at AngularConnect 2016</a>.
+  
+  参见Dave Smith在<a href="https://www.youtube.com/watch?v=9inczw6qtpY" target="_blank" title="Cross Site Request Funkery Securing Your Angular Apps From Evil Doers">AngularConnect 2016关于XSRF的演讲</a>。
+  
 h3#xssi Cross-site script inclusion (XSSI)
 
 h3#xssi 跨站脚本包含(XSSI)