A06:2025 - Insecure Design: Security Must Be Designed In, Not Bolted On

Understanding Insecure Design in 2025

Insecure design slides two spots from fourth to sixth in the OWASP Top 10:2025 ranking as Security Misconfiguration and Software Supply Chain Failures leapfrog it. This downward movement reflects genuine progress—the industry has seen noticeable improvements in threat modeling adoption and greater emphasis on secure design since this category was introduced in 2021.

However, don't mistake position shifts for problem resolution. Insecure design remains a critical vulnerability category affecting every type of application, from simple web forms to complex distributed systems. This category focuses on risks related to design and architectural flaws, with a call for more use of threat modeling, secure design patterns, and reference architectures.

What makes insecure design particularly insidious is its fundamental nature. A secure design can still have implementation defects leading to vulnerabilities that may be exploited. An insecure design cannot be fixed by a perfect implementation as needed security controls were never created to defend against specific attacks. You cannot patch your way out of a design flaw.

The Critical Distinction: Design vs. Implementation

Understanding the difference between insecure design and insecure implementation is crucial for effective remediation. Design flaws occur during architecture and planning phases, before code is written. Implementation defects happen when developers incorrectly code a well-designed system.

Consider a payment processing system. An implementation bug might allow SQL injection due to improper input sanitization—the design called for parameterized queries, but developers used string concatenation. This can be fixed by correcting the code. In contrast, a design flaw would be architecting the system to trust client-side price calculations without server-side verification—no amount of perfect coding can fix this architectural mistake.

Insecure design represents a broad category of different weaknesses, expressed as missing or ineffective control design. One of the factors that contributes to insecure design is the lack of business risk profiling inherent in the software or system being developed, and thus the failure to determine what level of security design is required.

The Business Logic Epidemic

Business logic vulnerabilities exploit the rules governing how applications process data and manage workflows. Unlike technical vulnerabilities that break systems, these flaws manipulate legitimate functionality to achieve malicious goals.

The statistics are alarming. The 8th Annual Hacker-Powered Security Report from HackerOne found business logic flaws ranked within the top 10 most common vulnerabilities, totaling 2% of all vulnerabilities with a 5% year-over-year increase. The crypto and blockchain industries experienced an eye-watering 37% increase in business logic flaws from 2023 to 2024.

A 2023 survey by BusinessWireIndia revealed that 90% of online retailers report losing money due to misuse of discounts, loyalty points, or return policies. These aren't isolated incidents—business logic flaws exist everywhere applications have rules.

According to research from Imperva, business logic attacks against APIs increased from 17% in 2022 to 27% in 2023, representing a 59% year-over-year surge. These attacks are particularly dangerous because they use legitimate functionality against itself, making them invisible to traditional security tools.

Why Design Flaws Persist Despite Known Solutions

If secure design principles have existed for decades, why do architectural flaws continue to compromise applications in 2025?

• Security as an Afterthought
  • Most development organizations still treat security as something to add after building functionality rather than as a foundational design principle. Features, time-to-market, and user experience dominate planning discussions. Security reviews, when they occur, happen late in development when fundamental architectural decisions cannot be economically changed.
  • Research from OX Security shows fixing security flaws post-deployment can cost 100 times more than addressing them during design. Yet organizations consistently skip threat modeling and security design reviews in favor of faster feature delivery.
• Flawed Assumptions About Users and Attackers
  • Developers build systems based on how they expect users to behave, not how attackers will behave. A fundamentally flawed assumption is that users will only interact with the application via the provided web interface. This is especially dangerous because it leads to the further assumption that client-side validation will prevent users from supplying malicious input.
  • Applications assume users will follow workflows in the intended order, provide reasonable inputs, and access systems through official interfaces. Attackers, of course, bypass all these assumptions using tools like Burp Suite to manipulate requests between browser and server.
• Inadequate or Absent Threat Modeling
  • Security Compass's 2025 State of Security by Design and Threat Modeling report found that over three-quarters of security practitioners view threat modeling as a top priority, and eight out of ten anticipate its adoption to increase further. However, implementation remains inconsistent, especially among smaller organizations without dedicated security teams.
  • Without structured threat modeling, teams cannot identify attack vectors, trust boundaries, or critical security requirements. They build systems vulnerable to threats they never considered.
