This article was originally published on the personal blog of the founder of CrossWise InfoTech and is republished here with edits.<\/p>\n\n\n\n
OWASP Top 10 2025 Risk #6 \u2014 \u201cInsecure Design\u201d<\/strong> \u2014 represents a true intersection between software engineering and cybersecurity, yet it remains the most common \u201cgray area\u201d where both sides tend to deflect responsibility or selectively ignore the issue.<\/p>\n\n\n\n Cybersecurity practitioners often label it as \u201ca developer\u2019s problem,\u201d arguing that surgical, tactical security measures are largely ineffective against design flaws deeply embedded in business logic. Conversely, software engineers habitually respond: \u201cIf the design is flawed, it\u2019s because the business demanded it\u2014it\u2019s not a vulnerability.\u201d The unspoken message? Business comes first; security can wait.<\/p>\n\n\n\n This cognitive disconnect\u2014and the failure of both sides to grasp the root cause\u2014is why A06 persists.<\/p>\n\n\n\n Insecure Design is not merely a coding defect<\/strong>. It is a structural risk seeded as early as the requirements analysis phase<\/strong>. The crux lies in whether the systems analyst conducting requirements elicitation possesses sufficient risk-awareness and the ability to infer threat vectors from business logic\u2014only then can design and implementation teams respond cohesively.<\/p>\n\n\n\n I present two real-world cases encountered personally:<\/p>\n\n\n\n 1) Experience-Based Inertia<\/strong><\/p>\n\n\n\n In Industrial IoT (IIoT), a common design inertia stems from the assumption that devices reside in physically isolated internal networks. Developers thus transmit control commands (e.g., start\/stop, parameter adjustments) in plaintext over the network. While risky even in closed environments, the limited attack surface renders it a \u201cmanageable risk.\u201d<\/p>\n\n\n\n However, when this same logic is directly ported to consumer-facing, internet-connected IoT systems, uncontrolled risks emerge. Attackers can enumerate API endpoints, replay requests, or tamper with parameters to bypass authentication and directly manipulate devices.<\/p>\n\n\n\n For example, consider this device API:<\/p>\n\n\n\n If the API lacks proper access controls on the device ID ( Critically, if no authorization model was ever designed<\/strong>, this isn\u2019t \u201cbroken access control\u201d\u2014it\u2019s Insecure Design by omission<\/strong>. Code audits can confirm this distinction.<\/p>\n\n\n\n The root cause isn\u2019t poor coding skill, but design inertia<\/strong>: the failure to treat \u201cresource ownership\u201d and \u201coperation authorization\u201d as core business rules during system modeling.<\/p>\n\n\n\n 2) Risk-Embedded Business Models<\/strong><\/p>\n\n\n\n Beyond violations of explicit security principles, Insecure Design also manifests more subtly:<\/p>\n\n\n\n When the business logic model itself constitutes a risk.<\/strong><\/p>\n\n\n\n Such issues are hard to detect but must be identified proactively during analysis<\/strong>\u2014not deferred to design, implementation, or post-deployment discovery, where remediation may be catastrophic.<\/p>\n\n\n\n Take an O2O online booking flow: <\/p>\n\n\n\n users proceed through steps like selecting a store \u2192 service type \u2192 parameters \u2192 time slot \u2192 payment method \u2192 payment initiation \u2192 post-payment processing. Each step triggers at least one API call.<\/em><\/p>\n\n\n\n From a pure business view, these steps seem necessary to guide users smoothly through the journey. Aligning APIs with this flow appears \u201clogical.\u201d<\/p>\n\n\n\n But from a risk perspective, this design multiplies the attack surface by N<\/strong>, where N equals the number of APIs. A single vulnerable endpoint compromises the entire system.<\/p>\n\n\n\n Both examples demand architectural and process-level fixes<\/strong>\u2014no \u201csurgical\u201d security tool can compensate.<\/p>\n\n\n\n For Case 1:<\/strong> Obfuscate sensitive parameters and implement robust authentication\/authorization.<\/p>\n\n\n\n Critics may ask: \u201cDoes obfuscation justify added complexity?\u201d<\/p>\n\n\n\n Yes\u2014and crucially, obfuscation is just one means to achieve Confidentiality (C)<\/strong>. The CIA triad (Confidentiality, Integrity, Availability<\/strong>) must be balanced:<\/p>\n\n\n\n Patterns like JWT or external-to-internal ID mapping are viable\u2014but selection must follow a holistic CIA assessment.<\/p>\n\n\n\n For Case 2:<\/strong> Replace step-by-step APIs with a single \u201cfetch service configuration\u201d endpoint. Let the frontend handle all user interactions, and submit the complete order only at payment initiation, with full backend validation.<\/p>\n\n\n\n This approach requires software engineers to deeply understand business logic during analysis<\/strong>, avoid rigid adherence to legacy workflows, and recognize that decoupling frontend logic from backend APIs enhances both flexibility and robustness.<\/p>\n\n\n\n Ultimately, the cost of secure design cannot be judged by short-term ROI. Like database transactions or audit logging, security is not optional\u2014it\u2019s a core quality attribute<\/strong>. As analysts or architects, we must treat security as a non-functional requirement<\/strong> from day one and quantify its impact on reliability and compliance.<\/p>\n\n\n\n Many security professionals still equate Insecure Design with \u201cBroken Access Control\u201d\u2014a misconception.<\/p>\n\n\n\n The essence of Insecure Design is the absence of mechanisms to constrain risk generation<\/strong>.<\/p>\n\n\n\n Broken Access Control assumes a permission model exists; Insecure Design is far broader. Even analyzing resource ownership or role-action mappings captures only surface-level risks. True understanding requires a systemic view of risk exposure<\/strong>, as illustrated in Case 2: multiplying APIs exponentially increases systemic fragility.<\/p>\n\n\n\n This blind spot stems from the chasm between security and business<\/strong>. As I\u2019ve argued before:<\/p>\n\n\n\n Security, if not integrated into business, will be marginalized\u2014or ignored entirely.<\/strong><\/p>\n<\/blockquote>\n\n\n\n For executives: Should CIO and CISO remain separate roles? My answer is no<\/strong>.<\/p>\n\n\n\n For practitioners: If your security reviews don\u2019t engage with business-aligned artifacts\u2014system design docs, data flow diagrams, permission models, and functional workflows\u2014you\u2019re not truly integrated.<\/p>\n\n\n\n The most dangerous mindset in software development is:<\/p>\n\n\n\n \u201cGet it working first; add security later.\u201d<\/strong><\/p>\n<\/blockquote>\n\n\n\n This \u201cagile procrastination\u201d is fatal for Insecure Design. Once data models, APIs, and permission schemes solidify, changes become exponentially costly.<\/p>\n\n\n\n This also impacts economic auditing<\/strong> (a domain I specialize in):<\/p>\n\n\n\n An application patched post-breach does not gain value<\/strong> from security investments\u2014on the contrary, such spending confirms material defects<\/strong>, warranting asset impairment<\/strong>.<\/p>\n\n\n\n In IP valuation or M&A contexts, this can nullify value entirely. Who would buy a system that required massive post-hoc security fixes? How can buyers trust no other critical flaws remain?<\/p>\n\n\n\n Thus, Secure by Design<\/strong> means:<\/p>\n\n\n\n Security is not a feature\u2014it\u2019s a foundational system capability.<\/strong><\/p>\n<\/blockquote>\n\n\n\n It demands that risk awareness permeate our very first UML diagram and use case.<\/p>\n\n\n\n Systems analysts are the first line of defense for cybersecurity.<\/strong><\/p>\n\n\n\n Though rooted in my background (IS auditor + systems analyst + software engineering MSc), this discussion holds vital lessons for pure-play security practitioners:<\/p>\n\n\n\n Future-proof security talent must stand at the intersection of software engineering and cybersecurity.<\/strong><\/p>\n<\/blockquote>\n\n\n\n The era of \u201cBurp Suite warriors\u201d brute-forcing APIs is ending\u2014AI will automate repetitive tasks. Organizations now need bridge-builders<\/strong>: professionals who can read architecture diagrams, contribute to requirements reviews, and operationalize threat modeling. In short: those who can judge whether a design introduces unacceptable risk<\/strong>.<\/p>\n\n\n\n Because today, security is inseparable from modern software engineering<\/strong>.<\/p>\n","protected":false},"excerpt":{"rendered":" This article was originally published on the personal blog of the founder of CrossWise InfoTech and is republished here with edits. I. Introduction OWASP Top 10 2025 Risk #6 \u2014 \u201cInsecure Design\u201d \u2014 represents a true intersection between software engineering and cybersecurity, yet it remains the most common \u201cgray area\u201d where both sides tend to […]<\/p>\n","protected":false},"author":1,"featured_media":290,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[12,15],"class_list":["post-280","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-it_project","tag-12","tag-15"],"aioseo_notices":[],"jetpack_featured_media_url":"https:\/\/crosswise.hk\/wp-content\/uploads\/2026\/02\/banner.jpg","_links":{"self":[{"href":"https:\/\/crosswise.hk\/en\/wp-json\/wp\/v2\/posts\/280","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/crosswise.hk\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/crosswise.hk\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/crosswise.hk\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/crosswise.hk\/en\/wp-json\/wp\/v2\/comments?post=280"}],"version-history":[{"count":3,"href":"https:\/\/crosswise.hk\/en\/wp-json\/wp\/v2\/posts\/280\/revisions"}],"predecessor-version":[{"id":283,"href":"https:\/\/crosswise.hk\/en\/wp-json\/wp\/v2\/posts\/280\/revisions\/283"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/crosswise.hk\/en\/wp-json\/wp\/v2\/media\/290"}],"wp:attachment":[{"href":"https:\/\/crosswise.hk\/en\/wp-json\/wp\/v2\/media?parent=280"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/crosswise.hk\/en\/wp-json\/wp\/v2\/categories?post=280"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/crosswise.hk\/en\/wp-json\/wp\/v2\/tags?post=280"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}II. Typical Scenarios Leading to Insecure Design<\/h2>\n\n\n\n
POST \/api\/v1\/device\/12345\/control\nBody: { \"action\": \"set_max_op_mins\", \"value\": 30 }<\/code><\/pre>\n\n\n\n12345<\/code>)\u2014such as verifying user identity, permissions, or requiring a valid access token (clearly absent here)\u2014attackers may brute-force device IDs, reconstruct valid payloads, and remotely control devices, causing physical damage and financial loss.<\/p>\n\n\n\nIII. Solutions from a Software Engineering Perspective<\/h2>\n\n\n\n
\n
IV. Reinterpreting Insecure Design from a Cybersecurity Lens<\/h2>\n\n\n\n
\n
V. There Are No Shortcuts in Secure Design<\/h2>\n\n\n\n
\n
\n
VI. Where Do Cybersecurity Professionals Go From Here?<\/h2>\n\n\n\n
\n