Cross-site Scripting (XSS)

OWASP Top 10 - A7


OWASP just updated the Top 10 list.
Check out this in-depth post to learn everything about the new OWASP Top 10 2021.

Discover OWASP Top 10 2021

What is Cross-site Scripting (XSS)?

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.

Cross-site Scripting Attack Example

The most common example of XSS is a basic coded search engine for a website. The site search script is in this format:

Once something has been searched for, the script displays on the webpage something along the lines of:

"Results for Hdiv XSS here"

Simply displaying the search string straight onto the webpage without performing any validation checks. An attacker could insert a script and if no sanitation checks are being performed, this will just be displayed straight onto the webpage. This could be used to display anything the attacker wants.<script>alert("Hdiv XSS");</script>


Learn the answers to the key questions regarding IAST tools

Download Now

How to Prevent Cross-site Scripting (XSS)

The source of the problem of XSS risk is based on writes that use untrusted data without using escaped functions.

HTML Escape

XSS can be prevented sanitizing any user input before it is processed and/or rendered back to the browser. For example, in JSP by using JSTL <c:out> tag or fn:escapeXml() EL function when (re)displaying user-controlled input. This includes request headers, cookies, URL, body, parameters, etc, the whole request. Also the user-controlled input which is stored in a database needs to be escaped during redisplaying.


      // JSTL Tag
      <c:out value="${bean.userControlledValue}"/>
      // Spring Form Tags
      <form:hidden path="${bean.userControlledValue}" htmlEscape="true" />
      // Spring Eval
      <spring:eval expression="bean.userControlledValue" htmlEscape="true"/>
      // Struts 1
      <bean:write name="bean" property="userControlledValue" filter="true"/>
      // Struts 2
      <s:property value="#request.bean.userControlledValue" escapeHtml='true'/>

Input validation

Custom validation

Validate all input data to the application using whitelist (what is allowed) for type, format, length, range, reject if invalid.

Use Hdiv's Automatic Validation and Protection

It is important to note that both preventions are necessary, HTML Escape and Input Validation. To reinforce Input Validation, Hdiv eliminates to a large extent the risk originated by attacks of type Cross-site scripting (XSS) and SQL Injection using generic validations applied at application level.

In addition, Hdiv gets the required information directly from memory in real time, thanks to the integration points with web frameworks. After this analysis and thanks to the understanding of the semantics of each piece of data, Hdiv differentiates automatically between two types of data:

  • Data generated on the server side (read-only data): 90-95% of the information managed by a web application is read-only data offered by the server, which is presented by the application to be read/selected by the end user. This is the case of static information (text, images), and other components such as lists, buttons, links, etc.
  • Data generated on the client side (editable data): Only 5-10% of the information managed by a web application corresponds to data that is generated on the client side by the user, through text boxes (such as a search fields) or file input fields.

Hdiv makes an automatic security validation of the read-only data received by a web application that gives 100% trust. This means that it is impossible to carry out any kind of attack based on read-only data validated by Hdiv.

Risk Covered

The validation carried out by Hdiv is based on one of the security foundations (input data integrity validation), offering total guarantees. Furthermore, this validation algorithm needs no updating and is not affected by the evolution of technology or attacks, providing a 100% effective long-term solution.


The 7 Key Factors to Successful DevSecOps

Download Now



The 7 Key Factors to Successful DevSecOps

Download Now


Hdiv Detection (IAST) for Developers



The Best Protection Against OWASP Top 10 Risks



Agile protection: above and beyond the WAF

Read More