• Modern System Complexity
  • Modern applications involve microservices architectures, cloud platforms, third-party APIs, container orchestration, CI/CD pipelines, and increasingly, AI models. Each layer introduces potential design flaws. A misconfigured service mesh, an overly permissive API gateway, or poor segregation between tenants can all stem from design decisions rather than implementation errors.

Common Insecure Design Patterns

Understanding how design flaws manifest helps teams recognize and prevent them.

• Missing or Inadequate Rate Limiting
  • A credential recovery workflow might include questions and answers, which is prohibited by NIST 800-63b, the OWASP ASVS, and the OWASP Top 10. Beyond this specific case, authentication endpoints without rate limiting allow unlimited login attempts, enabling brute-force attacks. Password reset mechanisms without throttling can be abused for account enumeration or denial of service.
  • According to Hadrian security research, a REST API login endpoint without rate limiting becomes susceptible to brute-force attacks where attackers make unlimited login attempts. The secure design pattern involves implementing rate limiting at the architectural level—for example, allowing only five login attempts per minute per IP address.
• Business Logic Exploitation
  • Business logic vulnerabilities are context-specific but share a common characteristic: they manipulate legitimate rules to achieve malicious outcomes.
  • The OWASP documentation provides this illustrative example: 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 can find an attack vector in the business logic of the application, for example booking six hundred seats and all cinemas at once in a few requests, causing a massive loss of income.
  • Another example: A retail chain's e-commerce website does not have protection against bots run by scalpers buying high-end video cards to resell on auction websites, creating terrible publicity for the video card makers and retail chain owners, and enduring bad blood with enthusiasts who cannot obtain these cards at any price.
  • Real-world exploitation demonstrates severe financial impact. Consider this promotion scenario: An online retailer offers "Spend $100 this month, get a $25 gift card." Due to flawed logic, a user places enough orders to reach the $100 threshold and receives the gift card. They then cancel a small order, dropping below the threshold, before making a new purchase that pushes the total back over $100. The system reissues the $25 gift card, unaware it already rewarded that milestone. With careful manipulation, the user earns multiple $25 gift cards while actually spending only around $100.
• Trust Boundary Violations
  • Applications that trust client-side data without server-side validation create exploitable design flaws. PortSwigger research highlights examples: An e-commerce system accepting price values from the client allows attackers to purchase items for arbitrary amounts. A shopping cart trusting client-side price parameters without server validation enables purchasing expensive items for pennies.
  • More subtle violations involve accepting device information, user roles, or security decisions from untrusted sources. Any data crossing a trust boundary—from user to application, from internet to DMZ, from one microservice to another—must be validated and treated as potentially malicious.
• Workflow Step Skipping
  • Multi-step processes that don't enforce order or validate state transitions allow attackers to skip critical security checks. Consider an online purchase flow that validates payment in step three but doesn't verify this validation occurred before confirming the order in step four. Attackers can directly call the confirmation endpoint, bypassing payment entirely.
  • Account creation workflows that send verification emails but don't check verification status before activating accounts represent design-level vulnerabilities that implementation fixes cannot address.
• Overly Permissive APIs
  • APIs designed without data minimization principles expose more information than necessary. A social media API returning complete user profile data without checking which fields are sensitive allows attackers to extract email addresses, phone numbers, and other private details simply because the API was never designed with privacy in mind.
  • Internal APIs exposed to external networks due to architectural oversight represent another common design flaw. Development teams often assume certain APIs will only be called internally, leading them to skip authentication and authorization entirely.

Real-World Consequences of Design Failures

The impact of insecure design extends far beyond theoretical vulnerabilities.

• The USPS API Disaster (2018)
  • In November 2018, the United States Postal Service exposed information about approximately 60 million users due to flawed business logic and broken authorization. The API was designed to allow authenticated users to request their own data but lacked controls to verify users could only access their own information. This wasn't a coding error—it was a fundamental design flaw in how the API handled authorization.
  • Any regular user could access other users' email addresses, street addresses, phone numbers, and package tracking information without sophisticated technical skills. The vulnerability existed because the system never designed proper authorization checks into the API architecture.
