diff --git a/docs/source/reference/websecurity.md b/docs/source/reference/websecurity.md
index 8473c3e9..d9a9a397 100644
--- a/docs/source/reference/websecurity.md
+++ b/docs/source/reference/websecurity.md
@@ -5,18 +5,18 @@ The **Security Overview** section helps you learn about:
 - the design of JupyterHub with respect to web security
 - the semi-trusted user
 - the available mitigations to protect untrusted users from each other
-- the value of periodic security audits.
+- the value of periodic security audits
 
 This overview also helps you obtain a deeper understanding of how JupyterHub
 works.
 
-## Semi-trusted and untrusted users
+## Semi-trusted and Untrusted Users
 
 JupyterHub is designed to be a _simple multi-user server for modestly sized
 groups_ of **semi-trusted** users. While the design reflects serving semi-trusted
 users, JupyterHub is not necessarily unsuitable for serving **untrusted** users.
 
-Using JupyterHub with **untrusted** users does mean more work by the
+Using JupyterHub with **untrusted** users entails more work by the
 administrator. Much care is required to secure a Hub, with extra caution on
 protecting users from each other as the Hub is serving untrusted users.
 
@@ -32,7 +32,7 @@ servers) as a single website (i.e. single domain).
 
 To protect users from each other, a user must **never** be able to write arbitrary
 HTML and serve it to another user on the Hub's domain. JupyterHub's
-authentication setup prevents a user writing arbitrary HTML and serving it to
+authentication setup prevents a user from writing arbitrary HTML and serving it to
 another user because only the owner of a given single-user notebook server is
 allowed to view user-authored pages served by the given single-user notebook
 server.
@@ -41,7 +41,7 @@ To protect all users from each other, JupyterHub administrators must
 ensure that:
 
 - A user **does not have permission** to modify their single-user notebook server,
-  including:
+  as well as:
   - A user **may not** install new packages in the Python environment that runs
     their single-user server.
   - If the `PATH` is used to resolve the single-user executable (instead of
@@ -101,8 +101,8 @@ pose additional risk to the web application's security.
 
 ### Encrypt internal connections with SSL/TLS
 
-By default, all communication on the server, between the proxy, hub, and single
--user notebooks is performed unencrypted. Setting the `internal_ssl` flag in
+By default, all communications on the server, between the proxy, hub, and single
+-user notebooks are performed unencrypted. Setting the `internal_ssl` flag in
 `jupyterhub_config.py` secures the aforementioned routes. Turning this
 feature on does require that the enabled `Spawner` can use the certificates
 generated by the `Hub` (the default `LocalProcessSpawner` can, for instance).
@@ -118,7 +118,7 @@ extend to securing the `tcp` sockets as well.
 
 ## Security audits
 
-We recommend that you do periodic reviews of your deployment's security. It's
+We recommend that you do periodic reviews of your deployment's security. It is
 good practice to keep JupyterHub, configurable-http-proxy, and nodejs
 versions up to date.
 
@@ -129,7 +129,7 @@ A handy website for testing your deployment is
 
 ## Vulnerability reporting
 
-If you believe you’ve found a security vulnerability in JupyterHub, or any
+If you believe you have found a security vulnerability in JupyterHub, or any
 Jupyter project, please report it to
 [security@ipython.org](mailto:security@ipython.org). If you prefer to encrypt
 your security reports, you can use [this PGP public