Design REST routes, validate JSON, build Node and Express APIs on a SQL database, secure them, test them and ship them.

Back-End Web APIs

## Why it matters

HTTP is **stateless**: each request arrives on its own, with no memory of the previous one. Yet users expect to log in once and stay logged in. Every API that has accounts needs a way to attach "this is Ada" to later requests. The two main approaches, **server sessions** and **tokens**, each have trade-offs, and picking the wrong one, or storing it in the wrong place, causes real security bugs.

## Authentication and authorization

Two words that are easy to mix up:

- **Authentication** (authn): *who are you?* Proving identity with a password, a Google sign-in, a code from an authenticator app.
- **Authorization** (authz): *what may you do?* Ada can edit her own profile but not someone else's; a moderator can hide posts.

This lesson is about carrying the result of authentication across requests. Authorization checks happen on every request after that.

## Cookies

A **cookie** is a small value the server asks the browser to store and send back automatically on every request to the same site:

```http
HTTP/1.1 200 OK
Set-Cookie: sid=8f2c...; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=604800
```

From then on the browser adds `Cookie: sid=8f2c...` to each request. The attributes matter:

- `HttpOnly`: JavaScript on the page cannot read the cookie, so a cross-site scripting (XSS) bug cannot steal it.
- `Secure`: sent only over HTTPS.
- `SameSite=Lax` (or `Strict`): the browser does not send it on most cross-site requests, which blocks many cross-site request forgery (CSRF) attacks.
- `Max-Age` / `Expires`: how long it lasts. Without one, it is deleted when the browser closes.

## Approach 1: server sessions

1. The user logs in with a correct password.
2. The server creates a random, unguessable **session ID**, stores `{ sessionId -> userId, expiresAt }` in a database or cache, and sends the ID in an `HttpOnly` cookie.
3. On each request, the server looks up the ID and loads the user.
4. Logging out deletes the session row. The cookie is now worthless.

Strengths: the server can revoke any session instantly ("log out of all devices"), and the cookie holds no data at all. Cost: a lookup per request, and a shared store if you run more than one server.

## Approach 2: tokens (JWT)

A **JSON Web Token** is a string of three base64url parts: `header.payload.signature`. The payload holds **claims**:

```json
{ "sub": "user_42", "role": "student", "iat": 1792771200, "exp": 1792774800 }
```

The server signs it with a secret key. On later requests it **verifies the signature** and trusts the claims without a database lookup. Important details:

- A JWT is **signed, not encrypted**. Anyone can decode the payload. Never put secrets or personal data in it.
- Always verify the signature and the expiry with a maintained library, and fix the allowed algorithm. Never accept `alg: none`.
- A JWT is valid until it expires. Revoking one early needs extra work: short lifetimes plus refresh tokens, a deny list, or a per-user version number stored in the database and checked on each request (which brings back a lookup).

## Where the token lives

Tokens can travel in two ways:

| | `HttpOnly` cookie | `Authorization: Bearer <token>` header |
|---|---|---|
| Sent automatically | Yes, by the browser | No, your code adds it |
| Readable by page scripts | No | Yes, if stored in `localStorage` |
| Main risk | CSRF (mitigate with `SameSite`, CSRF tokens) | XSS can steal it |
| Good fit | Browser apps on your own domain | Mobile apps, CLIs, server-to-server |

For browser apps, a session ID or token in an `HttpOnly`, `Secure`, `SameSite` cookie is the safer default. Mobile apps have no cookie jar by default, so they usually send a bearer token and keep it in the platform's secure storage (Keychain on iOS, Keystore on Android). API keys for server-to-server calls are another kind of bearer token.

## Worked example: the request flow

```text
POST /login {email, password}
  -> check password
  -> create session (or sign token)
  -> 200 + Set-Cookie: sid=...; HttpOnly; Secure; SameSite=Lax

GET /me   (browser sends Cookie: sid=...)
  -> middleware loads the session -> req.user = { id: 42 }
  -> 200 { "id": 42, "name": "Ada" }

GET /me   (no cookie, or expired)
  -> 401
```

