I have a system which allows users to enter HTML-reserved characters into a text area, then post that to my application. That information is then saved to a database for later retrieval and display. Alarms are (should be) going off in your head. I need to make sure that I avoid XSS attacks, because I will display this data somewhere else in the application. Here are my options as I see it:
Encode before save to DB
I can HTML-encode the data on the way in to the database, so no HTML characters ever are entered in the database.
Pros:
- Developers don’t have to remember to HTML encode the data when its displayed on the web page.
Cons:
- The data now doesn’t make sense for desktop-based applications (or anything other than HTML). Stuff shows up like
< > &etc.
Don’t HTML encode before saving to DB
I can HTML encode the data whenever I need to display it on a web page.
Pros:
- Feels right because it keeps the integrity of the data that was entered by the user.
- Allows non-HTML based applications to just display this data without having to worry about HTML encoding.
Cons:
- We might display this data in a lot of places, and we’ll have to make sure that every developer knows that when you display this field, you’ll need to HTML encode it.
- People forget things. There WILL be at least once instance when we forget to HTML encode the data.
Scrub the data before saving to DB (don’t HTML encode)
I can use a well-tested third party library to remove potentially dangerous HTML and get a safe HTML fragment to save the database, not HTML encoded.
Pros:
- Preserves most of the original input so that display in a non-HTML format makes sense.
- Less catastrophic if the developer forgets to HTML encode this information for display on a web page.
Cons:
- Still messes with the data as the user originally entered it. If they really want to type a
<script>or<object>tag, it won’t make it, and we’ll get support calls and emails because of that.
My question is: What is the best option, or if there is another way of going about this, what is it?
The right thing to do is not mangle/change user input.
So, do not encode before saving.
Yes, this puts the onus on the developers to remember and know that they need to encode anything coming out of the DB, but this is good practice regardless.