Software Development Security practice questions

Vulnerability scanner

Why wrong: Vulnerability scanners primarily identify known security weaknesses in systems, networks, or applications by comparing configurations and observed behaviors against a database of signatures. While they can detect outdated software versions that might imply certain components, their core function is not to enumerate a comprehensive, hierarchical list of all third-party and open-source components and their dependencies within a software product. Therefore, it cannot fulfill the requirement of understanding the full software supply chain composition.

Static Application Security Testing (SAST)

Why wrong: Static Application Security Testing (SAST) tools analyze an application's source code, bytecode, or binary code without executing it, identifying potential security flaws like buffer overflows or SQL injection vulnerabilities. While SAST can sometimes identify specific libraries or frameworks used by parsing manifest files or import statements, its primary purpose is not to generate a complete, hierarchical inventory of all direct and transitive third-party and open-source components, including their versions and licenses, which is crucial for comprehensive supply chain risk management.

Dynamic Application Security Testing (DAST)

Why wrong: Dynamic Application Security Testing (DAST) tools interact with a running application from the outside, simulating attacks to identify runtime vulnerabilities such as cross-site scripting or authentication bypasses. Because DAST operates on the compiled, executing application and does not access its internal source code or build artifacts, it cannot systematically enumerate the specific third-party libraries, open-source components, or their dependencies embedded within the application. Its focus is on observable behavior and exploitable flaws, not internal component composition.

Strong authentication

Why wrong: Strong authentication refers to the use of robust methods and controls to verify a user's identity, making it significantly harder for unauthorized individuals to gain access. Implementing an account lockout policy directly strengthens authentication by preventing attackers from making unlimited login attempts, thereby mitigating brute-force and credential stuffing attacks. This mechanism enhances the overall security posture of the authentication process by limiting the window of opportunity for attackers.

Defense in depth

Why wrong: Defense in depth is a cybersecurity strategy that employs multiple, overlapping security controls to protect assets, ensuring that if one control fails, others are still in place to provide protection. It involves layers like physical, technical, and administrative safeguards. While account lockout is a technical control, it represents a single mechanism within the authentication layer, rather than a multi-layered architectural approach encompassing diverse security domains.

Least privilege

Why wrong: The principle of least privilege dictates that users, processes, or systems should be granted only the absolute minimum set of permissions necessary to perform their legitimate tasks, and no more. This minimizes the potential damage if an account is compromised. Account lockout, conversely, is an authentication mechanism designed to prevent unauthorized access attempts altogether, and it does not define or restrict the specific access rights a successfully authenticated user possesses.

Use of an outdated version of a JavaScript library with known vulnerabilities

Why wrong: This scenario represents a vulnerability stemming from the use of insecure or outdated third-party components, a common issue in software supply chains. While it introduces a significant security risk, it is fundamentally distinct from a misconfiguration, which involves incorrect or suboptimal settings within the server's own configuration files or deployed application settings. This is a software composition analysis problem, not a configuration management one.

Lack of CSRF tokens in forms

Why wrong: The absence of Cross-Site Request Forgery (CSRF) tokens in web forms signifies a missing security control within the application's design or development, rather than a server misconfiguration. CSRF protection is an application-level security mechanism implemented in code to prevent unauthorized commands from being transmitted from a user's browser. While a serious vulnerability, it's not about incorrect server settings but a fundamental flaw in the application's security architecture.

Weak password policy allowing short passwords

Why wrong: A weak password policy that permits short or easily guessable passwords falls under the category of "Broken Authentication" or "Insecure Authentication Mechanisms." While related to security settings, it primarily concerns the robustness of the authentication system itself and the rules governing user credentials, rather than an incorrect server or application configuration parameter. This issue directly impacts the integrity and strength of user identity verification.

Encrypting the serialized data

Why wrong: Encryption primarily ensures confidentiality, meaning unauthorized parties cannot read the serialized data, but it does not inherently provide integrity. An attacker could still modify the encrypted data in a way that, when decrypted and deserialized, could lead to a malicious object or code execution. Without integrity checks, an attacker could substitute a valid encrypted payload with a different, equally valid (but malicious) encrypted payload if they understand the structure or can replay known attacks, without breaking the encryption itself.

