Application Security Engineer interview questions

I trace the value across call boundaries and record where its security properties actually change.

• I start from concrete sources such as Express `req.query`, follow returns, parameters, fields, callbacks, and aliases, and end at sinks such as `db.query` or `child_process.exec`.
• I inspect wrappers rather than trusting their names, because `runSafeQuery` may still concatenate a string before calling the database driver.
• I use a call graph or a CodeQL path query to confirm interprocedural routes, then review each reported path for feasible control flow.
• I add a focused test with attacker-controlled input and a safe counterpart to confirm which branch reaches the sink and whether the intended sanitizer changes the value.

I model separate taint kinds because a transformation safe for one sink can be unsafe for another.

• HTTP parameters, message payloads, and database values originally supplied by users are sources, while SQL execution, HTML rendering, and process creation are distinct sink classes.
• Parameter binding clears SQL taint only for value positions; HTML encoding clears output for one rendering context; neither makes a value safe for a shell.
• I model propagation through collections, object properties, builders, and framework helpers so the rule does not lose taint at ordinary application abstractions.
• I add negative tests for safe flows and positive tests for each source-to-sink combination before enabling the model in CI.

I mark a helper as a sanitizer only when its contract removes the exact exploitability required by a specific sink.

• An `isUUID` check can constrain a path or identifier, but it does not sanitize the original string for HTML or a command line.
• I read the implementation for Unicode, decoding, length, and failure behavior, and confirm callers use the validated return value rather than the original input.
• I prefer modeling a typed transformation such as `parseTenantId(): TenantId` over a boolean guard because the safe value is harder to lose.
• Regression tests include bypass candidates and a rule test proving taint stops only on the intended branch.

I rely on auto-escaping only for the output context the framework documents and keep track of every escape hatch.

• React text interpolation and Jinja HTML templates normally encode HTML text, but `dangerouslySetInnerHTML`, Jinja `safe`, and raw template blocks remove that protection.
• HTML-text encoding is not sufficient inside JavaScript, CSS, or a URL, so those contexts need dedicated APIs or strict allowlists.
• Server-rendered values can become DOM XSS later if client code passes them to `innerHTML`, `insertAdjacentHTML`, or an unsafe third-party widget.
• I review template configuration and custom filters because disabling autoescape globally turns a framework guarantee into an application-wide assumption.

I map the changed trust boundaries first, then spend review time on code that moves or interprets untrusted data.

• I inspect route, schema, authorization, serializer, template, query, filesystem, and outbound-request changes before mechanical refactors or generated files.
• I trace one complete request from entry point to side effect and compare the new path with the existing authentication and tenant-isolation pattern.
• I examine removed checks and changed defaults in the diff, then use blame or surrounding code when the patch depends on an unstated invariant.
• I ask for focused tests around negative authorization, malformed input, and boundary cases rather than approving based only on happy-path coverage.

I focus on APIs that reinterpret strings as code, markup, paths, queries, or commands.

• `eval`, `Function`, string-based timers, and `vm.runInNewContext` are code-execution sinks even when the input first passes through JSON parsing.
• `child_process.exec`, `execSync`, and `{ shell: true }` invoke a shell; `spawn` or `execFile` with a fixed executable and argument array avoids shell parsing.
• `innerHTML`, `insertAdjacentHTML`, and React `dangerouslySetInnerHTML` require context-appropriate sanitization such as a tightly configured DOMPurify policy.
• Dynamic `require`, filesystem paths, and object merges need allowlists or canonicalization because they expose traversal and prototype-pollution paths.

I review Java APIs that execute expressions, construct queries, deserialize objects, or start operating-system processes.

• `Runtime.exec(String)` does not automatically invoke a shell: it splits the string into an executable and arguments, so shell metacharacters alone are not interpreted, although attacker-controlled executable names or options still create argument and process-selection risks.
• `new ProcessBuilder("sh", "-c", value)` explicitly invokes a shell and is vulnerable when `value` is untrusted; I instead use a fixed executable, separate arguments, and allowlisted options.
• `Statement.execute` with concatenation is a SQL sink; `PreparedStatement` protects values but cannot parameterize table names or sort directions.
• SpEL, OGNL, template or scripting evaluation, and `ObjectInputStream` over untrusted bytes can expose code-execution paths and require removal or narrowly constrained designs.

