As I have been trying to cover the OWASP Top 10 to make my full-stack development skills more valuable, standardized, and aligned with the cybersecurity domain, the topics I have already covered include:
- A01 – Broken Access Control
- A02 – Cryptographic Failures
- A03 – Injection
In this article, I will talk about A04 (Insecure Design), its remediation, and how it differs from A01 in some important ways.
What A04 (Insecure Design) Focuses On
A04 focuses on the absence of proper logic and security mechanisms at the design and implementation level of a web application or website, which ultimately makes it insecure.
Some practices that commonly lead to Insecure Design include:
- Trusting the client-side too much
- Not designing APIs and gateways according to server-issued protocols and rules
- Performing sensitive processing on the client side
- Fetching sensitive data on the frontend when it is not required
Practical Handling of A04 in My Project
In this article, I’ll explain some of the practices I eliminated to avoid A04 (Insecure Design) issues in one of my projects, Alpha Connect Hub (now IoT Nerve).
Handling A04 across the entire project and all modules is my responsibility as a skilled full-stack developer to ensure that no cybersecurity issues are introduced due to weak design decisions.
To keep this article focused and practical, I will explain A04 using a specific module example.
Example Module: MQTT Broker Server Credentials
This module is responsible for setting up credentials (username and password) for the MQTT Authentication Service, which is required to connect to the MQTT Broker.
Insecure Practices Eliminated
One of the main vulnerabilities that must be rooted out in this module is:
- Fetching the password on the frontend (even in hashed form)
The involvement of passwords or authentication keys on the frontend directly contributes to Insecure Design.
Another insecure practice that must not be allowed is:
- Allowing the password-changing mechanism to proceed without verifying the original (old) password
Requiring the previous password ensures ownership verification and keeps access control intact.
Route Protection & OWASP Categorization
All routes used in this module are protected and require a server-issued token, enforced through middleware, before any real operation is performed.
Negligence in protecting such routes falls under A01 – Broken Access Control
The absence of proper route design, reasonable parameters, and a secure & safe output/result schema falls under A04 – Insecure Design
Top comments (0)