What are the OWASP Top 10 vulnerabilities, and how can they be mitigated?

Broken Access Control

Broken Access Control occurs when a system fails to enforce restrictions on what authenticated users are allowed to do. At its core, the vulnerability exists because the application relies on client-side requests—like URL parameters or hidden form fields—to determine the authorization level of a user rather than verifying permissions server-side for every single request. If a developer assumes that a user cannot see a hidden administrative button and fails to check the user's role on the backend during the data fetch, an attacker can simply manually trigger the API endpoint to gain unauthorized access. Mitigation involves enforcing a centralized access control mechanism where every request is evaluated against an explicit allow-list. By implementing a strict policy that denies all access by default and only grants specific permissions based on the session's verified identity, you ensure that even if an attacker manipulates the request, the server will reject the operation.

# Example of secure server-side check
function deleteUser(request, targetUserId) {
    // Always verify the authenticated user's role before processing the action
    if (request.user.role !== 'ADMIN') {
        throw new Error('Unauthorized'); // Deny by default
    }
    // Proceed with deletion only after authorization is verified
    database.execute('DELETE FROM users WHERE id = ?', [targetUserId]);
}

Injection Attacks

Injection vulnerabilities manifest when untrusted data is sent to an interpreter as part of a command or query. The fundamental flaw is the lack of separation between the control logic of the command and the user-supplied data, allowing the data to alter the meaning of the command itself. When an application concatenates user input directly into a database query string, the interpreter cannot distinguish between the intended logic and the injected malicious syntax. By treating everything in the string as part of the execution plan, the system inadvertently grants the user command-level authority. To mitigate this, you must always use parameterized queries or prepared statements. This technique ensures that the database driver treats input strictly as data, never as executable code, effectively neutralizing any attempt to alter the query structure regardless of what characters the user inputs into the form fields.

# Secure way to query the database using prepared statements
const userId = "'1' OR '1'='1'"; // Malicious input
// The query engine treats the input as a single literal string value, not executable code
database.execute('SELECT * FROM users WHERE id = ?', [userId]);

Cryptographic Failures

Cryptographic failures occur when sensitive data is exposed due to weak encryption algorithms, poor key management, or the absence of encryption during transit and at rest. These vulnerabilities happen because developers often prioritize convenience over secrecy, storing passwords in plaintext or using outdated hashing methods that are susceptible to collision attacks or brute force. When sensitive information travels over insecure channels or resides in storage without adequate protection, it becomes trivial for an attacker to intercept or dump the data. Effective mitigation requires implementing strong, modern encryption standards like AES-256 for data at rest and ensuring all traffic is encrypted via Transport Layer Security. Furthermore, you must never store passwords in plaintext; instead, use memory-hard, salt-based hashing algorithms that slow down password cracking attempts, rendering stolen data useless even if the underlying database is compromised.

# Use strong hashing with a unique salt for password storage
const bcrypt = require('bcrypt');
const saltRounds = 12;
// Hash password before saving to storage
const hash = bcrypt.hashSync(userPassword, saltRounds);
database.execute('INSERT INTO users (password) VALUES (?)', [hash]);

Insecure Design

Insecure Design refers to risks related to a lack of security-focused processes during the architectural planning of an application. Unlike implementation bugs, these flaws are rooted in the logical flow and feature specifications. If an application is designed without threat modeling, it may inadvertently contain logic that allows users to bypass security checkpoints or access sensitive business operations without verification. This category highlights that you cannot 'code' your way out of a fundamentally broken design. To mitigate this, security must be integrated into the design phase by performing regular threat modeling sessions. By proactively imagining how an attacker might attempt to manipulate business workflows, architects can design systems that enforce security invariants throughout the application logic. This approach ensures that security is a functional requirement rather than a post-development patch applied to a flawed foundation.

// Logic ensuring secure multi-step business process
function completeTransaction(transaction) {
    // Ensure the state cannot be jumped over
    if (transaction.status !== 'VERIFIED') {
        throw new Error('Invalid state transition');
    }
    // Process payment only after status verification
    processPayment(transaction);
}

Security Misconfiguration

Security Misconfiguration happens when security controls are incorrectly set up, are left in a default state, or are overly permissive. This is a common point of failure because complex systems often ship with diagnostic features, default credentials, or verbose error messages enabled to simplify setup. If these settings remain in a production environment, they provide attackers with a roadmap of the application's internal structure and versioning. Misconfigurations also include headers that are not set, such as missing Cross-Origin Resource Sharing policies, which expose the system to unauthorized interactions. Mitigation involves adopting an automated 'infrastructure as code' approach to ensure consistent, hardened deployments. By disabling unnecessary features, removing default accounts, and strictly configuring headers to limit browser access to resources, you reduce the attack surface and ensure the system behaves predictably under adversarial scrutiny.

// Configure strict HTTP headers to prevent resource misuse
response.setHeader('Content-Security-Policy', "default-src 'self'");
response.setHeader('X-Content-Type-Options', 'nosniff');
response.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');

Interview questions

All cyber security interview questions →

Check yourself

Take the full cyber security quiz →