I flag Python APIs that deserialize objects, evaluate expressions, invoke shells, or build paths and queries from strings.

• `pickle.loads`, `marshal.loads`, and unsafe `yaml.load` can construct attacker-chosen objects; JSON or `yaml.safe_load` is preferable for plain data.
• `eval`, `exec`, and dynamic imports execute code, while `subprocess.run(..., shell=True)` adds shell metacharacter interpretation.
• SQL f-strings remain injectable; DB-API placeholders must carry values, with identifiers selected from an allowlist or composed by the driver's SQL builder.
• `tarfile` or `zipfile` extraction and `pathlib` joins need destination containment checks before writing files.

A path check and a later open are separate operations, so an attacker can replace a symlink or directory entry between them.

• `realpath` followed by `open` still leaves a race window if another process can modify the checked path.
• On Linux I prefer descriptor-relative operations such as `openat` with `O_NOFOLLOW`, trusted directory descriptors, and restrictive ownership and permissions.
• I perform authorization and file use on the same opened descriptor, then use atomic `rename` for publication instead of re-resolving the pathname.
• Temporary files come from `mkstemp` or an equivalent API with exclusive creation, not a predictable name checked with `exists` first.

A security check can become stale when concurrent requests change the protected state before the write commits.

• Two redemption requests can both observe `used = false` and spend one coupon twice if the check and update are separate statements.
• I encode the invariant in one conditional update, a unique constraint, or a transaction with the required row lock, then accept only the winning result.
• For authorization tied to mutable membership, the policy check and sensitive mutation belong in the same transaction or trusted database operation.
• Idempotency keys stop duplicate retries, but they do not replace locking or constraints for two different requests targeting the same resource.

I constrain the entire outbound request lifecycle, not just the URL text received from the user.

• I parse with one well-defined URL library, allow only `http` or `https`, reject credentials and unusual numeric IP forms, and resolve every address before connecting.
• The connection layer blocks loopback, link-local, RFC 1918, IPv6 local ranges, cloud metadata addresses, and disallowed ports even after DNS rebinding.
• Redirects are disabled or each target is revalidated, with response-size, timeout, and redirect-count limits.
• High-risk fetchers run behind an egress proxy or isolated network whose allowlist makes internal services unreachable by design.

I trace where typed query construction falls back to raw SQL and verify which parts still receive structural interpretation.

• APIs such as SQLAlchemy `text`, Prisma `$queryRawUnsafe`, Knex `raw`, Hibernate native queries, and string-based `orderBy` deserve sink-level review even when surrounding code uses an ORM.
• Placeholders bind values only; table names, column names, operators, sort directions, and SQL fragments must come from fixed mappings or builder APIs, not request strings.
• I inspect wrappers and tagged-template behavior because some APIs parameterize interpolations while similarly named unsafe variants concatenate them.
• Tests use metacharacters in values and unexpected identifier choices, then inspect generated SQL and results to prove data never changes query structure.

I examine both attacker-supplied patterns and fixed patterns whose worst-case backtracking grows sharply with input length.

• Nested or overlapping quantifiers, ambiguous alternation, and repeated groups followed by a failing suffix are warning signs; anchors alone do not make such a pattern linear.
• I cap input length before matching and replace ambiguous expressions with simpler parsing, bounded quantifiers, or a linear-time engine such as RE2 where its feature set is sufficient.
• User-supplied regex is disabled or compiled through a constrained syntax and strict size limits rather than trusted because compilation succeeded.
• Regression benchmarks include near-miss adversarial strings and enforce a time budget, while process isolation or timeouts provide only defense in depth.

Prototype pollution occurs when attacker-controlled property paths modify an object's prototype instead of only its own data.

