diff --git a/docs/topics/security.txt b/docs/topics/security.txt
index 151853d4ac..0a3c6bff02 100644
--- a/docs/topics/security.txt
+++ b/docs/topics/security.txt
@@ -76,9 +76,17 @@ POST to your Web site and have another logged in user unwittingly submit that
 form. The malicious user would have to know the nonce, which is user specific
 (using a cookie).
 
+When deployed with :ref:`HTTPS <security-recommendation-ssl>`, 
+``CsrfViewMiddleware`` will check that the HTTP referer header is set to a 
+URL on the same origin (including subdomain and port). Because HTTPS
+provides additional security, it is imperative to ensure connections use HTTPS
+where it is available by forwarding insecure connection requests and using
+HSTS for supported browsers.
+
 Be very careful with marking views with the ``csrf_exempt`` decorator unless
 it is absolutely necessary.
 
+
 SQL injection protection
 ========================
 
@@ -112,6 +120,8 @@ The middleware is strongly recommended for any site that does not need to have
 its pages wrapped in a frame by third party sites, or only needs to allow that
 for a small section of the site.
 
+.. _security-recommendation-ssl:
+
 SSL/HTTPS
 =========
 
@@ -147,7 +157,15 @@ server, there are some additional steps you may need:
   any POST data being accepted over HTTP (which will be fine if you are
   redirecting all HTTP traffic to HTTPS).
 
-.. _additional-security-topics:
+* Use HTTP Strict Transport Security (HSTS)
+
+  HSTS is an HTTP header that informs a browser that all future connections
+  to a particular site should always use HTTPS. Combined with redirecting
+  requests over HTTP to HTTPS, this will ensure that connections always enjoy
+  the added security of SSL provided one successful connection has occurred.
+  HSTS is usually configured on the web server.
+
+.. _host-headers-virtual-hosting:
 
 Host headers and virtual hosting
 ================================
@@ -158,15 +176,17 @@ Site Scripting attacks, they can be used for Cross-Site Request
 Forgery and cache poisoning attacks in some circumstances. We
 recommend you ensure your Web server is configured such that:
 
-    * It always validates incoming HTTP ``Host`` headers against the expected
-      host name.
-    * Disallows requests with no ``Host`` header.
-    * Is *not* configured with a catch-all virtual host that forwards requests
-      to a Django application.
+* It always validates incoming HTTP ``Host`` headers against the expected
+  host name.
+* Disallows requests with no ``Host`` header.
+* Is *not* configured with a catch-all virtual host that forwards requests
+  to a Django application.
 
 Additionally, as of 1.3.1, Django requires you to explicitly enable support for
 the ``X-Forwarded-Host`` header if your configuration requires it.
 
+.. _additional-security-topics:
+
 Additional security topics
 ==========================