• The Coinbase Trading API Vulnerability (2022)
  • In 2022, Coinbase disclosed and patched a critical business logic vulnerability in its Retail Advanced Trading API. Due to a missing validation check, users could manipulate API requests to trade one cryptocurrency using the balance of a different asset, violating expected logic constraints.
  • While internal protections prevented exploitation, the flaw revealed how subtle gaps in business logic—even without traditional security bugs—can expose platforms to serious risk. Coinbase responded quickly and awarded a $250,000 bounty to the researcher who responsibly reported the issue.
  • This incident demonstrates that even well-resourced organizations with mature security programs can miss design-level flaws during development.
• E-commerce Coupon Abuse
  • One well-known case involved a hacker discovering a bug on an e-commerce platform where discount codes could be reused repeatedly, even though they were meant for single use. The design never properly tracked coupon redemptions at the architectural level.
  • According to HackerOne reports, similar discount redemption flaws allow attackers to redeem the same promo multiple times, leading to significant platform losses. Even small bugs like stacking multiple offers can cost companies millions when exploited at scale.
• The Clubhouse Unprotected API (2021)
  • The audio-based social network Clubhouse was designed with the assumption that only mobile devices would access it, leading to unprotected API endpoints. When developers used browser tools to access these APIs directly, they found no authentication, no rate limiting, and no access controls.
  • This wasn't a bug—it was a fundamental design assumption that proved catastrophically wrong. The architecture never considered that API endpoints might be accessed outside the official mobile application.

The OWASP Business Logic Abuse Top 10

Recognizing the unique challenges of business logic vulnerabilities, OWASP has introduced the Business Logic Abuse Top 10 project, with the first release scheduled for May 30, 2025, at OWASP AppSec Global EU in Barcelona.

• A Novel Computational Approach
  • This project departs from traditional vulnerability frameworks by leveraging the Turing machine model to define and categorize business logic abuse. Applications are viewed as abstract machines with: Tape (representing memory or data storage such as databases and in-memory objects) and Head (representing data access mechanisms such as API calls and queries).
  • The project modeled business-logic vulnerabilities as automata by mapping Turing-machine primitives to real-world logic flows. This framing ensures the taxonomy can represent every possible logic flaw because any business rule can be expressed as a Turing machine.
• Validation with Real-World Data
  • To validate coverage, the project used large language models to classify all CVEs from 2023 to 2025—76,000 CVEs in total. After applying clustering algorithms, discarding low-confidence classifications, and removing items covered by other OWASP Top 10 categories, the result was 12 tightly-bound, high-confidence clusters of real-world exploits related to business logic abuse.
  • The methodology ensures the framework is both theoretically complete and practically aligned with real-world vulnerabilities, representing a significant evolution in how the security community addresses logic flaws.

Threat Modeling: The Foundation of Secure Design

Secure design is a culture and methodology that constantly evaluates threats and ensures that code is robustly designed and tested to prevent known attack methods. At the heart of secure design lies threat modeling.

What is Threat Modeling?

Threat modeling is the structured process of identifying, analyzing, and prioritizing potential threats to a system before they manifest as real-world attacks. It involves understanding what you're building, identifying who might attack it and why, assessing what could go wrong and how severe it could be, and determining what defenses to build from the start.

According to ISACA's Threat Modeling Revisited white paper, threat modeling should be integrated early, helping organizations make better decisions about proactively protecting their systems. When used effectively, it becomes a valuable part of any security strategy, not just for stopping attacks but for making businesses stronger and more prepared.

STRIDE Methodology

STRIDE, developed by Microsoft in the late 1990s, is the most mature and widely adopted threat modeling methodology. The acronym represents six threat categories:

• Spoofing: Can attackers impersonate legitimate users or systems?
• Tampering: Can data be maliciously modified?
• Repudiation: Can users deny actions they took?
• Information Disclosure: Can sensitive data be exposed?
• Denial of Service: Can the system be made unavailable?
• Elevation of Privilege: Can attackers gain unauthorized permissions?

STRIDE is easy to understand and provides structured approaches to identifying threats in software systems. Its model-centric approach categorizes threats, making it simpler than more comprehensive methodologies while still being effective for most applications.

PASTA Methodology