## Common mistakes

- **Storing tokens in `localStorage`** in a browser app, where any injected script can read them.
- **Cookies without `HttpOnly`, `Secure` and `SameSite`.**
- **Long-lived JWTs with no way to revoke them** after a password change or account compromise.
- **Personal data or secrets in a JWT payload.**
- **Checking authentication but not authorization**: a logged-in user can still try to read someone else's data.
- **Predictable session IDs.** Use a cryptographically secure random generator, such as `crypto.randomBytes(32)`.

## Quick recap

- Authentication proves who someone is; authorization decides what they may do.
- Sessions keep state on the server and are easy to revoke; JWTs carry signed claims and are hard to revoke early.
- Browser apps: prefer `HttpOnly`, `Secure`, `SameSite` cookies. Mobile and server clients: bearer tokens in secure storage.
- Whatever you choose, check authorization on every request.

The **Do** tab quiz asks you to choose the right approach for a few real situations.


Compare server sessions and tokens, and store them safely in cookies or secure storage.

Sessions, cookies, and tokens

Session vs Token Authentication in 100 Seconds

Session Vs JWT: The Differences You May Not Know!

## Why it matters

Databases get leaked: through a SQL injection bug, a misconfigured backup, a stolen laptop or an insider. When that happens, the question is whether the attacker also gets every user's password. People reuse passwords, so a leaked password from your site can unlock their email or bank. Storing passwords correctly means that even with a full copy of your database, an attacker has to do enormous work to recover them. It is a small amount of code with a very large effect.

## Encryption is the wrong tool

**Encryption** is reversible: anyone with the key gets the original back. If the key sits on the same server as the database (it usually does), a leak of one is likely a leak of both. You never need to read a user's password back, only to check that a login attempt matches. That is a job for a **hash**.

## Hashing

A **cryptographic hash function** turns any input into a fixed-size output (a digest). It is one-way (you cannot compute the input from the digest) and the same input always gives the same digest:

```text
sha256("hunter2") -> f52fbd32b2b3b86ff88ef6c490628285f482af15ddcb29541f94bcf526a3f6c7
```

At login, you hash the attempt and compare digests. So far so good, but plain fast hashes such as MD5 or SHA-256 are **not enough** for passwords, for two reasons.

**1. Same password, same hash.** If a thousand users chose `password123`, they all have the same digest. An attacker cracks one and gets a thousand accounts. Worse, attackers keep huge precomputed tables of digests for common passwords (rainbow tables), so a plain SHA-256 of a common password can be looked up instantly.

**2. Fast is bad here.** SHA-256 is designed to be fast. A single modern graphics card can compute billions of SHA-256 hashes per second, so guessing every likely password takes very little time.

## Salt: make every hash unique

A **salt** is a random value, generated fresh for each user, that is combined with the password before hashing:

```text
user  salt              stored hash
ada   9f1c...e2 (random) hash("9f1c...e2" + "password123") -> 4b7a...
bob   03aa...71 (random) hash("03aa...71" + "password123") -> d91e...
```

Now two users with the same password have different hashes, and precomputed tables are useless because the attacker would need a table per salt. The salt is **not secret**; it is stored next to the hash. Its job is uniqueness, not secrecy.

## Slow, adaptive hashing

The second fix is to use a hash designed to be **deliberately slow and tunable**, so that one check takes tens to hundreds of milliseconds. A user logging in does not notice; an attacker trying billions of guesses does. These are called password hashing functions or key derivation functions:

| Algorithm | Notes |
|---|---|
| **Argon2id** | Current first choice in the OWASP Password Storage Cheat Sheet; memory-hard, which makes GPU attacks costly |
| **scrypt** | Memory-hard; built into Node as `crypto.scrypt` |
| **bcrypt** | Older, still widely used and acceptable; has a work factor ("cost") and a 72-byte input limit |
| **PBKDF2** | Acceptable with a high iteration count; required by some compliance rules |

