Many developers see security as a separate phase of the software design process. Instead of building security in from day one, it is believed that it can be added later. This could not be further from the truth. While many security practices are specific to a given platform or programming language, here are some general principles which will avoid compromising an application’s security.
First, don’t treat security as an afterthought. This is one of the most important practices to grow accustomed to as a developer. Often, as launch day nears, development teams are so eager to release that they neglect essential tasks. Ignoring security is easily done because it seems less critical than does, for instance, optimizing database queries to run more efficiently on the production servers. Those problems are tangible. There are log files clearly showing that a given query is running more slowly than it should. There is no one actively attacking the application and while the consequences of a slow database query can be overcome, those resulting from a cracked server are not so easily resolved.
Another benefit to developing security into applications from the start is that it often makes developers actively think about how a system might be attacked. While it may seem paranoid to add extra security into a model before release, it is far easier to undo extra layers than it is to discover that they were necessary after the fact.
Avoid relying on a single layer of protection when developing an application. When using the MVC pattern, for example, many developers simply eliminate secured information from the view while still sending it over the wire. Unfortunately, failure to exercise due diligence in one layer causes the entire system to be compromised.
Instead, treat each layer as its own black box which must be independently secured. Code a model such that secured fields cannot be written or read by any code without the correct credentials. Eliminate secure information from being displayed in the view, and modify controllers to not access certain model fields in less secure contexts. The result is more code, but a failure in one layer will not result in a compromised system. Instead, a crash or traceback will reveal the error, which will make the application even more robust.
Consider how your application will be used. The security concerns for a mobile application are likely different than those of one to be used across a corporate intranet. Even so, plan your application with the weakest security circumstances in mind. Avoiding SSL and sending sensitive data unencrypted may work well in house, but as soon as someone accesses an application from a mobile phone or open access point, all of their data might be compromised.
Be aware of information leakage. Applications leak information in a variety of ways that can open up vectors for attack. Emailing passwords in the clear is a prime example of this. Instead, send links which allow the user to set a new password on a secure server. While an attacker can still intercept these emails and access the remote server before the intended user, the intent is for the legitimate user to quickly reset their credentials, so the information has a limited lifespan. Similarly, login credentials are often leaked to database administrators if passwords are stored unencrypted, or to anyone who compromises the database server.
Application security need not be fraught with paranoia and fear. By baking it directly into the development process rather than tacking it on as an afterthought, it is easy to avoid compromising application security while building a more robust product.