Greetings friends! While the first three risks in the OWASP Top 10 cover specific vulnerability types, ones which are incredibly common in web apps, the fourth risk is a completely different style of risk entirely: Insecure Design. Rather than a technical control, it’s a concept you need to ponder and think about over time.

We’ll dive into Insecure Design in a moment, but if you missed any of the top three, definitely go check them out when you’ve finished here: #1 Broken Access Control, #2 Cryptographic Failures, & #3 Injection.

👉 Want me to hack your app and work with you to help improve your security?
🕵️ Book a Laravel Security Audit and Penetration test!

Looking to learn more?
⏩ Security Tip #6: Disable Dev & Test Commands in Production
▶️ In Depth #2: SQL Injection

A04:2021 – Insecure Design

You’d be mistaken for thinking Insecure Design describes every other vulnerability in some way or another, but in this case it specifically refers to features and code patterns which are inherently insecure. You can read more about it in detail on their official guide, but with the exception of the “How to Prevent” and “Examples”, it’s kinda dry and hard to follow without diving into corporate-speak.

Insecure Design is a new risk, not seen previously in the Top 10, and this suggests an attempt at a broader coverage of the software landscape and recognition that sometimes the insecurities and vulnerabilities are inherited from the original design and tooling.

In an effort to understand what they are meaning, I found this line in the OWASP Guide that I believe sums it up what they are trying to get at:

“An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks.”

So how does this relate to us as Laravel developers?

One of the aspects of Insecure Design is using insecure tools or frameworks. This is where we have a huge advantage - Laravel is secure by default. It comes with a lot of security features, already enabled for us, so by choosing to build our apps in Laravel, we’re taking a massive step towards secure design. Laravel also includes a bunch of extra security features, many of which we've covered before1, that we can use whenever we need them to make designing and building secure sites easier.

However, we also need to consider industry advice, such as checking for compromised/pwned passwords rather than enforcing password complexity, and supporting Multi-Factor Authentication (MFA), and secure account recovery flows2.

Consider also how features can be abused within technical limits, to disrupt and damage the business. The example OWASP gives of a cinema booking website that would an attacker to abuse their group booking system to lock up cinemas and result in loss of income is quite interesting:

Scenario #2: A cinema chain allows group booking discounts and has a maximum of fifteen attendees before requiring a deposit. Attackers could threat model this flow and test if they could book six hundred seats and all cinemas at once in a few requests, causing a massive loss of income.

This stuff isn’t easy. Hackers will often come up with the most creative ways to abuse your apps and bypass what appear to be safe limits. We can often add technical controls in place to limit and prevent abuse, but not always - and this is where Insecure Design comes in. Sometimes you need to throw the design away and start again, with security as a focus.

Please take some time to think about Insecure Design and how it could relate to the projects you work on. If you have any questions or thoughts, throw them in the comments and we can get a discussion going!