I am building a web application, in which I am required to let user enter any character(even special characters - ~!@#$%^&*()_-+=|\{}[];:'"<,.>) in an input field. To mitigate the problems caused by them, I am taking care of two things -

  1. SQL injection - using parameterized queries
  2. Cross Site Scripting - HTML escaping user input before adding it to DOM.

Is it sufficient or am I missing something?

EDIT For giving a better context, I am explaining the flow.

In my web application, user input goes directly to a database. It is fetched from the database to create HTML(also setting html elements attributes and styles) and JSON. I am escaping the fetched values from the database while creating HTML.

While creating JSON, I am not escaping those fetched values. This JSON is used by our another application to create HTML. And I am making sure that the values are escaped before inserted into HTML.

  • 1
    what do you mean "special characters"? does this include characters like \bell and \ff and \n ?
    – LvB
    May 18, 2015 at 10:36
  • Sorry, I wasn't clear, I just updated the post. May 18, 2015 at 10:45
  • Can't this be solved by using prepared statements? The user input will not be able to modify the abstract syntax tree and there will be no issue for SQL injections. This only takes care of SQL injections, if you ever display this data, you need to take care of XSS as well. I would just use XSS preventing libraries for that part. A good library will allow special characters like <, ?, [ but won't allow scripts to be constructed. Take care that the combination of multiple outputs can't generate a script by putting the HTML in between in comment.
    – Silver
    Jul 4, 2016 at 7:54

2 Answers 2


There's no such thing as special characters.

It all depends on the context that input is used within your application. Protecting against SQLi and XSS is great, however if the input is then to be used in an operating system shell call it does you no good.

Always encode or sanitize when the data is used - leave this as late as possible. For example when outputting to HTML, HTML encode at this point.

So without knowing all the output points or sinks in your application, it is impossible to say if you are missing something. If all you are doing is inserting data into a database, and outputting it to HTML (not JSON, JavaScript, CSS, etc) then if you do the correct parameterisation and HTML output encoding in the right places you are good as far as XSS and SQLi vulnerabilities go. Doing anything else with the data would require properly encoding, sanitizing or using the correct API depending on the format.

  • Thanks, I just added the information in the post about how am I going to use the data. May 18, 2015 at 11:06

you put user input directly into a DB?... Bad idea (in general).

You should sanitize all Input. (so input coming from the client and input coming from the Database).

You are relying on the Client to make values safe in your example. something you should never fully trust as its outside of your control.

for the rest I defer to @SilverlightFox as his points are all valid and applicable with 1 addition. User input should be sanitized not only on display but before storage as well.

  • 2
    Why it is bad to put user input directly into a DB, If I have taken care of SQL injection vulnerabilities. May 18, 2015 at 12:36
  • because as Microsoft put it All input is Evil. Or in other words. you can not trust user input to be safe to be put into the Database until you have checked it.
    – LvB
    May 18, 2015 at 12:55
  • How do you sanitize #? May 18, 2015 at 19:26
  • that depends n your environment... there not all the same.
    – LvB
    May 18, 2015 at 22:57

You must log in to answer this question.

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