OWASP Top 10 2025: Application Design Flaws (TryHackMe)

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:

1. AS02: Security Misconfigurations

2. AS03: Software Supply Chain Failures

3. AS04: Cryptographic Failures

4. 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

# The hardcoded key from decrypt.js
key = b"my-secret-key-16"  # 16 bytes = AES-128

# The encrypted data (base64 encoded)
encrypted_base64 = "Nzd42HZGgUIUlpILZRv0jeIXp1WtCErwR+j/w/lnKbmug31opX0BWy+pwK92rkhjwdf94mgHfLtF26X6B3pe2fhHXzIGnnvVruH7683KwvzZ6+QKybFWaedAEtknYkhe"

# Decode from base64
encrypted_data = base64.b64decode(encrypted_base64)

# Create cipher in ECB mode (as specified in the JS)
cipher = AES.new(key, AES.MODE_ECB)

# Decrypt
decrypted_padded = cipher.decrypt(encrypted_data)

# Remove padding
try:
    decrypted = unpad(decrypted_padded, AES.block_size)
    print(decrypted.decode('utf-8'))
except Exception as e:
    # If unpad fails, try without unpadding
    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:

1. Inspected page source → found reference to decrypt.js

2. Examined JavaScript → discovered hardcoded encryption key

3. Found encrypted document (base64 encoded)

4. Identified algorithm (AES-128-ECB) and mode (ECB—weak!)

5. Converted JavaScript to Python for easier decryption

6. 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:

1. Initial reconnaissance with Gobuster (limited results)

2. Changed User-Agent to mobile device (bypassed client-side checks)

3. Continued enumeration, discovered /api directory structure

4. Found /api/users/admin, /api/users/user1, /api/users/user2 (IDOR vulnerability)

5. Discovered /api/messages endpoint

6. 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?

Practical Remediation Checklist

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):

• Supply chain attacks

• Configuration vulnerabilities

• Cryptographic attacks

• API vulnerabilities

Domain 3.0 (Security Architecture):

• Secure design principles

• Network segmentation

• Zero trust architecture

• Cloud security

Domain 4.0 (Security Operations):

• Vulnerability management

• Security baselines and hardening

• Configuration management

• Incident response (detecting and responding to design flaw exploitation)

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! 🔐