Security influencers provide real-world insight and “in-the-trenches” experiences on topics ranging from application security to DevOps and risk management


The Fast, Free, Fantastic Way to Find Cross-Site Scripting (XSS)


What Is XSS?

Cross-site scripting (XSS) is really pretty simple. Any time untrusted data ends up an HTML page without proper validation and escaping, you have a problem.  So when a developer takes an HTTP request parameter and it finds its way through the code into an HTML page, the result is XSS -- unless the data is properly validated and escaped.

Most studies, including our own 2013 Global AppSec Risk Report, show that XSS is very prevalent, affecting the vast majority of applications. Our work shows that 80% of applications have at least one XSS vulnerability. A visit to is certain to raise some eyebrows. That's a stunning result for a vulnerability that has been well understood for over a decade.

Finding XSS Problems

Most XSS is simple to find. You just have to find input that flows from an untrusted source into an HTML page. Many times, the the path from the request to the HTML page isn't very complicated. Sometimes the same call gets the data and puts in the HTML page, like putting ${} in a JSP page.

But other XSS can be devilishly complex. Imagine an application that has millions of lines of code involved in getting data, transforming it, validating it, storing it, combining it, escaping it, decoding it, persisting it, retrieving it, and finally rendering it. How can one know if there a path through all that code that creates an XSS vulnerability?

The number of possible paths and patterns is infinite. Every applicaiton is a beautiful snowflake with its own special weaknesses. That's why traditional tools struggle to find XSS without flagging a lot of false alarms.

Traditional Approaches

Dynamic scanning (DAST) tools attempt to guess which data can run this gauntlet. So these tools generate thousands of requests and bombard your application with them to see if they can get anything through. These tools can find issues that show up in web pages, but can't see anything internal to your application and don't exercise much of your code.

Static analysis (SAST) tools, on the other hand, try to model the entire application by guessing how all the source code, libraries, frameworks, and components fit together and will operate when run.  But they make a lot of mistakes and typically don't even attempt to model the whole application.

Both approaches are difficult to set up and don't get very good results. That's why we are leading the way with the next generation of application security tools known as IAST, or "Interactive Application Security Testing" tools.

The Contrast Security Approach for XSS

Remember the definition of cross-site scripting? (Any time untrusted data ends up an HTML page without proper validation and escaping.) Contrast™ simply tags and tracks untrusted data wherever it goes within an application. Contrast also tracks all the validation and escaping that happen to that data along the way. Then anytime data gets written to an HTML page we know if it's an XSS problem.  If it is, Contrast reports the vulnerability along with all the details. Contrast simply works better.

But you don't have to just take our word for it. The proof is in the proverbial pudding. You can test Contrast yourself. You'll get everything you need to test it out and discover cross site scripting weaknesses across your applications.

Just click on the graphic below to get 30 days of access to Contrast. 

Hackers have better tools than you...

Jeff Williams, Co-Founder, Chief Technology Officer

Jeff Williams, Co-Founder, Chief Technology Officer

Jeff brings more than 20 years of security leadership experience as co-founder and Chief Technology Officer of Contrast. Previously, Jeff was co-founder and CEO of Aspect Security, a successful and innovative application security consulting company acquired by Ernst & Young. Jeff is also a founder and major contributor to OWASP, where he served as the Chair of the OWASP Board for 8 years.