Using generic exception handling to catch errors

Why wrong: Generic exception handling, such as a broad `try-catch` block, is designed to gracefully manage runtime errors and prevent application crashes, not to prevent security vulnerabilities. While it can catch exceptions that occur during a deserialization attempt, it does not prevent the underlying deserialization vulnerability from being exploited. The malicious code or object could still be processed before the exception is triggered, or the exception might only occur *after* the harmful action has already taken place, making it a reactive rather than a preventative measure.

Logging all deserialization attempts

Why wrong: Logging deserialization attempts creates an audit trail, which is valuable for forensic analysis, incident response, and identifying potential attack patterns after an event has occurred. However, logging is a detective control; it does not actively prevent an attacker from successfully exploiting a deserialization vulnerability in real-time. The malicious payload would still be processed and potentially executed before the log entry is even written, meaning the system is already compromised.

Hashing the data with MD5 for faster performance

Why wrong: Hashing data with MD5 is fundamentally inappropriate for encryption purposes because MD5 is a one-way cryptographic hash function, not an encryption algorithm. It is designed for integrity checks, not confidentiality, and cannot be reversed to recover the original data. Furthermore, MD5 is cryptographically weak, highly susceptible to collision attacks where different inputs produce the same hash, making it unsuitable even for integrity verification in security-critical applications.

Using a static IV for simplicity

Why wrong: Using a static Initialization Vector (IV) for simplicity is a critical cryptographic vulnerability that severely compromises confidentiality. An IV must be unique for each encryption operation, ideally random or a nonce, to prevent identical plaintext blocks from producing identical ciphertext blocks when using block cipher modes like CBC or CTR. A static IV allows attackers to deduce relationships between encrypted messages, facilitating chosen-plaintext attacks and potentially leading to full plaintext recovery.

Implement CSRF tokens for all state-changing requests.

Why wrong: Cross-Site Request Forgery (CSRF) tokens are crucial for preventing attackers from tricking authenticated users into executing unintended actions on a web application. While CSRF is a form of tampering, it primarily addresses tampering at the application layer by ensuring requests originate from the legitimate user interface, not from a malicious third-party site. The question's context, however, emphasizes "tampering in transit" and "information disclosure," which are better addressed by transport layer security mechanisms like TLS, making CSRF tokens less directly relevant to the specific threats highlighted.

Log all user credentials during authentication attempts for audit purposes.

Why wrong: Logging user credentials, such as usernames and passwords, during authentication attempts creates a severe information disclosure vulnerability. If these logs are compromised, an attacker would gain direct access to sensitive user authentication data, leading to account takeovers and further breaches. Best practice dictates logging only non-sensitive information, like timestamps, source IP, and authentication success or failure, to maintain audit trails without introducing an unacceptable risk of credential exposure.

Deploy a Web Application Firewall (WAF) to block all incoming traffic from unknown IP addresses.

Why wrong: While a Web Application Firewall (WAF) is effective at mitigating various application-layer attacks like SQL injection and Cross-Site Scripting (XSS), blocking all incoming traffic from "unknown IP addresses" is an overly broad and impractical security measure. This approach would severely disrupt legitimate user access and is not a primary function or effective configuration for a WAF, which typically focuses on inspecting and filtering malicious request patterns rather than IP reputation alone. Furthermore, this does not directly address information disclosure or tampering in transit as effectively as other controls.

Escaping all user input before concatenation

Why wrong: Escaping all user input before concatenation is an unreliable defense against SQL injection due to its inherent complexity and potential for errors. Developers must correctly identify and escape all context-specific special characters, which is difficult to do exhaustively across various database systems and encoding schemes. A single missed character or incorrect escaping rule can create a vulnerability, making it a brittle and high-maintenance approach that is prone to bypasses.

Input validation using a blacklist of known malicious patterns

Why wrong: Input validation using a blacklist of known malicious patterns is fundamentally flawed because it operates on an incomplete and reactive basis. Attackers can often bypass blacklists by employing novel attack techniques, using different encodings, or discovering patterns not included in the list. This approach creates a false sense of security and requires constant, exhaustive updates to remain even marginally effective, which is practically unsustainable.