• Recursive merge and path setters must reject `__proto__`, `prototype`, and `constructor` at every depth, not only at the top level.
• I update vulnerable merge libraries and prefer schema-driven copying into explicit DTOs or null-prototype maps for dictionary data.
• Authorization and configuration code must use own-property checks such as `Object.hasOwn` rather than trusting inherited defaults.
• Tests submit nested JSON and query-string forms, then verify both ordinary objects and security decisions remain unchanged.

I bind the request to a strict operation-specific form object and keep the JPA entity outside the web binding boundary.

• The form declares only editable fields, while `WebDataBinder.setAllowedFields` adds a framework-level allowlist and `setIgnoreUnknownFields(false)` prevents unknown properties from being ignored by default.
• Because disallowed fields are suppressed rather than rejected automatically, I reject the request when `BindingResult` has errors or `getSuppressedFields()` is nonempty and map strict binding failures to a 400 response.
• The service copies validated values into a loaded, tenant-scoped entity and derives ownership, role, and account ID from authenticated server context, so nested paths cannot select privileged state.
• MVC tests submit privileged, unknown, and nested names such as `roles[0]` and assert rejection plus the absence of persistence side effects.

I choose a data-only format with an explicit schema and avoid formats that can instantiate arbitrary runtime types.

• JSON, Protobuf, or a constrained CBOR schema carries primitives and declared messages without Java `ObjectInputStream`, Python pickle, or .NET type-name activation.
• Input limits cover nesting depth, collection size, string length, and total bytes because safe object construction can still exhaust memory or CPU.
• Authenticity such as an HMAC prevents tampering but does not make a dangerous deserializer safe if a signing key or trusted producer is compromised.
• Legacy native serialization is isolated behind an allowlist and migration boundary, with gadget-capable dependencies removed where possible.

I disable DTDs and all external entity resolution, then verify those settings on the exact parser and version in use.

• The parser must not fetch external general entities, parameter entities, schemas, or XSLT resources from network or local files.
• I apply input-size, entity-expansion, nesting, and processing-time limits to cover denial-of-service variants such as exponential entity expansion.
• If a business format requires a schema, it is loaded from a trusted local catalog rather than a URI supplied by the document.
• A regression fixture attempts file disclosure and an outbound callback so tests prove the configuration rather than merely setting a flag.

I ensure that validation, authorization, signature handling, and business logic operate on one unambiguous interpretation of the request.

• Duplicate object keys, out-of-range numbers, non-finite values, invalid Unicode, and excessive nesting are rejected before a gateway and application can choose different meanings.
• Schema validation runs on the same parsed value that business code consumes, rather than validating raw text in one component and reparsing it with another library.
• If a protocol signs canonical JSON, every producer and verifier follows the same documented canonicalization; otherwise I verify the exact raw bytes before parsing.
• Differential fixtures send ambiguous payloads through the production gateway and application parsers and assert identical rejection and no side effects.

I treat the decoder and every derived artifact as untrusted processing inside an isolated pipeline.

• The service checks magic bytes and decodes the image with a patched library, then re-encodes a supported format instead of preserving attacker-controlled metadata or polyglot content.
• Pixel count, dimensions, frame count, decompressed memory, CPU time, and output size are bounded before thumbnail generation.
• Processing runs as a non-root identity in a sandbox with no network, a read-only filesystem, and a fresh temporary directory.
• Original and generated objects use random keys in private storage, and downloads receive fixed content types plus `Content-Disposition` rather than browser sniffing.

I extract into an isolated temporary directory under strict path and resource limits, then validate the resulting file set.

• Each entry is normalized and resolved beneath the destination; absolute paths, parent traversal, symlinks, hard links, devices, and duplicate normalized names are rejected.
• Limits cover entry count, per-file size, total expanded size, compression ratio, nesting, and processing time to stop archive bombs.
• Extraction uses safe library APIs and descriptor-relative writes, then a second stage parses only allowlisted file types as an unprivileged worker without network access.
• Nothing is published until the entire import succeeds, and cleanup removes partial output on every failure path.