A regularly-appearing news story over the last several years involves data being retrieved from a company or service without proper authorization. Recent examples have been the retrieval of iPad subscriber information from AT&T through web services or the credit card information retrieved from Target in November, 2012. The causes of both of these data breaches were different: For AT&T, the data was retrieved through the use of a web service that required no authentication to pull an email address; for Target, it appears that someone gained access to a computer inside a store and was able to install malware to enable remote control from that point.

Each problem is its own domain of security, but the core concept is the same: security procedures must be designed into the system from the beginning. From an API to network system configuration, attempting to add security after the fact tends to involve much more work than proper planning during the implementation phase.

When developing an application, the foremost concern needs to be what data is accessible by the actor performing a given operation. Incredible performance or dazzling user interface will mean nothing if data can be retrieved by unauthorized parties and force the service to be taken down. When creating the use cases for the services, care should be taken to identify what data will be modified and returned to the actor and verify before the operation commences that the actor has sufficient privileges to perform the desired operation.

A public, real-world reference project for the reason security needs to be considered from the beginning is the social network platform Diaspora. When it was first being written and released as a developer preview, it was quickly discovered that users could retrieve information for other user profiles that they were not connected to in any way, among other nefarious items. After the discovery was made public, the Diaspora team had to quickly retool and revisit their entire codebase to take authorization and authentication into account. This lost them several weeks of productivity before they released their first private beta two months later.

Developing the first time with security in mind can save a lot of headaches, late nights, and potential lawsuits later. Having to revamp existing code to improve security can lead to delayed release schedules, frustrated developers and management, and potentially very unhappy customers.