[nihonium]

Biggest problem here is their architectural design. They're mixing server side code with front end. They're printing angular code using back end, but they are not filtering {} characters. Basically, user can execute any angular code, therefore any javascript.

[rtpg]

Yeah, this problem is basically unsolvable if you wish to have { characters anywhere in your page from server-side rendering.

- Have the possibility of {{ and }} in your server-side output (or whatever symbols you configured Angular for)

- Have Angular.JS on a page with server-side output

Choose one.

It's important to realize that this affects things like user input as well. So form initials/form defaults can also be affected by this issue!

A bit of a silly way to fix this problem is to modify your server-side escaping function (surely you have this!) to "escape" {{ with {<zero-width space>{. This will mess up things that need to be equal to each other, and can poison user input (because of form initials) but will protect you from this issue.

[catmanjan]

If you're displaying user input you could just encode to their matching HTML entities...

&#123; or the human friendlier one &rcurb (?)

[rtpg]

that doesn't work because the HTML entity decoding happens before Angular does the scanning of the DOM for the brackets. So even if you use &rcurb; output from the server, Angular will still interpret the brackets "properly"

As to why this works this way, consider the following:

do you have to do HTML entity decoding when getting an input value from Javascript?

[52-6F-62]

Correct me if I'm wrong but it appears they are now filtering the {} characters by URI encoding them upon submitting a search.

This isn't to say they've fixed anything else yet (I haven't looked), but it may mitigate the efforts of the lazy (like me in this instance).

[nihonium]

There were no filtering last time I've checked. Now, it looks like they've fixed the problem by completely deleting search results page, it's returning 404 :)