Implementing a Web Application Firewall (WAF)

Why wrong: Implementing a Web Application Firewall (WAF) acts as a valuable compensating control, but it does not comprehensively prevent application-layer vulnerabilities like SQL injection at the source. While a WAF can detect and block many common attack signatures, it operates at the network perimeter and cannot fix insecure application code. It may be bypassed by sophisticated attackers, generate false positives, or miss zero-day exploits, making it a secondary defense rather than a primary solution for secure coding practices.

Information Disclosure

Why wrong: Information Disclosure, in the context of an online banking application, refers to the unauthorized exposure of sensitive or confidential data to individuals or systems not permitted to access it. This could involve leaking account balances, transaction histories, personal identifiable information (PII), or even system architecture details, thereby compromising the confidentiality of user data and operational security. While a critical threat, it doesn't directly describe the *alteration* of data.

Elevation of Privilege

Why wrong: Elevation of Privilege occurs when an attacker exploits a vulnerability to gain access rights or permissions beyond what they were initially authorized for, moving from a lower-privileged state to a higher one. In an online banking scenario, this might involve a regular user gaining administrative access or a limited user gaining access to another user's full account. While a severe threat, it focuses on unauthorized *access levels* rather than the direct *modification of data* itself.

Spoofing

Why wrong: Spoofing involves an attacker successfully impersonating a legitimate user, system, or entity to gain unauthorized access or deceive other components within the online banking environment. This could include phishing attacks to steal credentials, IP address spoofing, or DNS spoofing, aiming to bypass authentication mechanisms or misdirect traffic. Its primary focus is on faking identity or origin, distinct from the direct unauthorized alteration of data.

Use Content Security Policy (CSP) headers to restrict script execution

Why wrong: While Content Security Policy (CSP) headers are a valuable defense-in-depth mechanism, they operate client-side to mitigate the *impact* of XSS by restricting script execution. CSP cannot retroactively fix the underlying server-side vulnerability where malicious scripts are already stored in the database. The core issue of untrusted data being stored and later rendered unsafely remains unaddressed by CSP alone, making it an incomplete solution for remediation.

Sanitize input by removing all HTML tags before storing

Why wrong: Removing all HTML tags during input sanitization is an overly aggressive approach that can severely degrade legitimate user functionality, such as allowing rich text formatting. While input validation is crucial, simply stripping tags does not guarantee XSS prevention if other attack vectors exist, and it fundamentally alters the user's intended content. Furthermore, this method is less robust than context-aware output encoding, which preserves data integrity while neutralizing malicious script execution upon rendering.

Store comments in a separate domain to isolate them

Why wrong: Storing comments on a separate domain, while potentially a good security practice for isolating user-generated content, does not directly prevent a stored Cross-Site Scripting (XSS) vulnerability. If the separate domain still renders the unsanitized malicious content, the XSS payload will execute within that isolated domain's context. This strategy primarily aims to limit the *blast radius* of an attack by preventing session hijacking or data exfiltration from the main application's domain, rather than eliminating the XSS flaw itself.

Separation of duties

Why wrong: This principle is an administrative control designed to mitigate the risk of fraud, error, and insider threat by distributing critical tasks among multiple individuals. It ensures that no single person possesses sufficient privileges to complete a sensitive operation entirely on their own, requiring collusion to bypass controls. While vital for governance, it does not directly address the architectural layering of diverse technical security mechanisms to protect against external attacks.

Fail-secure

Why wrong: The fail-secure principle dictates that when a system component experiences a failure, it should default to a state that denies access or operation, thereby preserving the confidentiality, integrity, and availability of data. This prevents unauthorized access or exploitation during system malfunctions. However, this principle specifically addresses system behavior upon failure rather than the proactive, multi-layered deployment of diverse security mechanisms intended to prevent initial compromise.

Least privilege

Why wrong: The principle of least privilege mandates that every user, program, or process should be granted only the minimum necessary permissions and access rights required to perform its specific authorized functions. This significantly reduces the potential impact of a security breach or error by limiting the scope of damage an attacker or compromised entity can inflict. While crucial for minimizing the attack surface, it focuses on access control granularity rather than the strategic deployment of multiple, distinct security layers throughout an entire system.

