Spring Escape HTML and prevent XSS attacks

TL;DR – If you think the context-param isn’t working, make sure you’re not outputting the value on the page somewhere not inside a spring form.

I ran into an issue recently where after a security scan was ran we were told when you enter a variable into the URL i.e. ?endDate=someJavaScript it was being executed on the page. Assumed it was an easy enough fix, so googled around and found, this solution for Spring Framework


I put that into the web.xml, restarted and it didn’t work, so I tried adding the page level and form level tags, but those didn’t work either. After messing around for a few hours I realized there was another place on the page where we were outputting the variable endDate, and it wasn’t inside a spring form.

What defaultHtmlEscape does is add that parameter to every spring tag in your application, pretty obvious in hindsight, but what I needed to do was make sure everywhere those values were displayed that they were displayed using a jstl c:out tag, i.e. <c:out value="${endDate}"></c:out> which also defaults to not allowing HTML to be rendered.

ESPN FantasyCast broken in Chrome

Once again ESPN FantasyCast is broken in Chrome. If you’re using Chrome and are seeing the game score and stats on two separate lines. Hit F12 and copy the following into the Console and press enter

$('#real .progame').css('width', '101%')

This increases the container for the game by 1% and allows the page to be fully functional again.

Java Format date with 4, 5 or 6 milliseconds

The title of this is wrong as far as terminology, but that’s what I was googling when trying to figure out my issue, so hopefully someone is helped by my struggles. I had a date 2016-06-01 13:20:24.60807 that I was trying to format into mm/dd/yyyy hh:mm:ss aa and the time was not accurate. I was using yyyy-MM-dd HH:mm:ss.SSSSSS as the format for SimpleDateFormat.

Date date = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSSSSS").parse(2019-06-01 13:20:24.60807); Was my exact Code and it kept outputting 06/01/2016 01:21:24 PM which was mostly accurate but not rounding up. I tried every variation of .* including just a dot and 1-6 S’s, but couldn’t get the value to work. The fewer S I tried the more off the result was. It wasn’t until I stumbled upon this StackOverflow question that I found out the issue. In Java 7 and below Date does not have enough precision to handle nanoseconds which is what the 4th, 5th and/or 6th digit after the period was, so rather than just truncating nano seconds it was adding 60,807 ms to my current time. Makes sense once you know the issue, but this data was coming from a stored proc and I could just truncate off the nanoseconds, so I ended up taking the left 23 characters of the current Date and then applying a pattern of “yyyy-MM-dd HH:mm:ss.SSS” and then using DateUtils.round to get the correct result. The resulting code, absent my try/catches is below.

public static String parseDate(final String currentDateStr, String currentFormat, String expectedFormat) {
    String currentDate = StringUtils.left(currentDateStr, 23);
    Date date = DateUtils.round(date, Calendar.SECOND);
    return new SimpleDateFormat(expectedFormat).format(date);
parseDate(processDate, "yyyy-MM-dd HH:mm:ss.SSS", "MM/dd/yyyy hh:mm:ss a");