diff --git a/en/09.1.md b/en/09.1.md
index be1c4a29..8f4bc738 100644
--- a/en/09.1.md
+++ b/en/09.1.md
@@ -33,16 +33,16 @@ CSRF attacks work mostly because of the process through which users are authenti
 
 ## How to prevent CSRF attacks
 
-You might be a little scared after reading the section above. But fear is a good thing. It will force you educate yourself on how to prevent vulnerabilities like this from happening to you.
+You might be a little scared after reading the section above. But fear is a good thing. It will force you to educate yourself on how to prevent vulnerabilities like this from happening to you.
 
 Preventative measures against CSRF attacks can be taken on both the server and client sides of a web application. However, CSRF attacks are most effectively thwarted on the server side.
 
-There are many ways of preventing CSRF attacks are the server side. Most approaches stem from from the following two aspects:
+There are many ways of preventing CSRF attacks on the server side. Most approaches stem from from the following two aspects:
 
 1. Maintaining proper use of GET, POST and cookies.
 2. Including a pseudo-random number with non-GET requests.
 
-In the previous chapter on REST, we saw how most web applications are based on GET and POST HTTP requests, and that cookies were included along with these requests. We generally design application as according to the following principles:
+In the previous chapter on REST, we saw how most web applications are based on GET and POST HTTP requests, and that cookies were included along with these requests. We generally design applications according to the following principles:
 
 1. GET is commonly used to view information without altering any data.
 
@@ -58,7 +58,7 @@ Since we've stipulated that modifications can only use POST, when a GET method i
 We need to implement a second step, which is (in the case of non-GET requests) to increase the length of the pseudo-random number included with the request. This usually involves steps:
 
 - For each user, generate a unique cookie token with a pseudo-random value. All forms must contain the same pseudo-random value. This proposal is the simplest one because in theory, an attacker cannot read third party cookies. Any form that an attacker may submit will fail the validation process without knowing what the random value is.
-- Different forms contain different pseudo-random values, as we've introduced in section 4.4, "How to prevent multiple form submission". We can reuse the relevant code from that section suit our needs:
+- Different forms contain different pseudo-random values, as we've introduced in section 4.4, "How to prevent multiple form submission". We can reuse the relevant code from that section to meet our needs:
 
 Generating a random number token:
 
@@ -89,7 +89,7 @@ We can use the preceding code to secure our POSTs. You might be wondering, in ac
 
 ## Summary
 
-Cross-site request forgery, otherwise known as CSRF, is a very dangerous web security threat. It is known in web security circles as a "sleeping giant" security issue; as you can tell, CSRF attacks have quite the reputation. This section not only introduced cross-site request forgery itself, but factors underlying this vulnerability. It concludes with some suggestions and methods for preventing such attacks. I hope this section will have inspired you, as a reader, to write better and more secure web applications.
+Cross-site request forgery, also known as CSRF, is a very dangerous web security threat. It is known in web security circles as a "sleeping giant" security issue; as you can tell, CSRF attacks have quite the reputation. This section not only introduced cross-site request forgery itself, but factors underlying this vulnerability. It concludes with some suggestions and methods for preventing such attacks. I hope this section will have inspired you, as a reader, to write better and more secure web applications.
 
 ## Links
 - [Directory](preface.md)