When I talk to developers about security in web development, I usually get the answer that the security is taken care by the systems team by securing the server and by using the https protocol. In reality that is just the tip of the iceberg on security. There’s much more you should do as a developer to incorporate security into your applications.

First the myth that using https secures your website – Using the https protocol only secures the communication between the browser and the server. What if the user himself is trying to hack your application? It just secures his session and doesn’t provide security for your website or application at all.

Another assumption I’ve come across is using the form action post is more secure than get. Posted data only seems secure since the data is not visible in the url. If anyone on the network is using a packet sniffer, the post data is still visible if data is transferred through http. Here is where using https helps.

Validate your form data on the server even if you have a super cool looking javascript validation on the browser. Clever users are known to disable javascript on the browser to get around your brilliant client side validation. Which means that if javascript is gone, all your form validation on the browser goes kaput.

On the server-side you have to be strict with your inputs via $_GET and $_POST even if you receive data through the https protocol. Use a good input filter library to clean your input data. Go to the extent of typecasting the inputs to the data-type to what you expect it to be. Using raw inputs to print data on screen or write to database is asking for trouble. This is how cross-site scripting and SQL injection creep into your applications.

I’ve seen really insecure applications take a file name from a query string in the url and go ahead and print the contents on screen. It just makes life easy for the cracker by allowing him to enter the path to a system file and mine the data to get into the server. Don’t ever use public data to craft your file include logic in the code, that’s easily exploitable!

An insecure practice which I’ve noticed is programmers use remote includes into the application, to the extent of having html snippets from other sites in their application. This allows users to inject malicious code from their own servers in your application. Imagine what they can do with this kind of power. Don’t allow users to a remote include code from external server urls whether it’s innocent looking HTML or otherwise.

This is not a comprehensive article on security but a quick one to cover some common issues developers have on web application security. If you need more specifics details, let me know by commenting on this post.