awesome-everything RU
↑ Back to the climb

Security

Security capstone: code and config reading

Crux Read real auth/web-app snippets spanning the track — JWT validation, object-level authz, cookie/CSRF config, password storage — and pick the highest-leverage fix a security-minded senior makes first.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbit
◷ 14 min

Security bugs are read in code and config, not in slogans. Each snippet below is a small piece of a real secure-app stack. Read it, find the seam, and pick the fix a senior makes before anything else — the same loop you run in a code review or an incident.

Goal

Practise the review loop across the whole track: spot the broken token check, the missing ownership check, the cookie that reopens CSRF, and the secret that turns a config into a breach — then choose the highest-leverage fix.

Snippet 1 — verifying the token

// Express middleware guarding the API
function authenticate(req, res, next) {
  const token = req.headers.authorization?.split(" ")[1];
  const claims = jwt.decode(token);          // decode only
  if (claims?.sub) {
    req.user = claims;                        // trust the payload
    return next();
  }
  return res.status(401).end();
}
Quiz

This middleware authenticates every request. What is the critical flaw, and the fix?

Snippet 2 — the OAuth-protected endpoint

// access token already verified upstream; req.user = { sub, scope }
app.get("/accounts/:id/statements", requireScope("statements:read"),
  async (req, res) => {
    const rows = await db.query(
      "SELECT * FROM statements WHERE account_id = $1", [req.params.id]
    );
    res.json(rows);
  });
Quiz

The token is validated and the scope is enforced. A user with a valid token still reads another account's statements. Why, and what is the fix?

res.cookie("session", token, {
  httpOnly: true,
  secure: true,
  // sameSite not set
});

// elsewhere, a "convenience" route
app.get("/account/delete", deleteAccountHandler);  // state change on GET
Quiz

HttpOnly and Secure are set, so XSS can't read the cookie. What CSRF exposure remains, and how do you close it?

Snippet 4 — config and signup

// config.js (committed to the repo)
export const config = {
  dbPassword: "S3cr3t-prod-pw!",
  jwtSecret: "supersecret",
};

// signup
const hash = crypto.createHash("sha256").update(password).digest("hex");
await db.users.insert({ email, hash });
Quiz

Two track-spanning failures sit in these few lines. Name both and the fix for each.

Recap

Every snippet was a seam between two units of the track. jwt.decode authenticates nothing — verify the signature and pin the algorithm. A valid token and scope are not ownership — add an object-level owns(subject, object) check to kill IDOR. HttpOnly stops XSS theft but not CSRF — set SameSite, add a token, and keep state changes off GET. And a committed secret is already breached (rotate, don’t delete) while a fast unsalted hash hands over the password column (use Argon2id with a per-user salt). Read the code, find the seam between correct-looking layers, and fix the structural gap.

Continue the climb ↑Security capstone: threat-model and harden a web app
shortcuts expand
search
K
prev piece
k
next piece
j
cycle tier
t
this menu
?
sources3
expand
  1. 01
  2. 02
  3. 03

Trademarks belong to their respective owners. Editorial reference only.