Developer explains why deleting flawed security rules matters more than writing them

A developer maintaining a custom security ruleset documented two instructive cases where written rules were ultimately cut or corrected. The first rule targeted SQL order-by injection via user-supplied column names but produced false positives on safe, allowlist-validated code because taint analysis could not model control-flow decisions. The second rule, which shipped, incorrectly flagged Laravel's mimetypes: validation as unsafe, claiming it trusted the client-sent Content-Type header — a claim that source code inspection proved false, since both mimes: and mimetypes: inspect the actual file. The author warns that a noisy rule wastes developer attention, but a factually wrong rule is more dangerous because it can push developers away from secure practices toward weaker alternatives. The key lesson drawn is that reading original source code directly is more reliable than depending on secondhand summaries or assumptions.