From 9784af0eff823220a3bea341b2d53dfbbc02f074 Mon Sep 17 00:00:00 2001
From: Ryan Rudder <96507400+RRudder@users.noreply.github.com>
Date: Mon, 8 May 2023 11:54:01 +1000
Subject: [PATCH] Updates to rec for Self-Stored XSS

---
 .../cross_site_scripting_xss/stored/self/recommendations.md    | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/submissions/description/cross_site_scripting_xss/stored/self/recommendations.md b/submissions/description/cross_site_scripting_xss/stored/self/recommendations.md
index bddeb439..f64c12fb 100644
--- a/submissions/description/cross_site_scripting_xss/stored/self/recommendations.md
+++ b/submissions/description/cross_site_scripting_xss/stored/self/recommendations.md
@@ -3,10 +3,9 @@
 There is no single technique to stop XSS from occurring. However, implementing the right combination of defensive measures within the application will prevent and limit the impact of XSS. Some best practices include the following:
 
 - All user input fields should be sanitized based on what the field is likely to contain. For example, a date field (01/01/2001) should only contain a maximum of 10 characters consisting of numbers and forward slashes. Additionally, drop down or pick lists can be used for allowable inputs to ensure expected values are sent to the server.
-- Use appropriate HTTP response headers to ensure the browser correctly interprets responses. These should be customized specific to the application and its environment. For example:
+- Implement a Content Security Policy (CSP) to ensure the browser correctly interprets responses and restricts which sources can be used to execute scripts. This should be customized specific to the application and its environment. For example:
 
     ``` HTTP
-    X-Content-Type-Options: nosniff
     Content-Security-Policy: default-src ‘self’; script-src ‘self’
     ```