Broken authentication

Why wrong: Broken authentication refers to vulnerabilities in how an application manages user identities, login credentials, and session tokens. This could manifest as weak password policies, improper session invalidation, or susceptibility to brute-force attacks. While critical for overall security, it doesn't directly describe a scenario where an authenticated user can access another user's resources simply by changing an object identifier in a request without proper authorization checks.

Server-side request forgery (SSRF)

Why wrong: Server-side request forgery (SSRF) is a vulnerability where an attacker can induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing. This allows the attacker to force the server to connect to internal services within the organization's infrastructure or external third-party services. This differs from IDOR, which focuses on unauthorized direct access to application objects by manipulating identifiers, rather than coercing the server to initiate new, unauthorized network connections.

Security misconfiguration

Why wrong: Security misconfiguration encompasses a broad range of vulnerabilities resulting from improperly configured security settings across the application stack, including web servers, application servers, databases, and frameworks. Examples include using default credentials, enabling unnecessary features, verbose error messages revealing sensitive information, or inadequate access controls on directories. While IDOR can sometimes stem from a misconfiguration of authorization rules, the core issue of directly referencing objects without proper checks is more specifically categorized as IDOR itself, rather than a general misconfiguration.

Encoding input before processing

Why wrong: Encoding input before processing is an incorrect security practice for input validation. Encoding transforms special characters into a safe representation for a specific context, like HTML entities or URL encoding, but it does not validate the input's intent or content. A malicious payload, even if encoded, can still be decoded and executed by the application or underlying interpreter if it's not properly validated against expected patterns *before* any processing occurs. This approach merely shifts the problem without addressing the root cause of untrusted input.

Using regular expressions to sanitize input

Why wrong: Regular expressions for input sanitisation attempt to remove or block malicious characters, but injection attacks exploit context-specific parsing (e.g., SQL, LDAP, or shell interpreters) that regex cannot reliably anticipate across all encoding layers. This approach is tempting because regex effectively validates format constraints (e.g., email patterns) in static data, where character whitelisting is sufficient. It would be correct for preventing format-based injection in a single, well-defined context like a numeric ID field.

Blacklist validation to block known malicious patterns

Why wrong: Blacklist validation, which attempts to block known malicious patterns, is inherently flawed and provides insufficient security. This reactive approach relies on maintaining an exhaustive list of all possible bad inputs, which is practically impossible to achieve. Attackers can often bypass blacklists by using novel attack vectors, different encodings, or obfuscation techniques not present in the predefined list, leaving the application vulnerable to new or cleverly disguised threats. It creates a false sense of security by focusing on what *not* to allow, rather than what *is* allowed.

Implementing input validation on deserialized data

Why wrong: Implementing input validation on data *after* it has been deserialized is insufficient to prevent deserialization attacks. Many deserialization vulnerabilities exploit the process itself, allowing malicious code to execute during the object's construction or method calls triggered by the deserializer, *before* any application-level validation logic can be applied to the resulting object's state. By the time validation occurs, the damage, such as remote code execution or arbitrary file writes, may have already been done, making this a reactive and often ineffective control against the core deserialization exploit.

Using a allowlist of classes allowed to be deserialized

Why wrong: While using an allowlist of permitted classes for deserialization is a valuable security measure to prevent the instantiation of arbitrary or unexpected classes, it does not fully mitigate all deserialization vulnerabilities. Attackers can still exploit 'gadgets' within *allowlisted* classes, chaining their methods to achieve malicious outcomes like remote code execution or denial of service. The vulnerability often lies in the interaction and side effects of legitimate methods within trusted classes when invoked during deserialization with attacker-controlled data, rather than merely the presence of an unauthorized class.

Running deserialization in a sandboxed environment

Why wrong: Running deserialization within a sandboxed environment can limit the *impact* of a successful deserialization attack by restricting the resources and permissions available to the deserialized object and its associated code. However, sandboxing does not *prevent* the initial exploitation or the execution of malicious code within the sandbox itself. An attacker could still achieve denial of service, information disclosure, or even sandbox escape if vulnerabilities exist, making it a containment strategy rather than a primary preventative measure against the deserialization vulnerability itself.

