Let’s talk for a brief moment about some very basic things you can do to help make your web application more secure. If I were to pick three of the most common issues I still see while browsing the web, they would be:

  1. Error messages enabled
  2. Cross-Site Scripting (unescaped input)
  3. And yes, SQL Injection of some sort

The (un)fortunate thing is that most of these issues are easily solvable. A generic error page, as opposed to a stack trace or verbose error message, can usually be implemented with a couple configuration changes. Yet, I still see large websites that spit out stack traces and code when an error occurs.

Cross-Site Scripting is another issue that still plagues us. Testing for it is simple – just enter something like test"> into an input field and if the resulting page displays that in raw HTML, chances are you have a problem. Every language has some form of HTML-escaping function and, if possible, it’s good to turn this on by default. This will be the case in Rails 3.0, thankfully.

Finally, I still see traces of SQL Injection on an all-too regular basis. Identified by the oh-so-dangerous single tick mark – ‘ – and typically resulting in an error page that shouldn’t be showing up anyway if the first issue were address. That said, even if the error is obscured, it’s still possible to retrieve data using a technique called Blind SQL Injection. Any data getting sent to an SQL server should also be properly escaped or sent through stored procedures depending on the backend technology. Think SQL Injection isn’t a problem? Talk to RockYou, whose database of 32 million usernames and passwords was compromised because of it.

Address those three things and (sadly) you’ll be ahead of the game.