From fa40431da8d560097a417c41465a9bfef633bbe2 Mon Sep 17 00:00:00 2001 From: wbamberg Date: Thu, 12 Dec 2024 11:00:29 -0800 Subject: [PATCH] Consistent case for bullets --- files/en-us/web/security/attacks/xss/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/files/en-us/web/security/attacks/xss/index.md b/files/en-us/web/security/attacks/xss/index.md index e8636a01fc43f9b..820ffa63d70b96f 100644 --- a/files/en-us/web/security/attacks/xss/index.md +++ b/files/en-us/web/security/attacks/xss/index.md @@ -14,15 +14,15 @@ A web browser downloads code from many different websites and runs it on the use In a successful XSS attack, the attacker is able to subvert the same-origin policy by tricking the target site into executing malicious code within its own context, as though it were same-origin. The code can then do anything that the site's own code can do, including, for example: -- access and/or modify all the content of the site's loaded pages, and any content in local storage -- make HTTP requests with the user's credentials, enabling them to impersonate the user or access sensitive data +- Access and/or modify all the content of the site's loaded pages, and any content in local storage +- Make HTTP requests with the user's credentials, enabling them to impersonate the user or access sensitive data ![Diagram of attacker code running in target website](xss.svg) All XSS attacks depend on a website doing two things: -1. accepting some input that could have been crafted by an attacker -2. including this input in a page without _sanitizing_ it: that is, without ensuring that it won't be executable as JavaScript. +1. Accepting some input that could have been crafted by an attacker +2. Including this input in a page without _sanitizing_ it: that is, without ensuring that it won't be executable as JavaScript. ## Two XSS examples