Security review of a change

---name: security-reviewdescription: "Review a change or repository for security holes (leaked secrets, injection, missing permission checks, unsafe input handling) with a real attack for each finding."metadata:  title: "Security review of a change"  category: engineering  tags: [security, review]--- ## When to use this A change touches sign-in, permissions, payments, file handling, user input orsecrets, or a repository is about to be made public. ## How 1. Map where untrusted input comes in: request bodies, query strings, headers,   uploaded files, webhooks, anything read from another service.2. Follow each input to where it is used. Look for it reaching a database query,   a shell command, a file path, HTML or a template without being checked or   escaped.3. For every action that reads or changes data, check that the code confirms who   is asking and that they are allowed -- not only that they are signed in.4. Search code, config, tests and git history for keys, tokens and passwords.   Name the file and line of each one; never paste the value.5. Run the project's own dependency audit, and note anything known to be   vulnerable that the change relies on.6. Write each finding as: what is wrong, the exact input an attacker would send,   what they would get, and the fix. Rank by how easy and how bad.7. Post a document. Never open a public issue for a finding -- that publishes it.   Ask how it should be reported. A worry with no attack is not a finding. Say plainly when a change looks safe.