Security · Lesson 03

Securing APIs with Input Validation

Your API's attack surface is every byte it accepts. Client-controlled input is the most reliable path into a system, which is why injection attacks top vulnerability charts decade after decade. This lesson shows how to close that door.

The foundational rule: never trust the client

An API must treat every byte from outside its trust boundary as potentially hostile — even if the sender is your own mobile app running your own JavaScript. Why? Because an attacker can bypass the client entirely and send raw HTTP requests using curl, Burp Suite, or a custom script. The client-side validation you wrote, the JavaScript that "prevents" bad input, the mobile app that "only" shows valid options — none of it exists from the server's perspective. The only validation that counts is validation on the server.

Think of it like a bank teller window. The rope maze and the numbered ticket system are conveniences for honest customers. A determined bad actor ignores both and walks straight to the counter. The teller — the server — must check ID regardless of how the person arrived.

Allow-list vs deny-list

There are two philosophies for deciding what input is acceptable:

Allow-listing is almost always the right default. Specify the type, length, format, and allowed range for every field. If an input doesn't match, reject it with a 400. Do not try to sanitise it — sanitisation logic is where bypasses live.

# Allow-list examples — validate field by field

# Good: exact type + range check
age: integer, 0 ≤ age ≤ 150

# Good: constrained string with regex
username: string, matches /^[a-zA-Z0-9_]{3,32}$/"

# Good: enum for known values
status: one of ["active", "inactive", "pending"]

# Bad: blacklisting — an attacker encodes the blocked chars
comment: reject if contains "'" or "--"    # ← bypassed with Unicode lookalikes

Injection attacks — the anatomy

Injection happens when unsanitised user input is interpreted as code or commands by a downstream system. The three most common flavours in API contexts:

SQL injection — vulnerable vs fixed

Here is a login endpoint that concatenates user input into a SQL string, followed by how an attacker exploits it, followed by the correct parameterized fix:

// VULNERABLE — string concatenation (Node.js + mysql2 example)
const query = "SELECT * FROM users WHERE username='"
            + req.body.username
            + "' AND password='"
            + req.body.password + "'";
await db.query(query);   // ← executes attacker-controlled SQL

// SAFE — parameterized query (? placeholders, values passed separately)
const query = "SELECT * FROM users WHERE username=? AND password=?";
await db.query(query, [req.body.username, req.body.password]);
// The DB driver treats ? values as data, never as SQL syntax.
// A username of "' OR '1'='1" matches no row — it is just a string.

Parameterized queries (also called prepared statements) work because the SQL structure is fixed when it is sent to the database. The user-supplied values fill placeholders after the database has already parsed the query. No matter what string the attacker puts in, the database can never be tricked into treating it as SQL syntax.

Validate type, size, and range — everywhere

Injection is the dramatic example, but most real-world input bugs are quieter. A JSON body that contains a 50 MB string where you expected 200 characters can exhaust memory. A negative integer where you expected a positive quantity can underflow account balances. An unexpected field in a POST body can silently overwrite a protected attribute (mass-assignment — see below). Validate all of these at the boundary:

# OpenAPI 3.1 allow-list inline — validate in the schema, before any code runs
requestBody:
  content:
    application/json:
      schema:
        type: object
        required: [name, quantity]
        additionalProperties: false   # rejects unknown fields
        properties:
          name:
            type: string
            minLength: 1
            maxLength: 120
            pattern: '^[a-zA-Z0-9 \-]+$'
          quantity:
            type: integer
            minimum: 1
            maximum: 1000

Mass-assignment

Mass-assignment is what happens when you automatically bind all incoming JSON fields to a model object without checking which fields the caller is allowed to set. A simple example: your User model has an is_admin field. Your update endpoint is:

// UNSAFE — blindly bind all request fields to the user object
PATCH /v1/users/42
Body: { "email": "alice@example.com", "is_admin": true }

// The server does: user.update(request.body)   ← promotes caller to admin

// SAFE — explicit allow-list of writable fields
const allowed = ['email', 'display_name'];
const updates = pick(req.body, allowed);   // ignores is_admin entirely
user.update(updates);

Output encoding

Input validation stops bad data entering. Output encoding prevents stored bad data from being executed when it leaves. If you store a user-supplied string in a database and later return it inside an HTML response without encoding it, a stored XSS attack is possible. For JSON APIs the risk is lower (JSON is data, not markup), but any endpoint that renders HTML or serves files must encode output for the target context (HTML entities for HTML, URL encoding for URLs, etc.).

Under the hood: how it actually works

String concatenation creates injection because the database's SQL parser sees user input as part of the SQL grammar — it has no way to distinguish "code" from "data" when they arrive as one string. The parser treats the entire concatenated string as a SQL statement, so any SQL syntax embedded in the user's value becomes part of the query's structure.

# Step 1 — The vulnerable server code

# Developer intends this query:
SELECT * FROM users WHERE id = '<user_input>'

# Server code (Node.js):
const query = "SELECT * FROM users WHERE id = '" + req.body.id + "'";


# Step 2 — Attacker sends id = ' OR '1'='1

# Resulting query string sent to DB:
SELECT * FROM users WHERE id = '' OR '1'='1'

# DB parser sees:
#   WHERE clause: (id = '') OR ('1' = '1')
#   '1'='1' is always TRUE
#   → condition is TRUE for every row
#   → returns all users


# Step 3 — More dangerous: UNION-based extraction

# Attacker sends id = ' UNION SELECT username, password, null FROM users --
# Resulting query:
SELECT * FROM users WHERE id = '' UNION SELECT username, password, null FROM users --'
# → dumps the entire users table including password hashes


# Step 4 — Even more dangerous: stacked queries (database-dependent)

# Attacker sends id = '; DROP TABLE orders; --
# Resulting query on MySQL with multi-statement enabled:
SELECT * FROM users WHERE id = ''; DROP TABLE orders; --'
# → first query returns empty, second drops the table

Parameterized queries close this gap because the SQL driver sends the query template and the parameter values as separate protocol messages to the database. The database parses the SQL structure first, with the ? placeholder already understood as "a data slot, not SQL". When the value arrives, the parser has already finished — there is no grammar left to inject into.

How to debug & inspect it

Here is how to probe your own API for SQL injection and how to read the signs when something is wrong.

1. Search the codebase for string concatenation into queries: grep -rn "f\"SELECT\|+ \"SELECT\|+ 'SELECT" — any hit is a candidate vulnerability.
2. Confirm every DB call uses ? / %s / $1 placeholders, not f-strings or .format().
3. Send a single quote (') to every parameter that reaches a DB query — a 500 with a DB error means concatenation.
4. Verify the DB user has only SELECT/INSERT/UPDATE on the tables it needs — no DROP, no GRANT, no access to system tables.
5. Ensure DB error messages are caught and replaced with a generic 500 response before reaching the client.

category = request.args.get('category')
result = db.execute(f"SELECT * FROM products WHERE category='{category}'")

# Safe version — parameterized query
category = request.args.get('category')
# Allow-list: only accept known category slugs
valid_categories = {'electronics', 'clothing', 'books'}
if category not in valid_categories:
    return 400, {"error": "invalid category"}
result = db.execute(
    "SELECT * FROM products WHERE category=%s",
    (category,)   # ← tuple of values; db driver handles escaping
)

Sources & further reading

• OWASP — SQL Injection
• OWASP — Query Parameterization Cheat Sheet
• OWASP — Mass Assignment Cheat Sheet
• OWASP — Input Validation Cheat Sheet
• PortSwigger Web Security Academy — SQL injection