Building a Secure Coding Checklist
A secure coding checklist turns scattered security knowledge (OWASP Top 10 awareness, past incident lessons, framework-specific gotchas) into a repeatable gate that every pull request passes through before it reaches production. Instead of relying on one senior engineer to remember every pitfall, the checklist encodes those checks into something a reviewer or a CI pipeline can enforce consistently, catching issues like unvalidated input, hardcoded secrets, and missing authorization checks before they ship.
Cricket analogy: Just as a fielding side runs through a pre-match checklist covering pitch report, weather, and the opposition's known strengths against spin, a coding checklist forces the team to confirm the same critical risks every single release instead of trusting memory.
Input Validation and Output Encoding
Every checklist should require that all untrusted input — query parameters, form fields, HTTP headers, file uploads, JSON bodies — be validated against an explicit allow-list (type, length, format, range) rather than a deny-list of known-bad patterns, because deny-lists are trivially bypassed with encoding tricks. Equally important is context-aware output encoding: data rendered into HTML needs HTML-entity encoding, data placed into a SQL query needs parameterization (not encoding), and data placed into a URL needs percent-encoding, because using the wrong encoding for the context is a common source of stored and reflected XSS.
Cricket analogy: A bowler validating length and line before every delivery — checking the crease, the field placement, the batter's stance — rather than reacting only after a boundary is hit is like allow-list validation catching bad input before it does damage rather than reacting to an exploit after the fact.
Authentication, Session, and Access Control Checks
The checklist must verify that authentication endpoints rate-limit and lock out brute-force attempts, that session tokens are regenerated after login to prevent session fixation, and — critically — that every data-access code path performs an object-level authorization check confirming the logged-in user actually owns or is permitted to access the requested resource, not just that they are logged in at all. This last check, often called Broken Object Level Authorization (BOLA), is one of the most commonly missed items because functional tests rarely try accessing another user's resource ID.
Cricket analogy: A stadium checking that a ticket holder's seat number matches the section they're entering, not just that they hold any valid ticket, is exactly the object-level check missing when an app verifies login but not ownership of the specific record requested.
Dependency, Secrets, and Configuration Hygiene
A thorough checklist mandates automated dependency scanning (tools like npm audit, pip-audit, or Dependabot) against known CVE databases before merge, forbids committing secrets by requiring pre-commit secret scanning (gitleaks, truffleHog), and confirms that production configuration disables debug modes, verbose stack traces, and directory listing. Security misconfiguration consistently ranks in the OWASP Top 10 precisely because these are cheap to fix but easy to forget under deadline pressure.
Cricket analogy: A team manager checking every player's fitness clearance before selection, rather than assuming last season's medical report still applies, mirrors how dependency scanning re-checks every library version rather than trusting it was safe when first added.
# .github/workflows/secure-coding-gate.yml
name: secure-coding-checklist
on: [pull_request]
jobs:
checklist:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Secret scanning
uses: gitleaks/gitleaks-action@v2
- name: Dependency vulnerability scan
run: |
npm audit --audit-level=high
pip-audit -r requirements.txt
- name: Static analysis (SAST)
run: semgrep --config=p/owasp-top-ten --error
- name: Enforce parameterized queries
run: |
# fail the build if raw string concatenation is used to build SQL
! grep -R "f\"SELECT" --include=*.py . || (echo "Raw SQL string formatting detected" && exit 1)
- name: Config hygiene check
run: |
! grep -R "DEBUG = True" --include=*.py . || (echo "Debug mode left enabled" && exit 1)
Treat the checklist as a living document: every post-incident retrospective should ask 'would a checklist item have caught this?' and, if not, add one. A checklist that never grows after an incident isn't doing its job.
Code Review and CI Gate Enforcement
A checklist only works if it is enforced, not just documented — the most effective teams encode the highest-severity items (SQL injection patterns, hardcoded secrets, disabled TLS verification) as automated CI gates that block merge, while lower-severity, context-dependent items (proper error messaging, rate-limit tuning) remain as human code-review prompts. Splitting the checklist this way keeps automation fast and objective while preserving human judgment for nuanced cases.
Cricket analogy: The third umpire automatically overturns a clear no-ball on a front-foot line check (objective, automatable) while a marginal caught-behind decision still relies on the on-field umpire's judgment, mirroring which checklist items get automated versus left to human review.
Do not let an automated checklist create false confidence — a green CI pipeline only proves the specific checks you wrote for pass; it says nothing about logic flaws, business-rule bypasses, or novel vulnerability classes the checklist doesn't yet cover. Pair automated gates with periodic manual security review and penetration testing.
- A secure coding checklist converts ad hoc security knowledge into a repeatable, enforceable gate applied to every pull request.
- Input validation should use allow-lists, not deny-lists, and output encoding must match the destination context (HTML, SQL, URL).
- Authentication checks (rate-limiting, session regeneration) are necessary but insufficient — authorization must verify per-resource ownership (avoiding BOLA), not just that a user is logged in.
- Dependency scanning, secret scanning, and configuration hygiene checks catch cheap-to-fix, easy-to-forget issues that dominate real-world breach root causes.
- High-severity, objective checks (hardcoded secrets, raw SQL concatenation) should be automated CI gates; nuanced items remain human code-review prompts.
- A checklist must evolve — every post-incident retrospective should ask whether a new checklist item would have caught the issue.
- Automated checklist passes are necessary but not sufficient; they must be paired with manual review and periodic penetration testing.
Practice what you learned
1. Why is allow-list input validation generally preferred over deny-list validation?
2. What does Broken Object Level Authorization (BOLA) specifically fail to check?
3. Which checklist items are best suited to automated CI enforcement rather than human review?
4. Why must output encoding be context-aware?
5. What is the main risk of relying solely on a green CI security pipeline?
Was this page helpful?
You May Also Like
Common Web Security Tools
An overview of the core tool categories used in web security work — intercepting proxies, static and dynamic scanners, and reconnaissance tools — and when to use each.
Penetration Testing Basics
The fundamentals of penetration testing — how it differs from scanning, the standard engagement phases, and the black-box/gray-box/white-box testing spectrum.
Web Security Quick Reference
A fast-lookup cheat sheet of the OWASP Top 10, core HTTP security headers, and vulnerability-to-fix mappings for use during code review or interview prep.