OWASP Top 10 2025: Application Design Flaws

Security Misconfigurations

What It Is
Security misconfigurations happen when systems, servers, or applications are deployed with unsafe defaults, incomplete settings, or exposed services. These are not code bugs but mistakes in how the environment, software, or network is set up. They create easy entry points for attackers.

Why It Matters
Even small misconfigurations can expose sensitive data, enable privilege escalation, or give attackers a foothold into the system. Modern applications rely on complex stacks, cloud services, and third-party APIs. A single exposed admin panel, an open storage bucket, or misconfigured permissions can compromise the entire system.

Example
In 2017, Uber exposed a backup AWS S3 bucket with sensitive user data, including driver and rider information, because the bucket was publicly accessible. Attackers could download data directly without needing credentials. This shows how a deployment mistake can lead to a significant breach.

Common Patterns

• Default credentials or weak passwords left unchanged
• Unnecessary services or endpoints exposed to the internet
• Misconfigured cloud storage or permissions (S3, Azure Blob, GCP buckets)
• Unrestricted API access or missing authentication/authorisation
• Verbose error messages exposing stack traces or system details
• Outdated software, frameworks, or containers with known vulnerabilities
• Exposed AI/ML endpoints without proper access controls

How To Prevent It

• Harden default configurations and remove unused features or services
• Enforce strong authentication and least privilege across all systems
• Limit network exposure and segment sensitive resources
• Keep software, frameworks, and containers up to date with patches
• Hide stack traces and system information from error messages
• Audit cloud configurations and permissions regularly
• Secure AI endpoints and automation services with proper access controls and monitoring
• Integrate configuration reviews and automated security checks into your deployment pipeline

Challenge

Navigate to MACHINE_IP:5002. It appears that the developers left too many traces in their User Management APIs.

Software Supply Chain Failures

What It Is
Software supply chain failures happen when applications rely on components, libraries, services, or models that are compromised, outdated, or improperly verified. These weaknesses are not inherent in your code, but rather in the software and tools you depend on. Attackers exploit these weak links to inject malicious code, bypass security, or steal sensitive data.

Why It Matters
Modern applications are built from many third-party packages, APIs, and AI models. One compromised dependency can compromise your entire system, allowing attackers to gain access without ever touching your own code. Supply chain attacks can be automated and distributed, making them hard to detect and very damaging.

Example
In 2021, the SolarWinds Orion compromise showed the danger of supply chain attacks. Attackers inserted malicious code into a trusted update, affecting thousands of organisations that automatically installed it. This wasn’t a bug in SolarWinds’ core logic. It was a flaw in the software update building, verification, and distribution process.

With AI, we can observe this when using unverified third-party models or fine-tuned datasets that can embed hidden behaviours, backdoors, or biased outputs, compromising systems or leaking data.

Common Patterns

• Using unverified or unmaintained libraries and dependencies
• Automatically installing updates without verification
• Over-reliance on third-party AI models without monitoring or auditing
• Insecure build pipelines or CI/CD processes that allow tampering
• Poor license or provenance tracking for components
• Lack of monitoring for vulnerabilities in dependencies after deployment

How To Protect The Supply Chain

• Verify all third-party components, libraries, and AI models before use
• Monitor and patch dependencies regularly
• Sign, verify, and audit software updates and packages
• Lock down CI/CD pipelines and build processes to prevent tampering
• Track provenance and licensing for all dependencies
• Implement runtime monitoring for unusual behaviour from dependencies or AI components
• Integrate supply chain threat modelling into the SDLC, including testing, deployment, and update workflows

Challenge

Navigate to MACHINE_IP:5003. The code is outdated and imports an old lib/vulnerable_utils.py component. It needs to be patched ASAP!

Cryptographic Failures

What It Is
Cryptographic failures happen when encryption is used incorrectly or not at all. This includes weak algorithms, hard-coded keys, poor key handling, or unencrypted sensitive data. These flaws let attackers access information that should be private.

Why It Matters
Web applications rely on cryptography everywhere: protecting network traffic, securing stored data, verifying identities, and safeguarding secrets. When these controls fail, sensitive data such as passwords, tokens, or personal information can be exposed, leading to account takeovers or full-scale breaches.

Attackers can exploit these flaws through man-in-the-middle attacks, brute-force attacks on weak keys, or by simply discovering secrets that were never properly protected.

