Secure Software Implementation practice questions

Using cleartext with database permissions

Why it fails: Cleartext leaves values readable to anyone with file or backup access, and database permissions only gate SQL access, not the storage layer, so they fail the at-rest requirement entirely. It is tempting because permissions are simple and genuinely appropriate for controlling query-level access, but they cannot substitute for encryption of stored data.

Using MD5 hashing

Why it fails: MD5 is a fast, unsalted one-way hash built for integrity checking, not confidentiality; it cannot be decrypted, so the stored data becomes unusable, and collisions are practical. It is tempting because hashing is genuinely correct for storing passwords, but that scenario differs from protecting recoverable data at rest.

Storing data in base64 encoding

Why it fails: Base64 is a reversible encoding, not encryption, so anyone with database access reads the plaintext directly; it provides no confidentiality key. It is tempting because it obscures values visually and is genuinely used to safely transport binary data through text-only channels, but it satisfies no encryption-at-rest requirement.

Using <%- %> tags for all variables

Why it fails: The <%- tag renders unescaped HTML, which is a major XSS risk.

Disabling the template engine

Why it fails: Disabling the template engine removes server-side rendering entirely, so escaping is never applied and user data must be concatenated manually, which does not mitigate XSS. It is tempting when templates are unused or output is fully static, but the stem requires rendering user-supplied data safely via EJS escaping.

Implementing a global regex filter

Why it fails: A global regex filter is a denylist that attackers bypass with encoding, malformed tags or unusual vectors, and it does not encode output. It is tempting as centralised input sanitisation, which suits coarse validation, but the stem requires context-aware output encoding, which EJS's <%= %> tag performs.

Set the Content-Type header to application/json

Why it fails: Content-Type describes the request body's media type; it is client-controlled and carries no server-issued secret, so a forged cross-site request can set application/json just as easily. It is tempting because JSON endpoints often reject form-encoded posts, and would be correct for content negotiation or blocking simple form-based CSRF vectors, not for token validation.

Use a stateless session strategy with no tokens

Why it fails: A stateless session strategy removes the server-side session cookie, but CSRF exploits ambient credentials such as cookies or HTTP Basic authentication, so dropping sessions alone leaves state-changing endpoints unprotected. It is tempting because stateless APIs are common; the correct configuration enables Spring Security's CSRF token validation for those requests.

Enable csrf().disable() in the SecurityFilterChain

Why it fails: Disabling CSRF removes Spring Security's synchroniser token filter, so state-changing requests are accepted without any token validation — the opposite of prevention. It is tempting because it stops 403 errors during API development, and would be correct for a stateless REST API authenticated solely by bearer tokens, where no session cookie exists to forge.

Disable SSL on the API endpoint

Why it fails: Disabling SSL increases the attack surface.

Increase the request timeout

Why it fails: Request timeout governs how long the server waits for a response, not which fields the binder maps onto the model. It would be correct for slow upstream dependencies, but it leaves over-posting of privileged properties unaddressed.

Store user passwords in plaintext

Why it fails: Storing passwords in plaintext addresses credential confidentiality, not model binding, so it cannot prevent Mass Assignment. It is tempting because plaintext storage is a genuine security defect, and hardening credential handling would be the right focus when the scenario concerns password storage or authentication rather than binding untrusted input to object properties.

--ignore-cve

Why it fails: --ignore-cve is not a valid OWASP Dependency-Check parameter, so the scan would error rather than suppress the named vulnerabilities. It is tempting because the name reads like a suppression flag, but Dependency-Check handles false positives through a suppression XML file referenced with --suppression.

--exclude-all

Why it fails: Dependency-Check suppresses false positives through a suppression XML file referenced with --suppression, which matches specific CVE identifiers and package coordinates. --exclude-all instead omits entire dependency paths from scanning, so genuine vulnerabilities in those libraries go unreported. It suits excluding vendored or test-only directories from analysis, not filtering individual findings.

--skip-analysis

Why it fails: --skip-analysis disables the entire dependency analysis, suppressing all findings rather than the specific false positives, which defeats the scan. It is tempting as a blunt way to silence noise, but it is intended for bypassing analysis entirely, not for targeted suppression, which uses a suppression XML file.

Database connection timeout

