security-architecture-review

Security architecture review

Review in this order

Attention spent in this order finds the most consequential problems first.

1. Authentication. How identity is established, how sessions are represented, how they expire,

what happens on password reset and account recovery. Recovery flows are the most commonly weakest

path into an account and the least reviewed.

2. Authorization. The one that matters most and gets least attention. For every endpoint and

every object: who is allowed, and where is that checked? The characteristic failure is checking on

the way in but not on the object itself, so any authenticated user can reach any record by changing

an identifier.

Check multi-tenant isolation explicitly and by test, not by reading. Assume every identifier in a

request is attacker-controlled, because it is.

3. Data. What is collected, where it goes, where it rests, and who can read it. Sensitive data

in logs, in error responses, in analytics payloads, and in client bundles — all four are routine

findings.

4. Input and output. Untrusted input reaching a query, a template, a command, a deserializer, or

a URL the server fetches. Parameterize rather than escape. Validate against an allowlist rather than

a denylist.

5. Secrets. Never in source, never in client bundles, never in build logs. Rotatable, scoped to

what needs them, and with a documented rotation path that someone has actually walked.

6. Dependencies and supply chain. What is pulled in, how it is pinned, how updates are reviewed,

and what would happen if a maintainer account were compromised. Lockfiles committed, builds

reproducible.

Reviewing a change rather than a design

Look for: new endpoints without an authorization check, new external input, changed authentication

or session logic, new dependencies, anything touching cryptography, and anything that widens what a

role can do. Everything else is usually lower yield.

Never write your own cryptography. Use the vetted primitives, and be suspicious of any diff that

implements a comparison, a token, or a signature by hand.

Sources

references/sources.md in this skill lists the outside authorities that settle the questions

here — what each one is authoritative for, and what you may do with it. Check them before

answering on anything they cover, and cite what you used. Most are free to read and not free

to reproduce; the use note on each is binding.

Tooling

• SAST catches classes of bug cheaply and produces false positives at volume. Tune it or the

team will learn to ignore it, which is worse than not running it.

• DAST and dependency scanning find different things; neither replaces review.
• Secret scanning in CI and pre-commit is the highest-value automation per unit of effort.

By name today: Semgrep, CodeQL, or SonarQube for SAST; Snyk, Dependabot, or Trivy for

dependencies; Burp Suite or OWASP ZAP for DAST; gitleaks, TruffleHog, or GitHub secret

scanning for secrets — and similar in each category.

Automation is a floor, not a review. It finds known patterns, not design flaws — and design flaws

are what actually cause the expensive incidents.

Third-party integrations

What data leaves, under what agreement, with what access, and what happens if they are breached.

Scope credentials to the minimum, prefer short-lived tokens, and know how to revoke without an

outage.

Never

• Approve a design on the promise of a control with no named owner and no date.
• Accept "it is internal" as an authorization boundary.
• Review the diagram instead of the change. Read what is actually being built.
• Sign off on a third-party integration without knowing what data leaves and under what terms.

Return contract

Findings by severity, each with: the concrete attack, what the attacker gains, whether it blocks

release, and the specific fix. A finding with no attack path stated is a preference.