Process for Attack Simulation and Threat Analysis (PASTA) is a risk-centric methodology with seven stages. Unlike STRIDE's threat-focused approach, PASTA emphasizes understanding the attacker's perspective and aligning security with business objectives.

The seven stages include:

1. Define business objectives and security requirements
2. Define technical scope and boundaries
3. Decompose the application into components
4. Analyze threats using frameworks like STRIDE
5. Identify vulnerabilities and weaknesses
6. Model attacks and simulate exploitation
7. Analyze risks and determine mitigations

PASTA is comprehensive and focuses on realistic attack simulations, enabling a proactive approach. It incorporates continuous feedback and monitoring to adapt threat models over time. However, PASTA requires thorough understanding of attack simulation processes and can be resource-intensive due to its iterative nature.

Other Methodologies

• VAST (Visual, Agile, and Simple Threat modeling) is based on automated threat modeling tools requiring two model types: application threat models focused on application-level threats, and operational threat models focused on infrastructure and operational risks.
• OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation) focuses on organizational risks rather than purely technological risks, making it valuable for understanding business impact.
• MAESTRO (Multi-Agent Environment, Security, Threat, Risk, and Outcome) is specifically designed for agentic AI systems—autonomous, tool-using AI agents—helping security teams identify, assess, and mitigate AI-specific risks across the full lifecycle.

When and How to Threat Model

• Threat modeling should be integrated into refinement sessions (or similar activities); look for changes in data flows and access control or other security controls.
• For new projects, threat modeling should occur during initial architecture design, before major implementation decisions. For existing systems, it should happen when adding new features, adjusting existing functionality, integrating with external systems, or responding to security incidents.
• The key steps include understanding system architecture by documenting components, data flows, trust boundaries, and entry points. Teams identify assets worth protecting—sensitive data, critical functionality, and privileged access. They enumerate potential threats using methodologies like STRIDE, assess likelihood and impact, then determine appropriate mitigations.

Secure Design Patterns and Principles

Beyond threat modeling, several patterns and principles enable secure design.

• Defense in Depth
  • Never rely on a single security control. Layer multiple defensive mechanisms so that if one fails, others still provide protection. For authentication, this means combining strong passwords with multi-factor authentication, session management, and anomaly detection. For data protection, this means encryption at rest, encryption in transit, access controls, and audit logging.
• Principle of Least Privilege
  • Grant the minimum permissions necessary for functionality. Users should only access data and features they need. Services should run with minimal system privileges. API keys should have scoped permissions rather than global access. Database accounts should be limited to specific tables and operations.
• Fail Securely
  • When errors occur, systems should fail in a secure state rather than an insecure one. Authentication failures should deny access, not grant it. Validation errors should reject input, not accept it. Resource exhaustion should gracefully degrade functionality rather than exposing vulnerabilities.
• Complete Mediation
  • Check permissions for every access, not just initially. Don't assume that because a user was authorized initially, they remain authorized for subsequent operations. Re-validate privileges for sensitive operations. Check authorization at each tier, not just at the edge.
• Separation of Duties
  • Critical operations should require multiple parties. Financial transactions above certain thresholds should require approval. Administrative changes should require peer review. Deployment to production should require separate deployment and approval roles.

Implementing Secure Design in Practice

Translating principles into practice requires concrete processes and cultural changes.

• Security Requirements Early
  • Collect and negotiate the business requirements for an application with the business, including the protection requirements concerning confidentiality, integrity, availability, and authenticity of all data assets and the expected business logic.
  • Security requirements should be first-class requirements, not afterthoughts. For a payment processing system, requirements might specify all payment data must be encrypted in transit using TLS 1.3 or higher, cardholder data must be encrypted at rest using AES-256, payment processing must complete within 5 seconds or rollback, and all payment activities must be logged with immutable audit trails.
• Abuse Case Development
  • In the user story development, determine the correct flow and failure states, ensure they are well understood and agreed upon by the responsible and impacted parties.
  • For every use case, develop corresponding abuse cases that describe how attackers might misuse functionality. For a password reset feature, use cases describe legitimate users requesting and completing password resets. Abuse cases describe attackers attempting to enumerate valid accounts, lock out legitimate users, or social engineer support staff.