Insecure direct object reference (IDOR)

Why wrong: IDOR occurs when an application exposes a direct reference to an internal object—such as a file, database record, or account ID—and fails to verify that the requesting user is authorized to access that specific object. In this scenario the attacker isn't manipulating an object reference; they're coercing the server itself into issuing requests to other internal hosts via a URL parameter, which is a server-side trust boundary failure, not a missing authorization check on a user-owned resource.

Remote code execution (RCE)

Why wrong: Remote code execution means an attacker gets the server to execute arbitrary commands or code they supply, typically through an unsafe deserialization, injection, or file-upload flaw. Nothing in this scenario shows the attacker running code on the server—they're only causing the server to make outbound HTTP requests to internal addresses on their behalf. Triggering unintended network requests is a distinct vulnerability class from achieving code execution, even though a chained SSRF could sometimes lead to RCE in specific environments.

Cross-site request forgery (CSRF)

Why wrong: CSRF tricks an already-authenticated victim's browser into submitting a state-changing request to an application without their consent, exploiting the browser's automatic inclusion of session cookies. That requires a human victim's browser and session to be involved. Here, the attacker is directly manipulating a URL parameter to make the server itself issue requests, with no victim browser, session hijacking, or cross-site request forwarding taking place, so it doesn't fit the CSRF pattern.

Display detailed errors to users for troubleshooting

Why wrong: Exposing detailed error messages directly to users, such as full stack traces, SQL error messages, or internal file system paths, provides attackers with invaluable reconnaissance data. This information can reveal the application's underlying technologies, database structure, and potential vulnerabilities, enabling them to craft more targeted and effective exploits. Such disclosures significantly increase the attack surface and can lead to serious security breaches, including data exfiltration, privilege escalation, or remote code execution by providing a roadmap to system internals.

Disable all error reporting to eliminate information leakage

Why wrong: Completely disabling all error reporting creates a dangerous blind spot, preventing administrators from detecting and diagnosing critical application failures or security vulnerabilities in a timely manner. While it might seem to eliminate information leakage, it merely hides problems, allowing silent failures to persist, potentially leading to data corruption, service outages, or unpatched security flaws that attackers could still discover and exploit through other means. This approach severely hampers incident response capabilities and overall system resilience, making it impossible to address issues proactively.

Encrypt error messages before displaying to users

Why wrong: Encrypting error messages before displaying them to users offers no practical security benefit against information leakage if the user, or an attacker impersonating a user, possesses the means to decrypt the message. The core problem of sensitive data disclosure remains unaddressed, as the information is merely obfuscated rather than truly protected from the intended recipient. This method introduces unnecessary computational overhead and complexity without mitigating the fundamental risk of exposing internal system details to anyone who can access and decrypt the message.

Encrypt passwords using AES-256 with a static key

Why wrong: Encrypting passwords using AES-256 with a static key is fundamentally insecure for password storage because encryption is a reversible process. If the single static encryption key is ever compromised, all stored passwords can be immediately decrypted and exposed in plaintext. This method offers no protection against an attacker who gains access to both the encrypted data and the key, making it unsuitable for safeguarding sensitive user credentials.

Store passwords in plaintext but in a protected database

Why wrong: Storing passwords in plaintext, even within a supposedly protected database, is an unacceptable security practice. While database protections like access controls and firewalls are important, they are not infallible. Any successful breach of the database's perimeter defenses, whether through SQL injection, insider threat, or zero-day exploit, would instantly expose all user passwords without any cryptographic barrier, leading to widespread account compromise and potential identity theft.

Hash passwords with SHA-256 without salt

Why wrong: Hashing passwords with SHA-256 without a salt is highly vulnerable to various attacks, primarily rainbow tables and dictionary attacks. Without a unique salt, identical passwords will always produce the exact same hash value. Attackers can precompute a vast database of common password hashes (a rainbow table) and quickly match stolen hashes to their corresponding plaintext passwords, bypassing the need for individual brute-force attempts and compromising user accounts efficiently.

Injection

