So you've locked down your user input validation, your authentication/access control, and even your error handling. What else could possibly go wrong? If you're not careful about what data you store and how you protect it, you can cause serious damage to your users or even be held legally responsible for data breaches.

Protecting the back-end storage of your application is just as important as locking down the front-end user interface and web server. Some of the most common mistakes include:

• Failure to encrypt critical data
• Unencrypted backups
• Storing unnecessary data, or storing data too long
• Failure to delete data securely
• Insecure storage of keys, certificates, and passwords
• Attempting to invent a new encryption algorithm

Many developers and system administrators have a false sense of security about their internal network. In reality, most modern enterprise networks have hundreds, if not thousands, of potential entry points for outsiders (think company laptops on public wireless networks, spear phishing, and even old-fashioned facility breaches). In addition, insiders are a far bigger security risk than most people realize (estimates range from 40% to 80% of all IT security incidents, though this number is often subject to heated debate).

Regardless of the actual percentage, the fact is that any data stored by your application needs to be properly protected from both internal and external threats. To make sure that your data storage is secure, developers can use the following techniques:

1. Limit Data Storage: Only store data that is absolutely necessary for your application to meet its requirements, and don't store it longer than necessary. Use temporary storage as appropriate, but keep in mind that "delete" is by default not a secure operation in most environments (see the next bullet for details). Carefully weigh the benefits of user convenience against liability for stored data. For example, it may be acceptable to ask users to re-enter a credit card number for each transaction, depending on frequency. For simple yes/no checks, store a hash instead of the actual data (as is standard practice with passwords). This approach is limited because it only works when you don't care about the contents of the data.
2. Use Secure Deletion Methods: When deleting any data (including temporary files), use secure methods. For disk storage, use standard secure deletion tools (there are many available, depending on your platform and filesystems). For example, SDelete for Windows or wipe for Linux. For data stored in memory, a simple overwrite prior to deletion is sufficient in most cases. In Java, you need to be particularly careful with the String class, which is an immutable data type and may remain in memory until the application terminates (which could be a very long time in the case of a container web server). As a result, you should use a byte array instead when storing any sensitive data, such as passwords. Other languages probably have similar caveats, especially with some of the basic data types, so be sure to research how garbage collection works in your development environment.
3. Use Well-Known Encryption Algorithms: Today, there is little reason to ever let your users' data hit the disk platters (or flash storage chips) without being encrypted. Filesystem-level encryption solutions are available for all major environments and are transparent to the OS and applications. This may not help much against attackers who get into your running system, but it protects you in case of hardware or backup device theft. Depending on the sensitivity of your data, you may want to use application-layer encryption as well, where decryption is tied to each user's authentication token. In all cases, use well-established cryptographic routines and algorithms; don't attempt to come up with your own. In Java, the Java Cryptographic Extensions (JCE) provide enough functionality to satisfy the vast majority of application needs.
4. Stick to Proper Channels: It sounds like the mantra of some government bureaucrat, but it can be very useful for application developers. In other words, make sure that users (and internal staff) can only access the application via the intended user interface, where you're in control of the data and the audit trail. Any direct filesystem or database access to the application and backend data should be strictly limited and logged.
5. The Document Root is Off-Limits: Never store any application data in the document root of the web (application) server. No matter how well you may hide it, this is the most exposed part of your filesystem--so it's better not to take chances.

Sticking to these guidelines may well mean the difference between just another day at the office and a large-scale data breach case against your company (just ask TJX or Heartland Payment Systems).

Next time, we'll discuss how to provide a secure environment for your application via proper configuration management.