Foundations — Security — OWASP Top 10, input validation, authentication vs authorization

Before you can safely read the parent note Security — OWASP Top 10, you need to own every symbol and word it quietly assumes. Below, each idea is built from nothing, drawn as a picture, and justified by the question it answers. Nothing is used before it is defined.

0. The boundary picture (the whole subject on one page)

Everything starts here. On the left is the outside world: browsers, phones, scripts, attackers — nobody you control. On the right is your code: the trusted machine that reads a request and does something (reads a file, runs a database query, returns a page). Between them is a single line called the trust boundary.

Why the topic needs it: Every OWASP category is a specific way an attacker pushes something across this line and gets your trusted side to obey it. Keep this picture in your head and the rest is bookkeeping.

1. Input, output, and "interpreter"

The dangerous word is interpreter.

Why the topic needs it: "Injection" (OWASP A03) literally means untrusted input reached an interpreter and got run as code. You cannot understand that sentence until "interpreter" is a concrete thing in your mind. Interpreters here connect to SQL Databases (the SQL interpreter) and HTTP and Web Fundamentals (the browser).

2. The request/response loop

The parent note keeps saying "on every request." Here is what a request is.

Read the pieces of GET /api/orders/1042:

• GET — the method (the verb: fetch, don't change anything).
• /api/orders/1042 — the path, and 1042 is a value the client typed and can change.

That is why the changeable 1042 above is the seed of an IDOR attack: nothing stops the client from typing a different number.

Why the topic needs it: HTTP and Web Fundamentals is the transport for nearly every example. Sessions/tokens (next) exist only because raw requests are forgetful.

3. Identity, subject, and permission

Three words the parent note leans on constantly.

These three feed directly into the two headline words:

Why the topic needs it: The entire A01 (Broken Access Control) and A07 (Auth Failures) categories are failures of exactly these two steps. Getting the words precise is what stops you confusing "logged in" (AuthN done) with "allowed" (AuthZ done). See Principle of Least Privilege for how permissions should be kept minimal.

4. Allowlist vs blocklist (the two shapes of a rule)

The parent note claims allowlists are "strongest." Here is the picture that proves it.

Why the topic needs it: "Input validation — the master defense" is really "prefer allowlists." This idea also powers default-deny authorization: start by forbidding everything, then allow the known-good — the same shape applied to permissions.

5. Symbols used in the parent's formula

The parent note writes a "why parameterization is safe" formula. Every symbol, decoded:

So $P(\text{query})$ means "the instructions the database extracts after reading the glued string." When you glue $u$ inside the text, $u$ can add branches to that tree — new commands.

Now the safe alternative. Instead of gluing, you send the template alone to be parsed, and hand the user input over separately as a plain value. Two more symbols make this precise:

With parameterization the interpreter fixes its instruction structure from the template only, and the user input lands in one of those value slots. In symbols the parent writes: $P_{\text{parsed}}=P(T),u\in \text{values}$

Read it as two facts: (1) the committed parse tree equals the parse tree of the template alone — the user input contributed zero nodes to it; and (2) the user input $u$ is a member of the value set, i.e. it occupies a leaf slot and is never parsed as SQL. Because $u$ cannot add a node, parse-tree injection drops to nothing — the parent's $\to 0$.

Prerequisite map

Equipment checklist

Ready? Return to the parent topic — or, in Hindi/English, the Hinglish note. When you meet threats formally, Threat Modeling builds directly on the boundary picture from section 0.