Seems like I’ve been reading a lot about code injection vulnerabilities on Web sites. Of course, we all know about the Paris Hilton fiasco where a hacker was able to access her photos via the T-Mobile Web site. So for the sake of conversation, here’s what I do to prevent code injection:

• Double Validation – validate data input on the client side using JavaScript as well as on the server side. The server side validation is necessary in case the user turns off JavaScript.
• Referrer Checking – any page or process that accepts input from an HTML form should check its referrer to be sure it is receiving data from a trusted source. In some cases, it’s simple enough just to ensure it’s from the same domain; in others, you may want to be sure it comes from a particular page.
• Verify GET or POST – some languages, such as JSP, use a single method to get data regardless of the method used to submit it (request.getParameter()). If you know the data should be submitted using a POST, make sure that’s where it came from when processing it.
• Remove HTML Tags by Default – there’s no reason to not strip HTML tags from input by default. Most of the time, there’s no need for it. It is only special cases (such as e-mails or message board postings) where HTML may need to be allowed.
• Never Echo – this is the golden rule to avoid code injection. Never take an input value and output it directly to a Web page. You should always “scrub” the data (validate, strip HTML, etc.) before using it in output.

In general, I’ve found that these approaches take care of a lot of code injection vulnerabilities. If anyone has any other ideas, please feel free to add them.

Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.