Week 8 secured API review

Why this matters

Six days ago you had an API that worked. Today you have one that knows who is calling, refuses what they may not do, records what happened without leaking secrets, and proves all of it with a test command. Today you close the week the way real teams close a security milestone: an adversarial review of your own work, negative tests for the things that must fail, a diagram someone else can read, and an honest list of what is still broken.

The last item is the one that separates engineering from theatre. A milestone with documented known limitations is trustworthy. One that claims to be secure is not.

Threat-driven review

A review that walks the code file by file finds typos. A threat-driven review starts from what an attacker wants and works backwards to the code that stands in the way. Same hour, far better questions.

Take your Day 53 threat model and run each attacker against each asset:

Attacker	Wants	Ask of your code
Anonymous stranger with curl	Any data, any write	Does every protected route sit behind requireAuth?
Logged-in technician	Admin actions	Is requireRole on every admin-only route?
Logged-in technician	Another user's records	Is ownership checked after loading the row?
Malicious website the user visits	A state change using their cookie	What does sameSite do about a cross-site POST?
Someone holding a copy of the database	Passwords	Is every stored value a salted bcrypt hash?
Someone reading log files	Credentials	Do the logs contain a password, cookie, or session ID?

Each row is a question you answer by running something, not by remembering. That is the whole method: attacker, asset, path, evidence.

Deny by default, one more time

The rule that has run under the whole week: when permission is unclear, the answer is no.

Unclear means any of these: a route you have not classified, a role you have not seen before, a session that failed to load, a resource whose owner you could not determine. Every one of them must end in a refusal, not a shrug.

// wrong — an unrecognised role falls through and is allowed
if (actor.role === 'technician' && !isAdminOnly(path)) return next();
if (actor.role === 'admin') return next();
next();                                        // ← anything unmatched gets through

// right — the default is refusal
if (!isAllowed(actor, action)) {
  return res.status(403).json({ error: 'insufficient permissions' });
}
next();

The difference is not style. The first shape breaks silently the day someone adds a role; the second breaks loudly, in a way you find immediately. Choose the failure you will notice.

Negative tests

A negative test asserts that something is refused. Yesterday's suite already has a few; today you make them systematic, because they are the only tests that can prove a security control exists.

Positive tests confirm the feature. Negative tests confirm the boundary:

• Anonymous request to every protected route → 401
• Technician on every admin-only route → 403
• Technician editing another technician's record → 403
• Expired session cookie → 401
• A session ID that was logged out → 401
• Duplicate serial number → 409
• Missing required field → 400

Test that a control fails correctly and you have tested the control. Test only the success path and you have tested nothing about it — a function returning true unconditionally passes every positive test you can write.

The architecture diagram

One page, drawn so a new developer can find things. Boxes for your layers, arrows for dependency direction, and a mark at each trust boundary. Text is fine — it survives in Git and it diffs.

                 ┌───────────────────────────────┐
  browser ──────▶│  routes/  (HTTP only)         │
   cookie: sid   │  requestLogger → requireAuth   │
                 │  → requireRole → handler       │
                 └───────────────┬───────────────┘
   ── trust boundary ────────────│──── user controls everything above
                                 ▼
                 ┌───────────────────────────────┐
                 │  services/  (rules, ownership) │
                 │  throws AppError(code)         │
                 └───────────────┬───────────────┘
                                 ▼
                 ┌───────────────────────────────┐
                 │  repositories/  (SQL, $1 args) │
                 └───────────────┬───────────────┘
                                 ▼
                          PostgreSQL
                   users · sessions · equipment
                       maintenance_records

Two things the diagram must show, because they are the two things people get wrong: which direction dependencies point (down only, never back up) and where the trust boundary sits (everything above it is under the user's control, as Day 1 established).

Dependency and secret checks

Two commands, both fast, both worth running before any milestone.

Dependencies. Your code is a minority of what ships; the rest is packages.

npm audit

# npm audit report

found 0 vulnerabilities

If it reports findings, read them before acting. npm audit fix applies compatible updates; npm audit fix --force may install breaking major versions, so run your tests immediately after. Not every advisory is exploitable in your usage — a vulnerability in a dev-only tool is different from one in your request path. Note the reasoning; do not silence the tool.

Secrets. The rule is that credentials come from the environment and never from a file in Git.

git ls-files | grep -i "env"     # .env must NOT be listed; .env.example may be
git grep -n -i -E "password *= *['\"]|secret *= *['\"]|api[_-]?key"
git log -p -S "password" -- src/ | head -40

The last command searches the whole history, not just the current files.

Walkthrough: the review pass

Work through this in order, writing results as you go. Each step produces evidence, not an opinion.

# 1. Everything still works
DATABASE_URL=postgres://localhost/maintenance_test npm test

 Test Files  3 passed (3)
      Tests  14 passed (14)

# 2. Anonymous access to a protected route
curl -s -o /dev/null -w '%{http_code}\n' -X DELETE http://localhost:3000/equipment/1

401

# 3. Wrong role
curl -c tech.txt -s -X POST http://localhost:3000/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"email":"[email protected]","password":"correct horse battery staple"}' > /dev/null
curl -s -o /dev/null -w '%{http_code}\n' -b tech.txt -X DELETE http://localhost:3000/equipment/1

403

# 4. Logout really revokes
curl -s -b tech.txt -X POST http://localhost:3000/auth/logout > /dev/null
curl -s -o /dev/null -w '%{http_code}\n' -b tech.txt http://localhost:3000/equipment

401

# 5. Nothing sensitive stored or leaked
psql maintenance -c "SELECT email, left(password_hash, 7) FROM users;"

      email       |  left
------------------+---------
 [email protected]  | $2b$12$

Then the two checks above — npm audit and the secret grep — and finally re-read one log excerpt looking specifically for a password, a cookie, or a session ID.

Your turn

Produce the milestone: a secured API with documented known limitations.

1. Run the full test suite. Everything green before you review anything.
2. Add negative tests for every row of the list above that you do not already cover. Include the logged-out-session case, which is the one people forget.
3. Do the threat-driven pass: for each attacker row in the table, run the command and record the status code you actually got beside the one you expected.
4. Fix every disagreement. If you cannot fix one today, it becomes a known limitation with a sentence explaining the risk.
5. Draw the architecture diagram in docs/architecture.md with dependency arrows and the trust boundary marked.
6. Run npm audit and the three secret commands. Record the output verbatim, including "found 0 vulnerabilities" if that is what you got.
7. Update docs/threat-model.md: move anything now mitigated into the mitigations list with the file that implements it, and leave the rest under known limitations with an honest one-line risk statement each.
8. Commit with a message naming what is secured and what is not.

Common pitfalls

• Reviewing by reading. Reading finds what you expect. Running finds what is true.
• An empty known-limitations list. You are missing rate limiting on login, at minimum. Say so.
• Fixing findings without a test. A bug fixed with no negative test comes back next month.
• Treating npm audit as a pass/fail gate. Read the advisory, decide whether it reaches your code, write down the reasoning either way.
• Assuming the removed secret is gone. History keeps it. Rotate it.

Verify it yourself

Open today's reference, the OWASP Top 10, and read the category list end to end — not one entry, the whole list.

1. Pick the category your API is most exposed to right now and justify the choice in one paragraph in docs/threat-model.md.
2. Find one category this week never addressed at all. Add it to known limitations with a note on what addressing it would involve. Week 11's security review will pick it up.

Naming your weakest point in writing, before anyone asks, is the professional habit this week was really teaching.