Why it fails: A database connection timeout is a runtime availability or configuration symptom, not a memory management defect, so static analysers examining C++ source cannot flag it. It is tempting because timeouts cause application failures, but they are diagnosed through monitoring and connection-pool tuning, whereas Fortify and Coverity target buffer overflows and memory leaks.

Business logic flaws

Why it fails: Business logic flaws concern intended application behaviour rather than memory handling, so static analysers cannot reliably detect them; they require manual review or dynamic testing. It is tempting because logic errors cause serious vulnerabilities, but Fortify and Coverity flag concrete memory misuse such as buffer overflows, use-after-free and uninitialised pointers.

Zero-day authentication bypass

Why it fails: Static analysis inspects source code paths for memory misuse such as buffer overflows or use-after-free; a zero-day authentication bypass is a runtime exploit of unknown logic, invisible to pattern-based code scanning. It is tempting because authentication flaws are severe, but detecting them requires dynamic testing or threat intelligence, not Fortify or Coverity.

style-src

Why it fails: style-src governs stylesheet origins, not script origins; script-src is the directive that whitelists JavaScript sources. It is tempting because both are fetch directives written in the same CSP syntax, and style-src would be correct if the policy needed to restrict where CSS files load from.

img-src

Why it fails: img-src governs image loading origins, so it leaves script execution unrestricted — the browser still fetches and runs JavaScript from any origin the default-src or script-src permits. It is tempting because CSP directives share identical source-list syntax, making them easy to confuse. img-src would be correct when restricting where images, icons or CSS-referenced graphics may load from.

connect-src

Why it fails: connect-src governs fetch, XHR, WebSocket and EventSource endpoints, so it never gates script loading. It is tempting because scripts frequently call APIs, but that outbound connection control is separate from the script-src directive that actually whitelists executable JavaScript origins.

Syntax checking

Why it fails: Syntax checking only verifies that code parses against the language grammar; it has no notion of data sensitivity or logging semantics. It is tempting because SonarQube runs parsers first, but detecting sensitive information written to logs requires static analysis rules that trace tainted data into logging calls.

Unit testing

Why it fails: Unit testing executes individual functions with mocked inputs and asserts behaviour, so it cannot scan log statements across the codebase for sensitive-data patterns. It is tempting because tests can catch a leak in one function, but detecting improper logging generally requires static analysis rules inspecting source.

Dead code detection

Why it fails: Dead code detection flags unreachable or unused code paths, which says nothing about whether a reachable log statement writes sensitive values. It is tempting because removing unused code reduces attack surface, but the stem requires identifying live logging calls that expose sensitive information, which static taint analysis performs.

To store the user's password

Why it fails: The state parameter holds an unguessable value echoed back on redirect to prevent cross-site request forgery; credentials are never placed in it. It is tempting because it persists across the redirect, but storing passwords there would expose them in URLs and logs.

To track the user's location

Why it fails: The state parameter carries an opaque anti-CSRF value correlating the authorisation request with the callback; it conveys no geolocation data. It is tempting because it travels through the browser redirect, but its purpose is binding the response to the initiating client session, not locating the user.

To encrypt the access token

Why it fails: The state parameter is an opaque anti-CSRF token; token confidentiality relies on TLS and, for OAuth2, PKCE or token binding. It is tempting because it accompanies the access token through the redirect, but it performs no encryption function.

To encrypt source code

Why it fails: An SBOM is a machine-readable inventory of components and dependencies; it performs no cryptographic function, so it cannot encrypt source code. Encryption is handled by code-signing or repository tooling. The SBOM's actual purpose is vulnerability and licence tracking across third-party libraries, which is why it is required for supply-chain risk management.

To speed up build times

Why it fails: An SBOM lists components, versions and dependency relationships; it does not participate in compilation, so build duration is unaffected. The temptation is that dependency visibility can inform caching or pruning decisions, but that is a downstream optimisation, not the SBOM's function. Its purpose is identifying vulnerable or unlicensed third-party components.

To replace the need for unit testing

Why it fails: An SBOM inventories third-party components and their versions; it executes no code and asserts no behaviour, so it cannot substitute for unit testing. It is tempting because both support assurance, but they address different risks. The SBOM's role is identifying vulnerable or unlicensed dependencies, not verifying application logic.

Session Hijacking

