OWASP Security Testing Basics

A staging search box is the fastest door into the OWASP Top Ten. You type an apostrophe into product search, press Enter, and the page returns 500 Internal Server Error next to a trace that names products.sql line 42. You did nothing clever: the quote terminated the query string the developer built by concatenation. The 2021 revision files this under A03: Injection, alongside NoSQL injection and OS-command injection. SQL injection has kept its place on every Top Ten since 2003 because each new generation of code reintroduces it.

The list is a prioritization tool, not a checklist to walk top to bottom. Sort it by what a single unauthenticated request can reach:

A01 and A03 go first because neither one needs credentials to start.

Probe with a ladder of payloads that can change query logic but never change data. You have written authorization, you operate on your own rows, and you stop at proof:

'                           syntax-error page or 500    the quote reached a query
' OR '1'='1                 full catalogue, not one row tautology accepted
' AND '1'='2                empty result set            boolean logic reaches the DB
' UNION SELECT NULL--       column-count error          union extraction attempted
'; WAITFOR DELAY '0:0:5'--  response about 5s slower    time-based blind (SQL Server)

No DROP, no DELETE, nothing you would regret running against your own account. If 1=1 and 1=2 return different bodies you have boolean-blind proof; if the delay tracks your SLEEP(5) or WAITFOR, it is time-based. Either difference is the evidence a bug report needs.

Do not stop at the visible form. Sort parameters (?sort=name;--), filter values, X-Forwarded-For, and even cookie values frequently reach the same query unfiltered, and they are the inputs nobody remembered to validate.

Some sinks fire later than the request that planted them: a display name saved at signup is interpolated into an admin's report query two days afterward. Store the payload in your own profile, then visit the page that reuses it — that is second-order injection, and it is why input validation alone never closes A03.

Once you have proof, verify the fix instead of trusting the ticket. Parameterization keeps the query and the data in separate channels:

# vulnerable: the value edits the query text
cur.execute("SELECT * FROM products WHERE name = '" + name + "'")

# safe: query text is fixed, the value travels beside it
cur.execute('SELECT * FROM products WHERE name = %s', (name,))

Two checks close the finding: the search service's database account should hold only SELECT privileges so an injected statement still cannot delete, and any WAF rule you add is a filter, never the fix.

For an interview, "How would you test for SQL injection?" expects a procedure rather than a payload list: confirm scope and authorization, probe with non-destructive payloads, point at the boolean or timing delta as evidence, then verify parameterization and least privilege on the fix. sqlmap belongs in that story only as authorized automation after manual proof. The scan you ran in Automated Accessibility Audits checks markup and ARIA, not query logic — different tool, different blind spots. Error leakage and vulnerable packages are the quieter half of this topic, covered next; once you can force a verbose 500 you are ready for Auth and Session Security Checks.

You submit <script>alert(1)</script> in a comment field and the page prints it back as literal text. It is tempting to declare the field safe. Most naive filters block exactly that string, so a real test keeps rotating payloads until something executes, and the ones that usually survive are event handlers with no closing tag:

<script>alert(1)</script>            classic, stripped by naive filters
<img src=x onerror=alert(1)>         no closing tag required
<svg/onload=alert(document.domain)>  fires with no user interaction
" autofocus onfocus=alert(1)>        breaks out of a double-quoted attribute
' onmouseover=alert(1) x='           breaks out of a single-quoted attribute

Run every payload against your own account, stop at alert(document.domain) — proof of execution with no data touched — and record exactly where in the page it fired.

A practical order for a comment field: submit a marker (xqz123) first so you can find your input in the HTML, rotate payload variants one at a time, then view the comment as a second account. Check the moderator's queue and the email notification too, because a payload that only executes for the person reviewing content is still stored XSS, and moderators are the highest-value target on the page.

Three flavors are separated by one question: who else sees this payload, and did the server ever receive it?

DOM-based XSS hides because server-side filters and WAF rules never observe the input. One line shows the shape of the sink:

const term = new URLSearchParams(location.search).get('q');
document.getElementById('results').innerHTML = term;   // sink, no server round trip

textContent fixes it outright; when markup is required, sanitize with a maintained library such as DOMPurify before assignment.

Encoding is contextual, and that is the part interviewers listen for. Enter a marker, then the sequence <>'", and find where the input lands: an HTML body needs entity encoding (<), a double-quoted attribute needs quote encoding, a JavaScript string needs escaping of quotes, backslashes and </, and a URL parameter needs percent-encoding. One global <script> blacklist protects exactly one of those four contexts.

Verify the mitigations instead of assuming them. Fetch the header with curl -sI https://staging.example.com/profile | grep -i content-security-policy and look for a policy without unsafe-inline, then re-send the payload and confirm the console logs a violation instead of executing. A policy installed only on the login page is not a policy — check every response that renders user content. Then read what it actually restricts: a Content-Security-Policy such as default-src 'self'; script-src 'nonce-a1b2c3' blocks inline event handlers even after a payload makes it into the DOM, and an HttpOnly cookie keeps document.cookie from reading the session — although script running in your origin can still act as the user, so output encoding and CSP remain the real defense. One taxonomy note for interviews: XSS was standalone category A7 in 2017 and folded into A03 Injection in the 2021 list.

An XSS that lifts a token from localStorage is exactly the scenario Auth and Session Security Checks is built to close, and it arrives immediately after this topic's dependency audit.

Attackers read before they break in. Force an error the cheap way — request /api/products/abc where the id column is an integer, post malformed JSON ({"qty": }), or submit a 4 MB field — and then read what the response gives away. Repeat the probe with a wrong content-type (sending text/plain to a JSON endpoint) and with an oversized field, because each failure path is often handled by different middleware and leaks differently.

The production response should be boring:

HTTP/1.1 500 Internal Server Error
content-type: application/json
cache-control: no-store

{"error":"internal_error","referenceId":"7f3c91ab"}

The stack trace, query text, and file paths belong in the server log keyed by that referenceId, so a support ticket correlates to the exception without shipping diagnostics to strangers. Suppressing errors is not the fix: app.disable('x-powered-by') in Express, server.error.include-stacktrace=never in Spring, and DEBUG=False on every non-development deployment are configuration decisions your suite should assert — a response-header check belongs in the API regression pack next to your status-code assertions.

Dependencies are the quieter leak, and the scan is one command that CI should own:

npm audit --audit-level=high      # non-zero exit when high+ found; gates the build
npm audit fix                     # applies semver-compatible bumps only
npm audit fix --force             # may jump majors — never run it blind in CI
npm ls lodash                     # shows which path pulled the vulnerable version

The scan only means something when the tree is pinned: commit package-lock.json and install with npm ci in CI, because a loose npm install can resolve a different transitive version on the agent than on your laptop and let yesterday's finding vanish for the wrong reason. Use npm audit --omit=dev when the report must reflect only what ships.

Each ecosystem has its equivalent: pip-audit -r requirements.txt, mvn org.owasp:dependency-check-maven:check, bundle audit --update on Ruby. They all do the same job — reporting a version number that sits in the tree.

Severity is a queue, not a decision. Triage every finding with three questions: is the package reachable from the code you ship (a CVE reached only through jest's transitive minimist never executes in production), is a fixed version available and does it patch a path you actually call, and can you mitigate now — npm overrides pins a transitive dependency without waiting on its parent:

"overrides": { "minimist": "1.2.8" }

A deferral an auditor accepts in one line reads like this: minimist 1.2.5 to 1.2.8, reachable only through webpack-dev-server, dev-only, no runtime path, owner: platform, sprint 14 — version, reachability, owner, date. Gate the pipeline on runtime high and critical findings, log dev-only ones for a weekly cleanup, and require a ticket carrying the reachability reasoning for anything deferred. That discipline is the same one you built running axe in CI for Automated Accessibility Audits: a scanner earns its keep only when its output has an owner. Next you apply that rigor to credentials and sessions in Auth and Session Security Checks.