Update v3_session.tex
[ssproject1617.git] / report / v11_httpsec.tex
index 4fb8da8..d1d2a58 100644 (file)
@@ -16,9 +16,9 @@ blocked.
 \item\pass{}
 Verify that every \HTTP{} response contains a
 content type header specifying a safe character set
-(e.g., \emph{UTF-8}, \emph{ISO 8859{-}1}).
+(e.g., UTF-8, ISO 8859{-}1).
 \begin{result}
-    Content type headers may be set anywhere in the application. Furthermure,
+    Content type headers may be set anywhere in the application. Furthermure,\\
     \code{Response::send} ensures that if no content type header is set, all
     responses will fall back to using \code{text/html; charset=UTF-8}.
 \end{result}
@@ -31,13 +31,14 @@ authenticated by the application.}
 % No proxies are present
 
 \item\fail{}
-Verify that a suitable X-FRAME-OPTIONS header is
+Verify that a suitable \code{X-FRAME-OPTIONS} header is
 in use for sites where content should not be
 viewed in a 3rd-party X-Frame.
 \begin{result}
     The application will never supply an \code{X-FRAME-OPTIONS} header. While
     this is not really a problem for the home page, a 3rd party X-Frame should
-    not be able to refer to the administrative interfaces of the application.
+    not be able to refer to the administrative interfaces of the application
+    and this should be fixed.
 \end{result}
 
 \item\pass{}
@@ -53,8 +54,7 @@ information of system components.
 \end{result}
 
 \item\fail{}
-Verify that all \API{} responses contain \code{X-Content-Type-Options:
-nosniff} and\\
+Verify that all \API{} responses contain \code{X-Content-Type-Options: nosniff} and\\
 \code{Content-Disposition: attachment; filename="api.json"} (or other
 appropriate filename for the content type).
 \begin{result}
@@ -70,7 +70,7 @@ JSON, and JavaScript injection vulnerabilities.
 \end{result}
 
 \item\fail{}
-Verify that the X-XSS-Protection: 1; mode=block
+Verify that the \code{X-XSS-Protection: 1; mode=block}
 header is in place to enable browser reflected \XSS{}
 filters.
 \begin{result}