Why it fails: Parameterised queries constrain SQL statement structure, leaving session token theft and fixation untouched; session hijacking is mitigated by secure cookie flags, token binding and session expiry. It is tempting because both concern untrusted input reaching a backend, yet the mechanisms and defences are entirely separate.

Insecure Deserialization

Why it fails: Parameterised queries prevent SQL injection by separating code from data; they do not validate serialised object graphs, so insecure deserialisation persists. It is tempting because both involve untrusted input, but deserialisation flaws require type allow-listing and integrity checks, not query parameter binding.

Directory Traversal

Why it fails: Parameterised queries bind user input as data values, so they do not affect filesystem path handling; directory traversal arises from unsanitised file paths, not SQL statement structure. It is tempting because both involve untrusted input, but traversal requires path canonicalisation and allow-listing, not query parameterisation.

It increases execution speed

Why it fails: A hardened base image reduces attack surface by removing unnecessary packages, shells and known-vulnerable components; execution speed is unrelated to hardening. Speed gains come from image size and layer caching, so this option confuses a performance property with the security benefit.

It automatically encrypts application logs

Why it fails: Log encryption is handled by the logging pipeline or storage layer, not by the base image's contents; hardening only strips unnecessary packages and permissions. It is tempting because hardened images do reduce attack surface, which is their actual purpose, but they neither configure nor manage application log encryption.

It eliminates the need for patching

Why it fails: Hardening removes unnecessary packages and tightens permissions, but patching remains necessary for the packages retained and for the application layer. It is tempting because a minimal image has fewer vulnerabilities to patch, yet new CVEs still require updates; only a distroless or scratch image with no OS packages approaches that reduction.

Store it in a public environment variable

Why it fails: A public environment variable exposes the key to any process, log dump, or container inspection on the host, and it is not encrypted at rest. It is tempting because environment variables keep secrets out of source control. A managed secrets service encrypts the value, controls access via identity, and enables rotation.

Add it to the .gitignore file

Why it fails: .gitignore only prevents untracked files from being committed; it does nothing for a key already hardcoded in a source file, which remains in the repository and its history. It is tempting because it stops accidental commits of credential files. The key must be moved to a secrets manager and rotated.

Obfuscate the key in the code

Why it fails: Obfuscation merely transforms the key's representation; the secret remains embedded in source and recoverable by anyone with the code. It is tempting as a quick hardening step against casual reading. A dedicated secrets manager stores the key outside the codebase, issues it at runtime, and supports rotation and audit.

Checking the file size

Why it fails: Checking file size limits resource consumption but does not inspect content, so a small malicious file still executes; the defence must validate type and content. It is tempting because size limits are a legitimate control against denial-of-service and storage exhaustion, and would be correct when the threat is oversized uploads rather than executable payloads.

Validating the file extension only

Why it fails: Extension validation relies on a client-supplied name that an attacker can rename, so a .php payload sent as .jpg passes; content and type verification is required. It is tempting because extension allow-lists are a standard upload control, and would be correct if filenames could be trusted and the web server never executed renamed files.

Enabling execution permissions on the upload folder

Why it fails: Granting execute permission on the upload directory lets any uploaded script run server-side, directly enabling the RCE the question asks you to prevent. It is tempting because some architectures do execute uploaded binaries deliberately, such as plugin or job-processing directories, but those require strict validation and isolation rather than open execution.

Cross-Site Scripting

Why it fails: ORMs parameterise queries, neutralising SQL injection, yet they do not sanitise data on output. Cross-site scripting arises when stored or reflected values are rendered into HTML without encoding, which the ORM never handles. Output encoding and CSP remain the developer's responsibility.

Brute force attacks

Why it fails: Brute force attacks target authentication endpoints by guessing credentials, a concern entirely outside the ORM's query-generation scope, so built-in ORM features cannot mitigate them. It tempts because ORMs sit near login data access, but credential-guessing defence belongs to account lockout, rate limiting and MFA at the authentication layer.

Buffer overflows

Why it fails: Buffer overflows occur in unmanaged memory handling such as C string operations, whereas ORM frameworks run atop managed runtimes and generate parameterised queries, so they neither introduce nor prevent them. It tempts because injection flaws share the ORM's data-access territory, yet overflow risk is determined by the language runtime, not the mapping layer.

