After exploring IAAA (Identity, Authentication, Authorization, and Accountability) failures in the previous room, I moved on to what many consider the most challenging category of vulnerabilities to fix: Application Design Flaws. Unlike authentication bypasses or broken access controls that can often be patched with code changes, design flaws are baked into the architecture from day one. They represent fundamental mistakes in how systems are conceived, built, and deployed—mistakes that often require complete architectural redesigns to fix properly.
This TryHackMe room covers four critical OWASP Top 10 2025 categories that all stem from weak foundations: A02: Security Misconfigurations, A03: Software Supply Chain Failures, A04: Cryptographic Failures, and A06: Insecure Design. What makes these vulnerabilities particularly dangerous is that they're not the result of a single coding error or oversight—they're systemic failures that affect entire applications, infrastructure stacks, and even organizational security postures.
The reality of modern application development is that we're building on top of countless layers of abstraction: cloud services, third-party libraries, container orchestration platforms, CI/CD pipelines, AI models, and automation frameworks. Each layer introduces potential points of failure. A misconfigured S3 bucket, a compromised npm package, a hardcoded encryption key, or an API endpoint that trusts client-side device information—any of these can serve as the entry point for a complete system compromise.
What struck me most about these vulnerabilities is their persistence in the wild despite being well-documented for years. The 2017 Uber data breach from a misconfigured AWS S3 bucket, the 2021 SolarWinds supply chain attack affecting thousands of organizations, and the 2021 Clubhouse API exposure allowing unauthenticated access to private conversations—these aren't theoretical scenarios. They're real incidents that caused massive damage, and similar vulnerabilities continue to be discovered daily.
In this room, I got hands-on experience exploiting each of these design flaw categories. From discovering verbose error messages that leak sensitive information, to exploiting outdated dependencies with known vulnerabilities, to breaking weak encryption implementations, and bypassing mobile-only access controls through simple User-Agent manipulation. Each challenge reinforced a critical lesson: you cannot bolt security onto a flawed foundation and expect it to hold.
The challenges in this room taught me to think like both an attacker and a defender. As an attacker, I learned to look beyond the obvious—checking for exposed APIs, enumerating endpoints, reading JavaScript files for hardcoded secrets, and questioning architectural assumptions. As a defender, I learned that security must be designed in from the beginning, not added as an afterthought.
Let's dive into each category and explore not just how to exploit these design flaws, but more importantly, how to prevent them from being built into systems in the first place.
Introduction
This room breaks each 4 of the OWASP Top 10 2025 categories. In this room, you will learn about the categories that are related to failures in architecture and system design. You will put the theory into practice by completing supporting challenges. The following categories are covered in this room:
AS02: Security Misconfigurations
AS03: Software Supply Chain Failures
AS04: Cryptographic Failures
AS06: Insecure Design
AS02: Security Misconfigurations
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.
Answer the questions below
What's the flag? THM{V3RB0S3_3RR0R_L34K}
AS03: Software Supply Chain Failures
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. Can you debug it?
Answer the questions below
What's the flag? THM{SUPPLY_CH41N_VULN3R4B1L1TY}
sending POST request of /api/process on the repeater of Burp Suite reveals the flag
AS04: Cryptographic Failures
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?
Answer the questions below
What's the flag? THM{CRYPTO_FAILURE_H4RDCOD3D_K3Y}
Looking around on the site, there’s a key on the landing page, but trying to decode on B64 decode or any other it’s not decryptable, meaning there might be a script that we’re expected to use this key on. Running Gobuster isn’t of help; it only shows a console directory, which we can’t navigate to on the site.
Back on the site, when we inspect or check the dev tools. There’s a JavaScript file that is shown under the script /static/js/decrypt.js It is easy to run a Python script over a JavaScript, so I converted the script into Python and then replaced the "my-secret-key-16" with the key that was on the landing page
nano decrypt.py
python3 decrypt.py
from Crypto.Cipher import AES
from Crypto.Util.Padding import unpad
import base64
key = b"my-secret-key-16"
encrypted_base64 = "Nzd42HZGgUIUlpILZRv0jeIXp1WtCErwR+j/w/lnKbmug31opX0BWy+pwK92rkhjwdf94mgHfLtF26X6B3pe2fhHXzIGnnvVruH7683KwvzZ6+QKybFWaedAEtknYkhe"
encrypted_data = base64.b64decode(encrypted_base64)
cipher = AES.new(key, AES.MODE_ECB)
decrypted_padded = cipher.decrypt(encrypted_data)
try:
decrypted = unpad(decrypted_padded, AES.block_size)
print(decrypted.decode('utf-8'))
except Exception as e:
print(decrypted_padded.decode('utf-8', errors='ignore'))
AS06: Insecure Design
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?
Answer the questions below
What's the flag? THM{1NS3CUR3_D35IGN_4SSUMPT10N}
Gobuster doesn’t reveal all directories, but you have to keep trying to check the site and using Gobuster till you find the flag…the documentation mentions api, users, and remember it’s a private chat application, so there’s a chance there are messages that’s why we eventually got the api/messages path working
gobuster dir -u http://IP_Address:5005/api -w /usr/share/wordlists/dirb/common.txt -x php,txt,html,js
gobuster dir -u http://IP_Address:5005/api/users -w /usr/share/wordlists/dirb/common.txt -x php,txt,html,js
http://IP_Address/api/users
gobuster dir -u http://IP_Address:5005/api/users/admin -w /usr/share/wordlists/dirb/common.txt -x php,txt,html,js
http://IP_Address/api/users/admin
http://IP_Address/api/users/user1
http://IP_Address/api/users/user2
gobuster dir -u http://IP_Address:5005/api/messages -w /usr/share/wordlists/dirb/common.txt -x php,txt,html,js
http://IP_Address/api/messages/admin
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
Completing this OWASP Top 10 2025 Application Design Flaws room was a masterclass in understanding that security failures often start at the design phase, not the implementation phase. The four categories covered—Security Misconfigurations, Software Supply Chain Failures, Cryptographic Failures, and Insecure Design—all share a common thread: they represent fundamental architectural weaknesses that cannot be simply patched away.
Key Takeaways from Each Category
A02: Security Misconfigurations taught me that even the smallest oversight in configuration can have catastrophic consequences. The challenge where verbose error messages leaked the flag demonstrated how developers often leave debugging information, stack traces, and internal system details exposed in production environments. These "helpful" error messages that make development easier become goldmines for attackers during reconnaissance. The lesson: harden everything, assume production will be probed, and never trust default configurations.
In real-world scenarios, misconfigurations are shockingly common:
Default admin credentials left unchanged
Cloud storage buckets set to public access
Debug endpoints exposed to the internet
API authentication disabled "temporarily" and forgotten
Overly permissive CORS policies
Detailed error pages showing stack traces, database queries, and file paths
The fix isn't just about toggling a setting—it's about establishing a security baseline, conducting regular configuration audits, and integrating automated security checks into deployment pipelines.
A03: Software Supply Chain Failures revealed the hidden danger lurking in our dependency trees. By exploiting an outdated lib/vulnerable_utils.py component through a POST request to /api/process in Burp Suite, I saw firsthand how a single compromised dependency can undermine an entire application's security. Modern applications aren't built from scratch—they're assembled from hundreds or thousands of third-party packages, libraries, frameworks, and now AI models.
The SolarWinds breach mentioned in the room demonstrates this perfectly: attackers compromised the build process, injected malicious code into a trusted update, and suddenly thousands of organizations that automatically installed updates became victims. This wasn't about finding a bug—it was about poisoning the well that everyone drinks from.
Critical supply chain security practices include:
Dependency scanning and vulnerability monitoring (tools like Dependabot, Snyk, or OWASP Dependency-Check)
Software Bill of Materials (SBOM) tracking
Package verification and checksum validation
Private package registries for internal dependencies
CI/CD pipeline security and access controls
Regular dependency updates (but with testing!)
Monitoring for unusual behavior in dependencies at runtime
With the rise of AI/ML, supply chain risks have expanded to include pre-trained models, fine-tuned datasets, and third-party AI services that could contain backdoors, biases, or data exfiltration mechanisms.
A04: Cryptographic Failures was eye-opening in showing how developers often implement encryption incorrectly, rendering it useless. Finding the hardcoded key "my-secret-key-16" in the JavaScript file /static/js/decrypt.js and using it to decrypt the supposedly "secure" document exemplifies one of the most common crypto failures: hardcoding secrets in source code.
The vulnerability chain I exploited:
Inspected page source → found reference to decrypt.js
Examined JavaScript → discovered hardcoded encryption key
Found encrypted document (base64 encoded)
Identified algorithm (AES-128-ECB) and mode (ECB—weak!)
Converted JavaScript to Python for easier decryption
Decrypted document using the exposed key
This demonstrates multiple crypto failures at once:
Hardcoded keys in client-side code (accessible to anyone)
ECB mode (deterministic encryption that reveals patterns)
Weak key ("my-secret-key-16" is too predictable)
Client-side security logic (encryption key exposed to all users)
Proper cryptographic implementation requires:
Keys stored in secure key management services (AWS KMS, Azure Key Vault, HashiCorp Vault)
Strong algorithms (AES-256-GCM, ChaCha20-Poly1305)
Secure modes (GCM, CTR—never ECB!)
Proper key rotation policies
TLS 1.3 for data in transit
Secrets management systems (not environment variables or config files in repos!)
Regular cryptographic reviews and audits
A06: Insecure Design was perhaps the most interesting because it highlighted architectural flaws that are nearly impossible to patch without redesigning the system. The challenge simulated the famous Clubhouse vulnerability: the application assumed only mobile devices would access it, leading to unprotected API endpoints.
My exploitation process:
Initial reconnaissance with Gobuster (limited results)
Changed User-Agent to mobile device (bypassed client-side checks)
Continued enumeration, discovered /api directory structure
Found /api/users/admin, /api/users/user1, /api/users/user2 (IDOR vulnerability)
Discovered /api/messages endpoint
Accessed /api/messages/admin to retrieve the flag
The vulnerability stemmed from flawed architectural assumptions:
Security based on device type (User-Agent header—client-controlled!)
No authentication on API endpoints
"Security through obscurity" approach
Trust in client-side controls
Assumption that "mobile-only" means "secure"
This is insecure design in its purest form: the application was never built with proper threat modeling. The developers assumed:
✗ Only our mobile app will call these APIs
✗ Users won't discover the API endpoints
✗ Device type = authorization level
✗ Client-side controls are sufficient
The correct approach requires:
✓ Authentication on ALL API endpoints (OAuth 2.0, JWT, API keys)
✓ Server-side authorization checks for every request
✓ Principle of least privilege
✓ Threat modeling during design phase
✓ Security requirements defined before implementation
✓ No trust in client-controlled data
The Bigger Picture: Design Flaws in the AI Era
What makes these design flaws even more critical in 2025 is the explosion of AI-powered systems. The room mentions several AI-specific risks:
Prompt Injection: User input blended with system prompts, allowing attackers to hijack AI behavior or extract hidden data.
Blind Trust in AI Output: Systems that act on AI decisions without validation, creating automated attack paths.
Poisoned Models: Pre-trained models from unverified sources that contain backdoors, biases, or data exfiltration mechanisms.
Unchecked AI Authority: AI agents given excessive permissions to access systems, execute commands, or modify data without proper guardrails.
These represent a new frontier of insecure design where the risks are amplified by automation and scale. A compromised AI agent with broad system access isn't just one vulnerability—it's a force multiplier for attackers.
Critical Lessons for Developers and Security Teams
Throughout this room, several themes emerged that apply across all four vulnerability categories:
1. Security Must Be Designed In, Not Bolted On You cannot add security at the end of development and expect it to work. Every architectural decision has security implications that compound over time.
2. Default Settings Are Your Enemy Default credentials, default configurations, default permissions—these are designed for ease of setup, not security. Always harden defaults before production deployment.
3. Trust Nothing by Default
Don't trust client-controlled data (User-Agent, cookies, headers)
Don't trust third-party dependencies without verification
Don't trust that "no one will find this endpoint"
Don't trust that encryption is secure just because it exists
Don't trust AI model outputs without validation
4. Complexity Is the Enemy of Security The more complex your architecture, dependencies, and workflows, the more attack surface you expose. Simplify where possible.
5. Visibility and Monitoring Are Critical
Log security-relevant events (but not secrets!)
Monitor dependencies for vulnerabilities
Audit configurations regularly
Track changes to security-critical components
Set up alerts for anomalous behavior
6. Threat Modeling Is Non-Negotiable Before writing a single line of code, ask:
What are we trying to protect?
Who might attack us and how?
What assumptions are we making?
What happens if X component is compromised?
What are our trust boundaries?
For organizations looking to address these design flaw categories:
Security Misconfigurations:
Remove default credentials and enforce strong passwords
Disable unnecessary services and endpoints
Configure cloud storage with least-privilege access (never public unless absolutely necessary)
Hide detailed error messages in production
Keep all software, frameworks, and containers up to date
Implement automated configuration scanning (tools like ScoutSuite, Prowler, CloudSploit)
Conduct regular security configuration reviews
Supply Chain Security:
Implement dependency scanning in CI/CD pipeline
Maintain Software Bill of Materials (SBOM)
Verify package checksums and signatures
Use private registries for internal packages
Monitor dependencies for new vulnerabilities
Lock dependency versions and test updates before deployment
Secure build pipelines and code signing processes
Audit third-party AI models before use
Cryptographic Implementation:
Use industry-standard key management services
Implement AES-256-GCM or ChaCha20-Poly1305 for encryption
Enforce TLS 1.3 for all network traffic
Never hardcode secrets in code or config files
Implement key rotation policies
Conduct regular cryptographic reviews
Use secrets management tools (HashiCorp Vault, AWS Secrets Manager)
Remove all ECB mode implementations
Secure Design:
Implement authentication on ALL API endpoints
Enforce server-side authorization checks
Never trust client-controlled data
Apply principle of least privilege
Conduct threat modeling for new features
Implement rate limiting and abuse prevention
Separate system prompts from user inputs (for AI systems)
Require human review for high-risk AI actions
Test for logic flaws and edge cases
Connection to Security+ and Career Development
For those studying for Security+ or pursuing cybersecurity careers, this room reinforces multiple exam domains:
Domain 1.0 (General Security Concepts):
CIA Triad (Confidentiality affected by crypto failures and misconfigurations)
Defense in depth (multiple layers, not single points of failure)
Security controls (technical, administrative, physical)
Domain 2.0 (Threats, Vulnerabilities, and Mitigations):
Domain 3.0 (Security Architecture):
Secure design principles
Network segmentation
Zero trust architecture
Cloud security
Domain 4.0 (Security Operations):
The hands-on experience gained in this room—from Gobuster enumeration to Burp Suite request manipulation to cryptographic analysis—builds practical skills that translate directly to security analyst, penetration tester, and security engineer roles.
Final Thoughts
What makes application design flaws so insidious is that they often hide in plain sight. A misconfigured bucket, an outdated dependency, a hardcoded key, an unauthenticated API—individually, they might seem like small oversights. Collectively, they represent a systemic failure to prioritize security in the design and deployment process.
The progression through this room reinforced a critical truth: the best time to fix security issues is during the design phase. The second-best time is now. Waiting until after deployment, after a breach, or after customer data is exposed is too late.
As we move further into 2025 and beyond, with increasing adoption of AI agents, automation platforms, and distributed systems, the attack surface continues to expand. The principles learned in this room—secure defaults, verified dependencies, proper cryptography, and sound architectural design—become even more critical.
Every application we build sits on a foundation of design decisions. If that foundation is weak, no amount of patches, updates, or security tools can fully compensate. But if we get the design right from the start—with proper threat modeling, security requirements, and architectural controls—we build systems that are resilient by design, not just defended by afterthought.
Moving Forward
This room is part of a larger OWASP Top 10 2025 series. The journey continues with Room 3, which covers Insecure Data Handling—another critical area where design decisions have lasting security implications.
The skills and mindset developed here—questioning assumptions, enumerating thoroughly, understanding architectural weaknesses, and thinking about security holistically—are foundational to any cybersecurity career.
Remember: Security is not a feature you add. It's a quality you design in.
Room Stats:
Categories Covered: 4/10 OWASP Top 10 2025
Flags Captured: 4/4 ✅
Key Skills Gained: Configuration auditing, dependency analysis, cryptographic assessment, architectural security review
Tools Used: Gobuster, Burp Suite, Browser DevTools, Python (PyCryptodome), Base64 decoding
Real-World Parallel: Uber (2017), SolarWinds (2021), Clubhouse (2021)
Thanks for following along with this writeup! If you found this helpful, check out my other OWASP Top 10 2025 writeups and cybersecurity content. And if you're building applications—please, for the love of all that is secure, use key management services and stop hardcoding secrets! 🔐
