Even though attacks against the business logic of a Web site vary as much as the logic does among different Web sites, there are some fundamental steps that developers can take to prevent these vulnerabilities from cropping up or at least mitigate the impact of those that do. Take note that many of these countermeasures focus on the larger view of the Web application. Many steps require code, but the application as a whole must be considered, including what type of application it is and how it is expected to be used.
This is the first time that the documentation phase of a software project has been mentioned within a countermeasure. All stages of the development process, from concept to deployment, influence a site's security. Good documentation of requirements and how features should be implemented bear significant aid toward identifying the potential for logic-based attacks. Requirements define what users should be able to do within an application. Requirements are translated into specific features along with implementation details that guide the developers.
Careful review of a site's workflows will elicit what-if questions, for example, what if a user clicks on link C before link B, submits the same form multiple times, or tries to upload a file type that isn't permitted? These questions need to be asked and answered in terms of threats to the application and risks to the site or user information if a piece of business logic fails. Attackers do not interact with sites in the way users are “supposed to.” Documentation should clearly define how a feature should respond to users who make mistakes or enter a workflow out of order. A security review should look at the same documentation with an eye for an adversarial opponent looking for loopholes that allow requirements to be bypassed.