Fourth OWASP top 10 vulnerabilities - Insecure Design Link to heading

Introduction Link to heading

This article is the fourth of a series of ten, for more information about the serie please refer to the first article. The first part will introduce what the vulnerability does and the impact of it on website, there is no practical example for this article due to the nature of the vulnerability. Finally, the last part will described the best practices to mitigate/delete vulnerable components. This article is focus on insecure design.

Insecure Design Link to heading

In this part, OWASP dissociate design part and implementation. A secure design can have implementation defects which can lead to vulnerabilities may be exploited by an attacker. On another hand, an insecure design cannot be fixed by a perfect implementation. One factor contributing to insecure design is the lack of business risk on the software for example. By definition, secure design is a practice to ensure that code is robustly designed and tested to prevent known attack methods. However, a threat modeling can help identify the flaws or defects caused by a insecure design, a tool such Microsoft Threat Modeling tool can help with that. Furthermore, it is better to be sure on the quality of the design before starting to implement it, discussion with security specialists should be an essential part of the design.

Means of prevention Link to heading

As explain a bit in the previous part, there are different ways to prevent from this vulnerability :

  • Use threat modeling for critical authentication, access control, business logic, and key flows.

  • Integrate security language and controls in accordance with use cases of the application.

  • Write unit and integration tests to validate that all critical flows are resistant to the threat model.

  • Limit resource consumption by user or service.

Conclusion Link to heading

Secure Design is a culture that each developer need to have. All the failure in an application shall be controled and expected. Documentations for other developers is mandatory to understand how the application works. Finally, secure design and more precisely secure software requires a secure devolpment lifecycle from scratch.