To spot a removed security check, read the deleted lines on purpose. Look for dropped authorization calls, validation, escaping, rate limits, logging and tests, and ask where the same job is done now. If nobody can say, the pull request has introduced a regression, even if every added line is clean.
Why deletions get missed
Review tools highlight what is new. Reviewers naturally read the green lines and ask whether they are correct. A deleted guard clause produces no green line to question. The remaining code often still compiles, passes tests and looks tidy, which makes a refactor that quietly drops a check hard to see.
The OWASP Secure Code Review Cheat Sheet lists a specific step for diff-based review: ensure no security regression. It also lists assessing the impact on existing security controls. Both are about what the change takes away as much as what it adds.
Where removed checks hide
Refactors. A function is split or inlined, and a validation call that lived in the old version does not move with the logic.
Cleanups. Unused-looking code is deleted. A line that seemed to do nothing was setting a header, checking a flag or logging an event.
Middleware and decorators. A decorator is removed from a route during a rewrite. The route works as before for normal users.
Test deletions. A failing test is removed rather than fixed. This often hides the check it was guarding.
Configuration. A setting is dropped and the default is less strict.
A reviewing routine
- Filter the diff to deletions. Most tools let you collapse added lines or scroll the red side alone.
- For each deleted block, name its job. Authorization, validation, encoding, limiting, logging, cleanup.
- Find the replacement. Search the new code for where that job is done now. If the check moved, good. If it was dropped, ask why.
- Check tests. Were any removed or weakened? A deleted assertion is a deleted control in test form.
- Check the description. The author should have said they removed something. OWASP says to understand the purpose of the change. If the description says "tidy up" and the diff removes an access check, that mismatch is the finding.
Questions to put in the comment
This removes the ownership check from export_report (old line 61).
Where is that enforced now? If it moved, link it. If it is intentionally
gone, please say why in the description.
Phrase it as a question about where the job went, not as an accusation. Most removed checks are accidents.
Patterns to search for in deleted code
| Deleted text | Possible loss |
|---|---|
| authorize, permission, owner, role | Access control |
| validate, schema, sanitize, escape | Input handling |
| limit, throttle, quota | Abuse control |
| log, audit | Detection and evidence |
| csrf, origin, cors | Browser protections |
| try, catch, finally | Cleanup and failure handling |
A search of the diff for those words takes seconds. It will produce false positives, and each one is a chance to confirm the logic moved.
Make it hard to remove by accident
- Keep a test for each important control, so deleting the check fails a test.
- Mark security critical files in code owners, so a deletion notifies the right reviewer.
- Centralise checks in one helper, so a route cannot drop its own copy without visibly removing the helper call.
Try it yourself
Open the demo to see how a pull request gate reports what a change did to your controls. Notice how a removed or weakened check would show up as a result, not as a green line.
Click through it at your own pace, or open it full screen.
Quick check
Should reviewers read every deleted line?
On security sensitive files, yes. Elsewhere, scan deletions for the pattern words above and read the ones that match.
Is deleting a test always suspicious?
No, tests become obsolete. Ask what the test protected and whether anything protects it now.
Sources
Last reviewed: 19 October 2026.