Each has a **cost parameter**. Raise it over the years as hardware gets faster. Good libraries generate the salt for you and store the algorithm, cost and salt inside the output string, for example `$2b$12$...` for bcrypt, so you can upgrade later.

## Worked example in Node

With the `bcrypt` package (or `bcryptjs`, a pure JavaScript version):

```javascript
import bcrypt from "bcrypt";

// Signup: hash once, store only the hash.
const passwordHash = await bcrypt.hash(password, 12); // 12 = cost factor
await db.users.insert({ email, passwordHash });

// Login: compare the attempt with the stored hash.
const user = await db.users.findByEmail(email);
const ok = user ? await bcrypt.compare(attempt, user.passwordHash) : false;
if (!ok) return res.status(401).json({ error: "Invalid email or password." });
```

Notice that `compare` reads the salt and cost from the stored string, so you never handle the salt yourself. Notice also the single error message: the response does not say whether the email exists. Careful implementations even run a dummy compare when the email is unknown, so the response time does not give it away either.

## Around the hash

Hashing is one layer. The rest of a sound password system:

- **Rate-limit and lock out** repeated failed logins, so online guessing is slow.
- **Set a sensible minimum length** (NIST guidance suggests at least 8, preferably more) and allow long passphrases. Check new passwords against lists of known-breached passwords instead of forcing odd character rules.
- **Offer two-factor authentication**, so a stolen password alone is not enough.
- **Never log passwords**, including in request-body logs and error reports.
- **A pepper** (an extra secret key kept outside the database, for example in an environment variable) adds protection if only the database leaks. It is optional and must be managed like any other secret.

## Common mistakes

- Storing passwords in plain text or with reversible encryption.
- Using a fast hash (MD5, SHA-1, SHA-256) without a password hashing function.
- One salt for every user, or a salt derived from the username.
- Writing your own scheme instead of using a maintained library.
- Different error messages for "unknown email" and "wrong password".

## Quick recap

- Never store passwords or encrypt them; store a salted, slow hash.
- A salt is random per user and makes identical passwords hash differently. It is stored, not secret.
- Use Argon2id, scrypt or bcrypt with a cost you raise over time.
- Combine hashing with rate limits, breached-password checks, 2FA and clean logs.

The **Do** tab quiz checks that you can explain each piece in your own words.


Explain why passwords are stored as salted, slow hashes and how to do it with a maintained library.

Password hashing

How NOT to Store Passwords! - Computerphile

System Design: How to store passwords in the database?

## Why it matters

An API is a public front door to your data. Unlike a web page, it has no buttons that hide what a user "should not" click: anyone can send any request with any ID. The **OWASP API Security Top 10** (from the Open Worldwide Application Security Project) lists the most common ways APIs get broken. The two at the top of most real-world incident reports are simple: **broken access control** and **injection**. Both are bugs in ordinary route code, and both are easy to prevent once you know the pattern.

## Broken object level authorization (BOLA)

The first entry in the OWASP API Top 10 is **Broken Object Level Authorization**. It looks like this:

```javascript
// BUG: any logged-in user can read any order
app.get("/orders/:id", requireLogin, async (req, res) => {
  const order = await db.orders.findById(req.params.id);
  if (!order) return res.status(404).json({ error: "Not found." });
  res.json(order);
});
```

`requireLogin` proves *who* the caller is. Nothing checks that the order **belongs** to them. An attacker logs in with their own account and changes `/orders/1001` to `/orders/1000`, `/orders/999`, and so on. Sequential IDs make it trivial, but random IDs are not a fix on their own; IDs leak through URLs, logs and shared links.

The fix is to check ownership on **every** request that names an object:

```javascript
app.get("/orders/:id", requireLogin, async (req, res) => {
  const order = await db.orders.findById(req.params.id);
  const allowed = order && (order.userId === req.user.id || req.user.role === "admin");
  if (!allowed) return res.status(404).json({ error: "Not found." });
  res.json(order);
});
```