Why wrong: Injection vulnerabilities occur when untrusted data is sent to an interpreter as part of a command or query, tricking the interpreter into executing unintended commands or accessing unauthorized data. This category includes SQL Injection, NoSQL Injection, OS Command Injection, and Cross-Site Scripting (XSS), where malicious input manipulates the application's underlying logic or data interactions. It specifically targets how an application processes and executes user-supplied input.

Cryptographic Failures

Why wrong: Cryptographic Failures involve the improper implementation or absence of cryptographic protections, leading to the exposure of sensitive data. This can manifest as using weak or deprecated algorithms, insufficient key lengths, improper key management, or failing to encrypt data at rest or in transit when required. Such failures directly compromise the confidentiality and integrity of protected information, making it readable or modifiable by unauthorized parties.

Broken Access Control

Why wrong: Broken Access Control refers to the improper enforcement of restrictions on what authenticated users are allowed to do, allowing them to bypass authorization checks. This can enable users to access other users' accounts, view sensitive files, modify data, or perform administrative functions without proper permissions. Flaws often arise from incorrect role-based access control (RBAC) implementations or insufficient validation of user requests against their assigned privileges.

Regenerate session tokens after login

Why wrong: Regenerating session tokens after login is primarily used to prevent session fixation attacks, where an attacker sets a known session ID before authentication. It does not directly address session token predictability, exposure in URLs, or absence of logout invalidation, making it less appropriate for the listed issues.

Implement IP address binding for session tokens

Why wrong: Implementing IP address binding for session tokens attempts to tie a session to a specific client IP address, but it introduces significant usability issues for legitimate users whose IP addresses may change during a session (e.g., mobile users, VPNs, or users behind load balancers). Furthermore, this control can often be bypassed by sophisticated attackers using proxies, botnets, or by compromising the user's local network, making it an unreliable and often counterproductive security measure.

Penetration testing

Why wrong: Penetration testing involves authorized simulated attacks on a system to identify exploitable vulnerabilities and assess the overall security posture. While crucial for validating defenses, it is typically a resource-intensive, manual process performed at later stages of the development lifecycle or on deployed systems. Its nature makes it unsuitable for continuous integration into early development and testing phases.

Vulnerability scanning

Why wrong: Vulnerability scanning systematically identifies known security weaknesses in networks, servers, and applications by comparing system configurations and installed software against a database of known vulnerabilities. While important for overall security posture, it primarily focuses on infrastructure and common software flaws, rather than deep analysis of custom application code during its development. It's generally an external, post-development assessment.

Dynamic Application Security Testing (DAST)

Why wrong: DAST examines a running application from the outside, simulating an attacker's perspective by sending various inputs and observing the application's responses. It can identify runtime vulnerabilities like authentication flaws or configuration errors. However, DAST requires a fully functional and deployed application instance, making it more suitable for later stages of the SDLC, such as quality assurance or pre-production environments, rather than continuous integration during early development.

CVSS

Why wrong: CVSS (Common Vulnerability Scoring System) is a standardized, open framework for communicating the characteristics and impacts of IT vulnerabilities. It provides a numerical score representing the severity of a vulnerability, allowing organizations to prioritize remediation efforts. However, CVSS is a post-discovery scoring system for *existing* vulnerabilities, not a proactive methodology for identifying potential threats during the design or requirements gathering phases of software development.

OCTAVE

Why wrong: OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) is a comprehensive risk-based strategic assessment and planning framework, not a specific threat modeling methodology focused on software design categories. It helps organizations understand information security risks by identifying critical information assets, the threats to those assets, and the vulnerabilities that could expose them. OCTAVE focuses on organizational risk management and developing a protection strategy rather than detailing specific software-level threats like Spoofing or Tampering.

PASTA

Why wrong: PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage, risk-centric threat modeling methodology that provides a structured approach to identifying, enumerating, and scoring threats. While it is a robust framework for understanding potential attacks and their business impact, it is distinct from STRIDE's specific categorization of threats against system properties. PASTA emphasizes an attacker-centric view, focusing on attack simulation and risk analysis to derive appropriate countermeasures, rather than a direct classification of threats into categories like Spoofing or Elevation of Privilege.