I might be asking a similar question to this: Whitelisting DOM elements to defeat XSS

But I think my proposed solution is different and I was wondering if I could get the community to comment on whether it can be an effective way to prevent XSS attacks.

I am customizing a content management system that has a large code baseline (possibly hundreds of thousands of lines of executable code). Because of the nature of COTs development it's very difficult for developers to keep track of each and every script the browser executes.

Is it possible to whitelist scripts on the server side using a ServletFilter ?

My understanding of a servlet filter is that it sees all requests and responses (i.e. all requests and responses must go through the filter chain). I have noticed that responses contain tags. Which means when all the bytes of the script are transferred back to the client browser from the server, the intention is for the script to be executed client-side. There lies my opportunity to perform a whitelist check right inside the servlet filter before it reaches the client. I would like to make sure any script sent back to the client is on my approved list of scripts. If not, the filter would modify the response and pull out the script then and there.

Now there are a couple problems I can think of with this approach. First, how would I assign unique identifiers to a particular script that can be added to a whitelist in the first place?

The second issue is even if I figure out a way to assign unique identifiers for a particular script and add them to the whitelist, the whitelist would probably be huge (because this is a COTs product containing possibly thousands of scripts). And if I happen to forget to put a good script on the whitelist then there will be broken functionality .

These are the only issues I can think of with this approach. I was wondering if the community could comment on it or make this a better solution.

1 Answer 1


There's only one real defense against malicious scripts, and that's context-sensitive output escaping. First we need a couple definitions:

  • Definition 1: Any time user input is going to be handed off to another dynamic language interpreter, the transition from your data to the interpreter in question is called a Security Boundary.
  • Definition 2: Every security boundary has a specific Context, and this context defines what the rules are to safely ensure that the data you're handing off will not be executed as code.

The technique you're discussing is really an output-filtering approach, perhaps where you only allow scripts to be imported, ie

<script src="mydomain.com/somescript.js"/><script>

The short answer is: Yes, you could do that, but it would not be a "perfect" control.

Also, if your application allows user-controlled html/script code as part of its business function, this approach is completely shot.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .