From eda47fc8d58692adf0e31a854a1728e27359f0b0 Mon Sep 17 00:00:00 2001 From: wbamberg Date: Fri, 13 Dec 2024 11:36:05 -0800 Subject: [PATCH] Update files/en-us/web/security/attacks/xss/index.md Co-authored-by: Hamish Willee --- files/en-us/web/security/attacks/xss/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/files/en-us/web/security/attacks/xss/index.md b/files/en-us/web/security/attacks/xss/index.md index 4eb48fb594b0bbd..662f53e730bc6ed 100644 --- a/files/en-us/web/security/attacks/xss/index.md +++ b/files/en-us/web/security/attacks/xss/index.md @@ -142,7 +142,7 @@ In both cases, the general approach to defense is the same, and we'll go into th If you need to include external input in your site's pages, there are two main defenses against XSS: 1. Use _output encoding_ and _sanitization_ to prevent input from becoming executable. If you're rendering content in the browser, you can use the [Trusted Types API](/en-US/docs/Web/API/Trusted_Types_API) to ensure that input is being passed through a sanitization function before being included in the page. -2. Use a [Content Security Policy](/en-US/docs/Web/HTTP/CSP) (CSP) to tell the browser which JavaScript or CSS resources it should be allowed to execute. This is a backup defense: if the first defense fails, so executable input makes it into a page, then a properly configured CSP should prevent the browser from executing it. +2. Use a [Content Security Policy](/en-US/docs/Web/HTTP/CSP) (CSP) to tell the browser which JavaScript or CSS resources it should be allowed to execute. This is a backup defense: if the first defense fails and executable input makes it into a page, then a properly configured CSP should prevent the browser from executing it. ### Output encoding