File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
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

Win a copy of Make it so: Java DB Connections & Transactions this week in the JDBC forum!
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!