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.

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.