Application Security Engineer interview questions

I would trace the untrusted value from its source through every transformation to the network sink before deciding whether it is vulnerable.

• Mark `req.query.url` as the source because the caller can change query parameters without using the normal UI.
• Follow assignments, helper calls, parsing, validation, and redirects until the value reaches `fetch`, Axios, or another outbound request API.
• Record controls on the path, then verify they constrain the final destination after DNS resolution and redirects rather than only checking the original string.

I would treat every value controlled outside the application's trust boundary as untrusted, even if a framework parsed it first.

• Request paths, query parameters, bodies, headers, and cookies are direct client-controlled sources.
• Database rows, queue messages, uploaded files, and partner API responses remain untrusted when another user or system can influence them.
• A TypeScript type or JSON parser changes representation but does not establish that a value is safe or authorized.

A sink is an operation where attacker-controlled data can gain a dangerous interpretation or affect a protected resource.

• SQL execution, shell process creation, template rendering, and `innerHTML` can interpret data as code or syntax.
• Filesystem writes, redirects, outbound HTTP calls, and deserializers can cross important application boundaries.
• The same value may be harmless in a log message but dangerous in a shell command, so I classify the sink by its actual API and context.

Validation decides whether input fits the application's rules, while output encoding prevents valid data from becoming syntax in its destination.

• A comment may legitimately contain `<`, quotes, or ampersands, so rejecting every special character would damage normal text.
• When rendering into HTML text, the template engine must encode characters for that HTML context.
• If the same value enters a URL or JavaScript string, it needs the encoder or safe API for that different context.

I would map a small set of public sort values to fixed SQL identifiers instead of inserting the caller's string into the query.

• For example, map `date` to `created_at` and `total` to `total_cents`, rejecting every other value.
• Database placeholders bind values, not table or column identifiers, so parameterization alone does not solve this case.
• The mapping also prevents accidental access to internal columns that happen to have valid SQL names.

The API must enforce the role rule because a caller can bypass the React form and send requests directly.

• Validate the server-side value against the exact roles allowed for this operation, not every role known to the system.
• Authorize who may assign a role separately, because a valid value such as `admin` can still be forbidden for the caller.
• Add an API test that sends `admin` and an unknown value as a normal user and expects rejection.

A trust boundary appears at each transition where components have different identities, permissions, or control over data.

• Browser input crosses into the API, so the API authenticates, validates, and authorizes it independently of the UI.
• A queued job crosses from the API to a worker, so the worker verifies message shape and does not assume every producer is correct.
• The API and worker cross into the database under service identities whose permissions should match their separate duties.

I would separate the capabilities so code that generates reports cannot delete accounts or modify unrelated records.

• Give the reporting path a database identity limited to the required views or `SELECT` operations.
• Put deletion behind a distinct service method and authorization check rather than exposing a general database client to every module.
• Run background converters and parsers under an unprivileged operating-system account with access only to their working directory.

I would return a stable generic error to the client and keep actionable details in restricted server logs.

• The response should omit SQL text, table names, filesystem paths, stack frames, and environment values.
• Log the exception with a correlation ID, request route, and safe context so developers can investigate without exposing internals.
• Map expected failures such as duplicate email to a specific safe response instead of leaking the raw database exception.

Security checks should apply to the same normalized value the sensitive operation will use.

• A path check before URL decoding may miss `%2e%2e/`, while the filesystem later receives `../`.
• Parse and normalize once with the platform library, reject invalid or ambiguous forms, then use that checked result.
• Avoid repeated decoding because double-encoded input can change meaning after the first validation step.

The code mixes caller-controlled data into SQL syntax, so the email can change the query structure.

• Replace concatenation with the driver's placeholder, such as `WHERE email = $1`, and pass `email` in the values array.
• Do not repair it with manual quote escaping because database modes and edge cases make that fragile.
• Add a regression test with a quote-containing email and confirm it remains one bound value rather than altering the statement.

The client may inject MongoDB operators instead of supplying the simple field values the application expects.

• Input such as `{"password": {"$ne": null}}` changes query semantics when arbitrary objects reach `find`.
• Build a new filter from validated scalar fields, for example `{ email: validatedEmail }`, rather than forwarding the request object.
• Reject keys beginning with `$`, but treat that as backup protection rather than a substitute for an explicit schema.

I would avoid the shell and pass a fixed executable plus separate arguments to `subprocess.run`.

• Use an argument list such as `["convert", input_path, output_path]` with `shell=False` so metacharacters stay inside one filename argument.
• Generate server-controlled paths and enforce file rules before starting the process.
• Run the converter with low operating-system privileges, a timeout, and resource limits to contain parser failures.

The application treats user input as Jinja template source, which can expose data or execute dangerous template expressions.

• Keep the template fixed in application code and pass the user value as data, such as `render_template("message.html", message=value)`.
• Leave Jinja autoescaping enabled for HTML output, but do not mistake autoescaping for protection against server-side template injection.
• Test an expression-shaped value and confirm it appears as text rather than being evaluated.

Unescaped input can add LDAP filter operators and change which directory entries match.

• Concatenating a username into `(&(uid=` plus input plus `)(active=true))` lets characters such as `*`, `(`, and `)` affect syntax.
• Use the LDAP library's filter-escaping or filter-builder API for assertion values rather than writing a generic backslash replacement.
• Keep the directory service account read-only and scoped to the required subtree to limit impact if a query is wrong.

The joined path may still escape the report directory, especially when `name` is absolute or contains parent segments.

• Prefer accepting a report ID and looking up a server-owned filename instead of exposing filesystem names to callers.
• If names are required, resolve both paths with `pathlib.Path.resolve` and require the target to be relative to the resolved report root.
• Review symlink handling and open the checked target without following links where the platform supports it, then test absolute and encoded parent paths.

It must verify every archive entry resolves inside the chosen extraction directory before writing it.

• Reject absolute entry names and parent traversal, then compare each normalized destination with the normalized extraction root.
• Treat archive-created symlinks as dangerous because a later entry can write through them outside the directory.
• Apply limits on entry count and total expanded size so a valid path check does not leave a decompression denial of service.

I would treat the uploaded bytes as hostile and constrain validation, storage, and parser execution separately.

• Enforce request and expanded-size limits, check the file signature with a maintained parser, and reject malformed or encrypted files the feature does not support.
• Store the upload under a generated name in private quarantine rather than a web-served or executable directory.
• Run parsing in an isolated low-privilege worker with time and memory limits, then expose only the parsed result after authorization.

Native Java deserialization can instantiate attacker-selected object graphs whose methods trigger dangerous gadget behavior.

• A classpath containing a usable gadget chain can turn `readObject` into code execution before application validation runs.
• Prefer a simple format such as JSON mapped to a narrow data class and validate its fields against a schema.
• If legacy serialization cannot be removed immediately, apply a strict `ObjectInputFilter` allowlist and isolate the operation.

With modern PyYAML, `yaml.load` takes an explicit `Loader`, and that loader determines which YAML tags and Python types may be constructed; `yaml.safe_load` uses `SafeLoader`.

• For untrusted YAML, use `yaml.safe_load` or `yaml.load(..., Loader=yaml.SafeLoader)`, then validate the resulting data against the expected schema.
• Do not use `yaml.unsafe_load` or `UnsafeLoader` on untrusted input because they permit Python-specific object construction that can trigger dangerous behavior.
• Do not classify every `yaml.load` call the same way: inspect its loader and any custom constructors, and still enforce input size limits.