WHAT'S IN THIS CHAPTER?
Understanding your application's security needs
Discovering the threats to your users
Identifying potential vulnerabilities
As with any other class of bug, addressing a security issue becomes more expensive the longer you wait to fix it. If there's a problem in the design of the application, trying to fix it in a bugfix release will be very costly because you'll need to change multiple classes. You'll also need to understand and account for the myriad uses and configurations your customers have in place, and be ready to support migration of all these to the new, fixed version of the application. Addressing the issue the first time around means not only spending less time on the issue, but also avoiding the additional (direct and indirect) costs of a security vulnerability out in the field and coordinating a fix release. I once worked on a project for which we spent about three weeks addressing an issue that had been caused by a bad choice of file system path in the planning phase, some years earlier.
Of course it's not going to be possible or even desirable to identify and fix every single vulnerability before writing any code. That's a recipe for spending a great deal of money and taking a very long time to get to market, by which time your competitors will have gotten their apps to the customers. There is a principle software engineers have borrowed from economics called the Pareto Principle, also known as the −80/20 rule." The principle ...