Web security

Review the whole application path, including server code and supporting services when they exist, regardless of stack. A clean review is bounded evidence, not a guarantee of security.

Select the work

• Development: for a feature or fix, identify the trust boundary it changes, implement the smallest sound control at the trusted decision point, and run focused checks that exercise the security property. Safe in-scope local edits and tests follow the user's implementation request.
• Review: for a question, diff, or component, inspect source and configuration without changing them; offer to save the result to the notes and save it only when the owner agrees. Research surrounding code to understand the path, but report the requested scope and any dependencies needed to establish it. Apply fixes only when requested.
• Pre-release audit: cover the deployed architecture and material entry points across the project. Give each relevant surface an evidence-backed disposition: checked, finding, hypothesis needing validation, or not covered. Ask only for missing deployment facts that could change a decision; keep reviewing independent source in the meantime.

A pre-release audit and a review start by reading the project's security notes; a pre-release audit ends by updating them, and development updates the register row of a finding it fixes, as notes describes.

Map who can act (anonymous visitor, user, tenant, administrator, service, provider), what they can affect, and where authority changes: browser to server, endpoint to worker or queue, service to data store, service to service, build to release, and application to provider. Include non-HTTP inputs such as queued jobs, scheduled tasks, files, and provider events when present. Trace the concrete path from an untrusted value or action through validation and authorization to its effect. Check the relevant lenses in trust surfaces; skip lenses without a corresponding feature or exposure. Use current framework and provider documentation when their behavior matters, rather than assuming defaults.

For routine development, stay with the changed path and its immediately affected controls. For a pre-release audit, expand to exposed routes and operations, backend jobs and integrations, identities and data stores, dependencies and build inputs, production configuration and deployment, and availability and recovery. Record what source cannot establish, such as gateway policy, hosted identity settings, secret rotation, backups, or live headers. An absent repository setting does not prove an absent deployed control.

Evidence and action boundary

Source inspection, configuration review, local diff/history review, and read-only dependency or secret scanning are source review. Keep scans local unless the user authorizes sending source or manifests to an external service. Redact credential values in outputs and reports. A scanner result or pattern match is a lead: validate the affected version, reachable path, configuration, and compensating control before calling it a vulnerability. If a scanner is unavailable, report its coverage gap and continue with review possible from source. Do not install or run untrusted dependencies merely to complete an audit.