Even better, put the owner in the query itself so the database cannot return someone else's row: `WHERE id = ? AND user_id = ?`. Returning `404` (not `403`) for other people's objects avoids confirming that the ID exists.

Related entries in the list:

- **Broken function level authorization**: a student can call `DELETE /admin/users/7` because only the admin *page* was hidden, not the route.
- **Broken object property level authorization**: a user can update `role` or `isVerified` through `PATCH /me` (mass assignment), or a response includes fields such as `passwordHash` that the caller should never see. Allow-list the fields you accept and the fields you return.

## Injection

**Injection** happens when untrusted input is mixed into code or a query that another system then runs. SQL injection is the classic example:

```javascript
// BUG: input becomes part of the SQL text
const sql = `SELECT id, title FROM posts WHERE author = '${req.query.author}'`;
```

The fix is a **parameterised query**: keep the SQL text fixed and pass the value separately.

```javascript
const sql = "SELECT id, title FROM posts WHERE author = ?";
const rows = db.prepare(sql).all(req.query.author);
```

The same pattern applies elsewhere:

- **NoSQL injection**: in MongoDB, a body of `{ "email": { "$ne": null } }` turns an equality check into "any email". Validate that fields are plain strings before querying.
- **Command injection**: never build shell commands from input (`exec("convert " + filename)`). Use APIs that take an argument array, or avoid the shell entirely.
- **Cross-site scripting (XSS)**: user text rendered into HTML without escaping. APIs should return data as JSON and let the front end render it safely.

## Other entries worth knowing

- **Broken authentication**: weak login flows, no rate limit on password or code guessing, tokens that never expire.
- **Unrestricted resource consumption**: no limits on page size, upload size or request rate, so one caller can exhaust your server or your bill. Cap `?limit=`, body size and requests per minute.
- **Security misconfiguration**: verbose error pages with stack traces, permissive CORS (`Access-Control-Allow-Origin: *` with credentials), default credentials, debug endpoints left on.
- **Server-side request forgery (SSRF)**: an endpoint that fetches a URL the caller supplies can be pointed at internal addresses. Allow-list destinations.
- **Improper inventory management**: forgotten old versions (`/v1/`) and test endpoints still running without the newer fixes.

The full list, with examples, is on the [OWASP API Security Project](https://owasp.org/www-project-api-security/) site (checked on 2026-10-23). The list is revised every few years, so read the current edition.

## A habit, not a checklist

Most of these bugs come from asking the wrong question. For every route, ask:

1. **Who** is calling? (authentication)
2. **May they do this action?** (function-level authorization)
3. **May they touch this specific object and these fields?** (object and property authorization)
4. **Is every input validated and passed to other systems as data, not code?** (validation and injection)
5. **What stops someone from doing this a million times?** (limits)

Write a test for each answer, especially the "other user's ID" case.

## Common mistakes

- Hiding a button in the UI and assuming the route is protected.
- Checking login but not ownership.
- Building SQL, shell commands or Mongo filters from raw input.
- Returning whole database rows instead of an allow-listed set of fields.
- No limits on list sizes, uploads or request rates.

## Quick recap

- Broken access control is the most common API flaw: check ownership and role on every object, ideally in the query.
- Injection is prevented by keeping code and data separate: parameterised queries, validated types, no shell strings.
- Allow-list input fields and output fields; cap sizes and rates.
- Read the current OWASP API Security Top 10 and test the "someone else's ID" case for every route.

**Try it:** the **Do** tab gives you two vulnerable functions. Fix the injection and the access-control bug so the checks pass.


Recognise the most common API flaws from the OWASP API Security Top 10 and fix broken access control and injection.

API security basics

Broken Object Level Authorization - 2023 OWASP Top 10 API Security Risks

Broken Access Control Explained: OWASP Top 10 A01 Explained with Examples

Keep users logged in with cookie sessions or tokens, store passwords as salted slow hashes, and fix the most common API security flaws.