Encryption with a symmetric key

Why it fails: Symmetric encryption is reversible, so the key holder can recover every plaintext password, and key compromise exposes the whole set. It tempts because encryption at rest is a genuine control for confidential data; it would be correct for data that must be decrypted later, whereas passwords only need verification via a salted one-way hash.

Storing in a configuration file

Why it fails: A configuration file is plaintext storage outside the database's access controls, so it neither protects nor verifies passwords. It tempts because application settings and connection strings legitimately live in config files; that pattern suits non-credential parameters, while passwords require salted hashing with a per-user salt.

Base64 encoding

Why it fails: Base64 is a reversible encoding, not a protection mechanism, so anyone with database access can trivially decode every stored password. It tempts because it obscures values from casual reading and is legitimately used for transporting binary data; it would suit encoding non-secret payloads, never credential storage.

Hardware procurement

Why it fails: Hardware procurement concerns acquiring physical infrastructure, which sits outside the SSDLC's process scope of requirements, design, implementation, verification and release. It tempts because development environments need hardware, but procurement is an operational prerequisite, not a security activity embedded in the lifecycle itself.

Marketing strategies

Why it fails: Marketing strategies shape product positioning and demand, not secure software construction, so they contribute nothing to threat modelling, secure coding or verification activities within an SSDLC. The option tempts because commercial viability genuinely matters to product success, but that belongs to business planning, not the security engineering lifecycle.

Unlimited project budget

Why it fails: Budget size does not determine whether security activities such as risk assessment, secure design or code review occur; an SSDLC is defined by its processes, not its funding level. It tempts because security tooling and training do cost money, yet adequate resourcing is an enabler rather than an essential lifecycle component.

The use of internal logging

Why it fails: Logging merely records events and never reconstructs attacker-controlled objects, so it cannot introduce deserialization flaws. It is tempting because logs often capture serialised payloads during incident response, but the vulnerability originates in functions such as Java's ObjectInputStream or PHP's unserialize(), which rebuild objects from untrusted bytes.

The use of JSON.parse()

Why it fails: JSON.parse() only produces plain data objects and cannot instantiate classes or invoke methods, so it does not create deserialization gadgets. It is tempting because JSON is a serialisation format, but the vulnerability arises in languages whose deserialisers reconstruct executable objects, such as Java or PHP.

The use of static typing

Why it fails: Static typing constrains values at compile time and does not govern how bytes become objects at runtime, so it cannot cause insecure deserialization. It is tempting because typed languages are often assumed safer, yet the flaw lies in native serialisation mechanisms like Java's readObject or Python's pickle, which execute during object reconstruction regardless of declared types.

HTTP Basic Auth

Why it fails: HTTP Basic Auth sends reusable base64 credentials per request and does not bind them to a service identity or channel, so a leaked credential grants standing access. It is tempting because it is trivial to add to HTTP-based transports, but gRPC's recommended mechanism is mutual TLS with per-service certificates.

IP allow-listing

Why it fails: IP allow-listing authenticates nothing; it filters by source address, which is spoofable inside a compromised network and breaks with dynamic pod addressing. It is tempting as a cheap network-layer control, but gRPC service-to-service authentication requires cryptographic identity, typically mutual TLS with workload certificates.

Shared API keys in headers

Why it fails: Static shared API keys are bearer secrets: any service holding the key can impersonate any other, and rotation is manual. It is tempting because gRPC metadata carries headers easily, but the recommended mechanism is mutual TLS, where each service presents its own certificate for peer verification.

Relying on antivirus software

Why it fails: Antivirus scans files and executables on endpoints; it cannot intercept script injected into a web page and executed by the browser, which is the XSS delivery path. It is tempting because endpoint protection genuinely blocks malware payloads, and would be correct for stopping trojan downloads rather than reflected or stored script execution.

Disabling cookies

Why it fails: Disabling cookies removes a session-theft target but does not stop script injection or execution in the victim's browser, which is what XSS prevention requires. It tempts as a hardening measure, and would suit reducing session risk alongside output encoding.

Using insecure HTML comments

Why it fails: Insecure HTML comments can leak server-side code or data into rendered pages, and browsers may parse comment content unpredictably, so they add exposure rather than prevent XSS. They tempt as documentation aids, but output encoding and input validation are the actual defences.