.agents/skills/security-review/references/checklist.md
Run this list mentally on every relevant change. For each bullet, either find that it does not apply, or confirm the listed mitigation is present in the diff. Each bullet links to the topic reference that owns the detail.
Does the change accept a URL, host, endpoint, baseURL, webhook target,
or any field that becomes the destination of an outbound HTTP request?
fetch(userUrl) or SDK init with endpoint: userUrl
without that wiring is a finding.Does the change add a new "integration" (Settings -> Integrations, new webhook destination, new storage backend, new LLM provider, new image proxy) that lets an admin configure a host?
Does the change follow redirects on a user-controlled URL with plain
fetch()?
fetchWithSecureRedirects with the
matching validator.projectId
in the where clause?project_id = {projectId: String}?protectedProjectProcedure (or
equivalent) and call throwIfNoProjectAccess with the right scope?withMiddlewares +
createAuthedProjectAPIRoute (or the equivalent organization variant) with
the right scope?These are enforced today by the repo-wide review checklist in ../../code-review/references/review-checklist.md; restate them here so the security sweep stays self-contained.
encrypt / decrypt
from @langfuse/shared/encryption) and never returned through get/list
endpoints?select / omit in Prisma) and
from logs?.env*.example files and validated via the
package env.mjs/ts, not read from process.env directly?auditLog with the right action and
resourceType? Match existing wiring in
web/src/features/blobstorage-integration/blobstorage-integration-router.ts
and similar routers.When a new finding class starts to recur in PR reviews or security reports,
add a one-line bullet here pointing at a new references/<topic>.md. Do not
restate the detail in this checklist; keep it as the trigger surface.