Cross-Site Scripting: Self

Sending unvalidated data to a web browser can result in the browser executing malicious code.

Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web application through an untrusted source. In the case of self-XSS, data is read from a text box or other value that can be controlled from the DOM and written back into the page using client-side code.


2. The data is included in dynamic content that is sent to a web user without validation. In the case of self-XSS, malicious content is executed as part of DOM (Document Object Model) modification.

The malicious content in the case of self-XSS takes the form of a JavaScript segment, or any other type of code that the browser executes. As self-XSS is primarily an attack on oneself, it is often considered unimportant, but should be treated the same as a standard XSS weakness if one of the following can occur:

- A Cross-Site Request Forgery vulnerability is identified on your website.
- A social engineering attack can convince a user to attack their own account, compromising their session.
Example 1: Consider the HTML form:

  <div id="myDiv">
    Employee ID: <input type="text" id="eid"><br>
    ...
    <button>Show results</button>
  </div>
  <div id="resultsDiv">
    ...
  </div>
  

The following jQuery code segment reads an employee ID from the text box, and displays it to the user.

  $(document).ready(function(){
    $("#myDiv").on("click", "button", function(){
      var eid = $("#eid").val();
      $("resultsDiv").append(eid);
      ...
    });
  });
  

These code examples operate correctly if the employee ID from the text input with ID eid contains only standard alphanumeric text. If eid has a value that includes metacharacters or source code, then after the user clicks the button, the code is added to the DOM for the browser to execute. If an attacker can convince a user to input malicious input into the text input, then this is simply a DOM-based XSS.