Common Patterns 

• Using deprecated or weak algorithms like MD5, SHA-1, or ECB mode
• Hard-coded secrets in code or configuration
• Poor key rotation or management practices
• Lack of encryption for sensitive data at rest or in transit
• Self-signed or invalid TLS certificates
• Using AI/ML systems without proper secret handling for model parameters or sensitive inputs

How To Prevent It

• Use strong, modern algorithms such as AES-GCM, ChaCha20-Poly1305, or enforce TLS 1.3 with valid certificates
• Use secure key management services like Azure Key Vault, AWS KMS, or HashiCorp Vault
• Rotate secrets and keys regularly, following defined crypto periods
• Document and enforce policies and standard operating procedures for key lifecycle management
• Maintain a complete inventory of certificates, keys, and their owners
• Ensure AI models and automation agents never expose unencrypted secrets or sensitive data
• The web application in this room contains a weakness of this type for you to explore.

Challenge

Navigate to MACHINE_IP:5004. Can you find the key to decrypt the file?

Insecure Design

What It Is

Insecure design happens when flawed logic or architecture is built into a system from the start. These flaws stem from skipped threat modelling, no design requirements or reviews, or accidental errors.

Moreover, with the introduction of AI assistants, AI systems exacerbate insecure design. Developers often assume that models are safe, correct, or predictable, or that the code they produce is flaw-free. When an AI system can generate queries, write code, or classify users without limits, the risk is built into the design, leading to poor architectural patterns.

Example
A good example is Clubhouse. Its early design assumed users would only interact through the mobile app, but the backend API had no proper authentication. Anyone could query user data, room info, and even private conversations directly. When researchers tested it, "he entire "private c "nversation" premise fell apart.

Why It Matters
You can't patch an insecure design. It's built into the workflow, logic, and trust boundaries. Fixing it means rethinking how systems, and now AI, make decisions.

Common Insecure Designs In 2025

• Weak business logic controls, like recovery or approval flows
• Flawed assumptions about user or model behaviour
• AI components with unchecked authority or access
• Missing guardrails for LLMs and automation agents
• Test or debug bypasses left in production
• No consistent abuse-case review or AI threat modelling

Insecure Design In The AI Era

AI introduces new kinds of design failures. For example, prompt injection occurs when user input is blended with system prompts, allowing attackers to hijack the context or extract hidden data. Blind trust in model output creates fragile systems that act on AI decisions without validation or oversight, which is why human review remains necessary. When it comes to poisoned models, pulled from unverified sources or fine-tuned on unsafe data, they can embed hidden behaviours or backdoors that compromise the system from within.

How To Design Securely

• Treat every model as untrusted until proven otherwise.
• Validate and filter all model inputs and outputs to ensure accuracy and integrity.
• Separate system prompts from user content.
• Keep sensitive data out of prompts unless absolutely needed and protect it with strict controls.
• Require human review for high-risk AI actions.
• Log model provenance, monitor behaviour, and apply differential privacy for sensitive data.
• Include AI-specific threat modelling for prompt attacks, inference risks, agent misuse, and supply chain compromise throughout the design process.
• Build threat modelling into every stage of development, not just at the start.
• Define clear security requirements for each feature before implementation.
• Apply the principle of least privilege across users, APIs, and services.
• Ensure proper authentication, authorisation, and session management across the system.
• Keep dependencies, third-party components, and supply chain sources verified and up to date.
• Continuously monitor and test the system for logic flaws, abuse paths, and emergent risks as new features or AI components are added.

Challenge

Navigate to MACHINE_IP:5005. Have they assumed that only mobile devices can access it?

Conclusion

Security design failures across AS02 Security Misconfigurations, AS03 Software Supply Chain Failures, AS04 Cryptographic Failures, and AS06 Insecure Design all come from the same root cause: weak foundations. You cannot add security at the end and expect it to work. Strong systems start with clear security requirements, realistic threat assumptions, controlled configurations, vetted dependencies, and sound cryptographic choices.

Treat defaults with suspicion, treat every dependency as a potential risk, and keep design simple enough to reason about. Get the design right early, and you avoid a long future of preventable incidents.

Continue the journey with Room 3 in this module: Application Design Flaws: https://tryhackme.com/jr/owasptop102025insecuredatahandling