• Architecture and Design Reviews
  • Conduct security-focused architecture reviews before implementation. These reviews should examine trust boundaries and data flows, authentication and authorization mechanisms, data classification strategies, third-party integration security implications, and resilience to common attack patterns.
  • Integrate security language and controls into user stories and integrate plausibility checks at each tier of your application from frontend to backend.
• Security Testing for Design Validation
  • Write unit and integration tests to validate that all critical flows resist the threat model. Tests should verify not just that features work, but that security controls cannot be bypassed.
  • For business logic, tests should verify rate limits cannot be exceeded, workflow steps cannot be skipped, negative values are rejected, concurrent operations maintain data integrity, and privilege escalation attempts fail.

Detection Challenges

Unlike injection vulnerabilities or authentication failures, insecure design issues are often the most critical in terms of consequences but also the hardest to detect.

Traditional scanners aren't designed to find business logic flaws. As one security researcher notes, Web Application Firewalls won't even understand there's anything wrong because attackers are simply using the application within the rules, easily bypassing WAF detection.

Invicti security research confirms that insecure design was controversial when first added to the OWASP Top 10 in 2021 as the first non-testable category. The remediation requires threat modeling during the design phase, a practice gaining traction but still far from universal.

According to Equixly analysis, automated API security testing can systematically verify that rate limits are enforced, authentication is required, authorization boundaries are respected, state transitions are validated, and business rules are consistently applied. In other words, it turns design requirements into continuously validated controls.

However, manual testing driven by real-world scenarios remains essential. Security professionals must truly understand the business to understand business logic vulnerabilities. If you don't understand what the business is trying to achieve, you cannot see business logic flaws.

Organizational Culture and Secure Design

Technical practices alone aren't sufficient. Organizational culture must support secure design.

• Security as Shared Responsibility
  • Often self-responsibility of developers is underappreciated. Foster a culture of awareness, responsibility and proactive risk mitigation.
  • Security cannot be the sole responsibility of a security team. Developers must understand security implications of design decisions. Architects must consider security as a first-class architectural concern. Product managers must prioritize security requirements alongside functional requirements.
• Executive Support
  • Leadership must support security design activities with adequate time, budget, and authority. This means allocating time for threat modeling in project schedules, investing in training and tools, empowering security teams to block insecure designs, and measuring security outcomes alongside delivery velocity.
• Incentive Alignment
  • Reward teams for identifying and fixing design flaws early rather than only rewarding feature delivery. Celebrate teams that discover vulnerabilities during design reviews. Recognize individuals who improve security processes. Make security expertise a valued career path.
• Regular Security Exchanges
  • Regular exchanges about security (e.g. during threat modeling sessions) can generate a mindset for including security in all important design decisions.
  • These discussions help developers internalize security thinking rather than viewing it as an external constraint imposed by security teams.

Tools and Automation

While threat modeling requires human judgment, tools can help scale the practice.

• Threat Modeling Tools
  • Modern threat modeling tools provide diagramming capabilities for visualizing architectures, threat libraries with common patterns, automated threat identification based on component types and data flows, integration with development tools and workflows, and reporting and metrics for tracking progress.
  • Tools like OWASP Threat Dragon, Microsoft Threat Modeling Tool, ThreatModeler, and IriusRisk help teams systematically document architectures and identify threats. The key is choosing tools that fit your workflow rather than forcing workflow changes to accommodate tools.
• AI-Assisted Threat Modeling
  • Emerging AI capabilities can assist with threat modeling by suggesting threats based on architecture patterns, identifying similar systems and their known vulnerabilities, generating abuse cases from use cases, and highlighting inconsistencies in security controls.
  • However, AI should augment human expertise, not replace it. Contextual understanding of business logic, organizational risk tolerance, and specific deployment environments still requires human judgment.
