Insecure Design – The #4 Web Application Security Risk

Developing secure applications requires more than just coding practices. It needs a holistic approach that centers around secure design principles.

Insecure design issues can lead to vulnerabilities that span all categories of risks like the OWASP Top 10. As the OWASP mentions, insecure design has the potential to impact all the top 10 application security risks identified by OWASP.

CWEs Mapped 40
Max Incidence Rate 24.19%
Avg Incidence Rate 3.00%
Avg Weighted Exploit 6.46
Avg Weighted Impact 6.78
Max Coverage 77.25%
Avg Coverage 42.51%
Total Occurrences 262,407
Total CVEs 2,691

A04:2021 – Insecure Design

What is Insecure Design?

Insecure design refers to flaws in the initial architecture, specifications, and layout of an application’s functionality. Unlike coding bugs that can be fixed, design flaws cannot be coded out later.

Some examples of insecure design patterns highlighted in the text include:

  • Using weak authentication methods like security questions, which can be easily guessed through public information

  • Not restricting file uploads adequately or validating uploaded file types

  • Returning overly detailed error messages that reveal sensitive information

The Fallout of Poor Design Decisions

The impact of insecure design can be massive. The text cites over 2,600 Common Vulnerabilities and Exposures (CVEs) related to design flaws with high exploit and impact scores.

Vulnerabilities that can arise due to improper design span things like:

  • Information leakage through verbose error reporting

  • Allowing arbitrary code execution via unrestricted file uploads

  • Enabling injection attacks with unsanitized user inputs

Ultimately, design issues weaken the application’s overall security posture significantly.

The Solution Lies in Secure Design Practices

The key takeaway from the text is that we need to shift left and prioritize secure design in the application development lifecycle.

Here are some recommendations highlighted to promote secure design:

OWASP’s Secure SDLC Methodology

The text specifically calls out OWASP’s secure SDLC methodology spanning five stages:

  • Planning: Define goals, requirements, scope

  • Design: Create architecture, threat model

  • Development: Code, code review, test coverage

  • Testing: Validate functionality, security

  • Release: Deploy, monitor, respond

In each stage, OWASP provides guidance, tools, and frameworks like the Software Assurance Maturity Model (SAMM) to embed security by design.

The Key is Being Proactive

In summary, the text reiterates that applications built without integrating secure design practices are set up to fail. Security issues should be mitigated proactively through measures woven into the fabric of the development lifecycle, not as an afterthought.

Shifting left into secure design is key to building robust, secure applications.

What are your thoughts on addressing application security through ingraining secure design? Feel free to share other ideas or recommendations in the comments.

Leave a Reply

Your email address will not be published. Required fields are marked *