Two Laptop Bag
The moose likes Security and the fly likes Are the following characters XSS vulnerable? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Security
Bookmark "Are the following characters XSS vulnerable?" Watch "Are the following characters XSS vulnerable?" New topic

Are the following characters XSS vulnerable?

dinesh maddy

Joined: Mar 30, 2012
Posts: 6
We are trying to implement security in our application, wherein we need to encode and decode the user inputs.

So can anybody please provide me a list of all the characters that are disallowed or dangerous, that I need to encode?

For eg. for "<" character we use <, for ">" character we use >

so can anybody please tell me if the following mentioned characters are XSS vulnerable, and if yes, then how to encode them?

1) ! - exclamation mark - characters for additional command execution

2) - hyphen - can be used in database queries, and the creation of negative numbers.

3) /\ = The forward-slash and back-slash are often used for faking paths and queries

4) { } [ ] = Curly brackets and square brackets are often used as script, program or regex expressions.

5) *(asterisk) = Often used in database queries for “all”.

eg. <script>x=""*alert(1)*"";y=42;</script>

6) `(Grave accent) = If you need to use both double and single quotes you can use a grave accent(`) to encapsulate the JavaScript string - this is also useful because lots of cross site scripting filters don't know about grave accents.

7) / (division or forward slash) -


8) Bitwise “xor” operator: (^)


9) Bitwise Left Shift (<<)


10) Bitwise Right Shift (>>)


11) Bitwise Right Shift With Zeros


12) Ternary Conditional Expression


Please let me know if I need to encode these characters too. I am using Java for development.

Tim McGuire
Ranch Hand

Joined: Apr 30, 2003
Posts: 820

Best practice is to not roll your own. This is possible, but you are likely to miss something. Instead, use a well tested library such as the OWASP ESAPI.

The following page covers a lot of potential pitfalls in rolling your own and also recommends using ESAPI:
I agree. Here's the link:
subject: Are the following characters XSS vulnerable?
It's not a secret anymore!