Exploiting Web Application Vulnerabilities (OWASP Top 10)

Broken Access Control

Broken Access Control occurs when an application fails to properly enforce restrictions on what authenticated users are allowed to do. At its core, the vulnerability exists because the server implicitly trusts the client to dictate its own privileges or resource access path. When an application relies solely on client-side state, such as a hidden form field or a simple URL parameter, the user can easily manipulate these inputs to access administrative functions or data belonging to other users. To reason about this, consider whether the server re-validates the user's permission for every single object request. If the application checks authorization only once during the initial login process, it creates a wide window for Insecure Direct Object Reference (IDOR) attacks. By modifying identifiers in the request, an attacker shifts the scope of the operation to unauthorized targets, bypassing security boundaries effectively.

# Example of a vulnerable IDOR pattern in a request handler
# The app assumes the ID belongs to the user without server-side verification
@app.route('/api/user/profile/<user_id>')
def get_profile(user_id):
    # VULNERABLE: Direct database lookup using user-supplied ID
    # An attacker can change user_id to scrape other profiles
    user_data = db.query(f"SELECT * FROM profiles WHERE id = {user_id}")
    return json.dumps(user_data)

Injection Flaws

Injection vulnerabilities arise when untrusted data is sent to an interpreter as part of a command or query. The fundamental reason this works is the conflation of data and control instructions within the same communication stream. When an interpreter receives input, it cannot inherently distinguish between the programmer's intended logic and the data provided by the user. If the input contains control characters—such as quotes, semicolons, or comment indicators—the interpreter may execute the attacker's data as if it were a legitimate command. To defend against this, the application must treat all user input as untrusted and utilize parameterized interfaces that enforce a strict boundary between instructions and data. By forcing the input to be handled purely as a literal value rather than an executable component, the structural logic of the backend query remains immutable, neutralizing the threat posed by injected malicious payloads.

# Vulnerable SQL Injection using string formatting
# The input is concatenated, allowing for command modification
def get_user_status(username):
    # VULNERABLE: ' or '1'='1 becomes a valid true condition
    query = "SELECT status FROM users WHERE username = '" + username + "'"
    return db.execute(query)

Insecure Design

Insecure Design refers to flaws inherent in the application's architecture rather than its implementation. Unlike bugs, which are coding errors, design flaws exist because the security requirements were either missing, improperly defined, or misunderstood during the planning phase. When an application fails to incorporate security controls like rate limiting or business logic validation from the start, retrofitting security becomes significantly more difficult and often incomplete. Reasoning about this requires examining the complete user flow; if the business logic allows an attacker to complete a sequence of actions that results in an unintended outcome—such as purchasing an item for free—the design itself is broken. Effective mitigation requires a shift-left approach where threat modeling is performed to identify how an attacker might abuse the application's intended purpose to subvert internal controls, ensuring the architecture is resilient by default.

# Logic flow vulnerability: allowing free purchases
# The design lacks a server-side check of the final price
def process_checkout(cart_items, user_supplied_price):
    # VULNERABLE: The server accepts price from the client
    if user_supplied_price == 0:
        return "Order Placed!"
    return "Please pay the total."

Security Misconfiguration

Security Misconfiguration is a broad category encompassing failures to secure the environment hosting the application. These vulnerabilities often occur because default settings are left unchanged, error messages are too verbose, or unnecessary features remain enabled in production. From an attacker's perspective, these misconfigurations act as information leaks. For example, a default configuration might expose a directory listing of sensitive files or return detailed stack traces upon an exception. These details provide a roadmap for exploitation by revealing the underlying stack, path structures, or installed dependencies. To reason about this, one must view the environment through the lens of a hardening checklist. Every enabled service, exposed port, or verbose log output represents a surface area that provides intelligence to an attacker. Minimizing this surface area is critical because the most secure code is often rendered ineffective if the environment hosting it is left wide open to reconnaissance and exploitation.

# Vulnerable configuration exposing debug information
# Error handling prints the stack trace directly to the response
@app.errorhandler(500)
def handle_error(e):
    # VULNERABLE: Exposes system paths and code structure to the user
    return f"An error occurred: {str(e)}", 500

Vulnerable and Outdated Components

Modern applications rely heavily on external libraries, frameworks, and modules. Vulnerable and Outdated Components occur when these dependencies have known, documented security flaws that remain unpatched in the production environment. The danger lies in the trust placed in third-party code; developers often focus on their custom logic while neglecting the maintenance of underlying infrastructure. An attacker can use automated scanning to identify versions of software known to be susceptible to Remote Code Execution (RCE) or other critical exploits. Once a vulnerable version is identified, the attacker does not need to spend time researching new zero-days; they simply leverage existing exploit kits. Reasoning about this requires a robust asset inventory and a strategy for continuous monitoring. If you do not know exactly what components are running in your environment, you cannot effectively assess your risk posture or ensure that your applications are protected against public, well-documented attacks.

# Using an outdated and vulnerable library version
# Vulnerability: CVE-2023-XXXXX (Insecure Deserialization)
import pickle # Dangerous library used in an outdated version

def load_user_session(data):
    # VULNERABLE: Deserializing data from the user allows RCE
    return pickle.loads(data)

Interview questions

All cyber security interview questions →

Check yourself

Take the full cyber security quiz →