• Automated Testing
  • Automated testing can validate that security controls designed in threat modeling actually work. API security testing tools can systematically verify authentication requirements, authorization boundaries, rate limiting enforcement, input validation, and data exposure controls.
  • Platforms like APIsec's fully automated API security testing identify business logic vulnerabilities at scale, helping organizations ensure design requirements translate into working protections.
  • The Path Forward; As a community, we need to move beyond shift-left in the coding space, to pre-code activities such as requirements writing and application design, that are critical for the principles of Secure by Design.
  • The drop in Insecure Design's ranking from fourth to sixth reflects real progress. Organizations are increasingly adopting threat modeling, considering security earlier in the design phase, using secure architecture patterns, and building security into requirements.
  • However, significant challenges remain. Business logic attacks continue rising rapidly, with a 59% year-over-year increase. Automated scanners cannot find design flaws, requiring human expertise, manual testing, and deep business context. The real financial impact remains severe, from unlimited coupon exploitation to race condition-based theft in banking systems.
  • GitLab's analysis of the 2025 OWASP Top 10 emphasizes that supply chain security is critical, with Software Supply Chain Failures added as a new high-impact category. Organizations should implement SBOM tracking, dependency scanning, and integrity verification throughout their pipelines.
  • For insecure design specifically, GitLab recommends using Code Suggestions for proactive guidance during development, suggesting secure design patterns like proper password hashing and encrypted storage mechanisms. Security Analyst Agents can review detected insecure design vulnerabilities in context, explaining architectural implications and providing remediation strategies that address root design flaws rather than symptoms.
  • Continuous Improvement; Learn from mistakes and offer positive incentives to promote improvements. Security design isn't a one-time activity but an ongoing practice.
• Incident Post-Mortems
  • When security incidents occur, conduct blameless post-mortems that identify design-level root causes. If an incident exploited missing rate limiting, don't just add rate limiting to that one endpoint—implement organization-wide design standards for rate limiting all authentication and sensitive endpoints.
• Security Champions Program
  • Designate security champions within development teams who receive advanced training in secure design and threat modeling. These champions help review designs for security issues, advocate for security best practices, and serve as a bridge between security and development teams.
• Evolving Threat Models
  • Threat models must evolve as systems change and new threats emerge. Schedule regular threat model reviews, especially when adding features, changing architecture, integrating with external systems, or when new attack techniques emerge in the industry.
  • Cloud Security Alliance's Cloud Threat Modeling 2025 guidance emphasizes building continuous, adaptive models that reflect real-time system changes, enhancing resilience and enabling proactive security decisions across complex, distributed environments.

Conclusion

✅ Insecure design represents a fundamental category of vulnerabilities that cannot be patched away. When security controls are never designed in the first place, no amount of perfect implementation can compensate.

✅ Secure software requires a secure development lifecycle, a secure design pattern, a paved road methodology, a secure component library, appropriate tooling, threat modeling, and incident post-mortems that are used to improve the process.

✅ The good news is that the tools, methodologies, and knowledge exist to design secure systems. Threat modeling frameworks like STRIDE and PASTA provide structured approaches. Secure design patterns offer proven solutions to common problems. Automated tools can scale security practices across large organizations. The emerging OWASP Business Logic Abuse Top 10 provides a comprehensive framework for understanding these critical flaws.

✅ What's needed now is organizational commitment to making security a core design principle rather than an implementation afterthought. This means allocating time for threat modeling in project plans, training developers in secure design, empowering security teams to influence architecture, measuring security design outcomes, and building cultures where security is everyone's responsibility.

✅ The shift from insecure to secure design isn't easy, but it's necessary. As applications grow more complex, attacks more sophisticated, and consequences more severe, building security into foundations rather than bolting it on afterwards isn't just best practice—it's the only viable path forward.

✅ By embracing threat modeling, implementing secure design patterns, validating security requirements through testing, continuously evolving security designs, and fostering cultures of security awareness, organizations can move beyond treating symptoms to addressing root causes. The future of application security lies not in finding and fixing more bugs, but in designing systems where entire classes of vulnerabilities cannot exist.

✅ Establish and use a secure development lifecycle with AppSec professionals to help evaluate and design security and privacy-related controls. Reach out to security specialists at the beginning of projects, throughout development, and for ongoing maintenance. Consider leveraging the OWASP Software Assurance Maturity Model (SAMM) to structure secure software development efforts.

✅ The industry's progress on insecure design, reflected in its movement from fourth to sixth position, shows that change is possible. With sustained effort, rigorous threat modeling, and organizational commitment to security-by-design principles, we can continue this positive trajectory and build a future where fundamental architectural flaws become increasingly rare.