Static Code Analysis Tool, Cross Site Scripting (XSS), a Fix and a Good Practice

You can always print out an attribute simply like this in JSP pages, assuming myAttr is the attribute name.

${myAttr}

But if the origin of that attribute is actually a request parameter that is coming straight from the user input, then by printing in JPS page that way, you make yourself vulnerable to the Cross Site Scripting. The fix to this Cross Site Scripting vulnerability is to escape HTML. By default, <c:out> prints its value by escaping HTML. Therefore, using <c:out> to print the attribute the following way

<c:out value="${myAttr}"/> 

will automatically fix the vulnerability. 

If myAttr attribute is not directly coming from the user input, then it's safe to print without <c:out>. But if your company or your client uses Static Code Analysis tool to scan your code as standard practice, those tools will normally flag as Cross Site Scripting vulnerability once they detect printing this way, ${myAttr}, in JSP pages whether or not that attribute is coming from the user input.

If you are sure that myAttr is actually not coming from the user input, then you can define the flag as "false positive". But it's gonna be very annoying to keep coming back every time your code is scanned by those tools. And what's more, it's usually company policy to fix as many flags as possible whether they are real vulnerabilities or false positives.

So it's a good practice or become an industry best practice to always print out an attribute using <c:out> the following way

<c:out value="${myAttr}"/>

whether the attribute is really vulnerable or not.