A useful application security best practices checklist is organized by layer — design, code, dependencies, secrets, pipeline, runtime, response — and enforced by automation, because a checklist nobody's CI checks is a wish list. This is the 2026 revision of ours. Two things changed since the last edition: the OWASP Top 10 2025 elevated software supply chain failures into a first-class category and moved security misconfiguration to number two, and attackers spent another year proving that stolen credentials and vulnerable dependencies beat clever exploits. The checklist reflects both.
Work through it honestly and mark each item: enforced automatically, done manually, or not done. The middle column is where most breaches come from — manual controls decay.
Design and access control
Broken access control has now held the number one OWASP spot across both the 2021 and 2025 editions, so this section stays first.
- Every endpoint declares its authorization rule explicitly; deny is the default for undeclared routes.
- Object-level checks on every lookup by ID (the IDOR test: change the ID in the request; you should get 403/404, never someone else's record).
- Server-side enforcement only — client-side hiding of buttons is UX, not security.
- Multi-tenancy isolation tested per release: one automated test suite that logs in as tenant A and attempts tenant B's resources.
- Threat model written for each new externally-facing feature; one page is enough, absence is the failure.
Code-level controls
- Parameterized queries everywhere; string-built SQL fails review, no exceptions.
- Output encoding by default via your template engine; every use of raw/unescaped output (
dangerouslySetInnerHTML,| safe,html_safe) carries a reviewed justification. - Input validation at trust boundaries with allowlists (see our note on getting even URL validation right — it is harder than it looks).
- File uploads: extension and content-type allowlist, size caps, stored outside the webroot, never executed.
- Error handling returns generic messages to clients and rich detail to logs — and, per the new OWASP category on mishandled exceptional conditions, fails closed: an exception in an auth check must deny, not skip.
Dependencies and supply chain
The OWASP Top 10 2025 expanded "vulnerable and outdated components" into software supply chain failures, which matches what incident data has said for years.
- Lockfiles committed and enforced (
npm ci, hash-pinned pip installs). - SCA scanning on every pull request that touches a manifest, plus continuous monitoring of deployed versions against new advisories — a software composition analysis gate catches the vulnerable version before merge instead of in an audit.
- Install scripts disabled by default in package managers; allowlist the handful that need them.
- Automated updates with a cooling-off period (about seven days) so you don't ingest a hijacked release published hours ago.
- SBOM generated per build and retained, so "did we ever ship that version" is a query, not a project.
- CI actions and base images pinned by digest, not mutable tags.
Secrets and configuration
Security misconfiguration climbed to number two in the 2025 Top 10; it is also the cheapest category to automate away.
- No secrets in source, ever; pre-commit and CI secret scanning both on (they catch different moments).
- Secrets injected at runtime from a manager, scoped per service, rotated on a schedule and on any suspicion.
- Short-lived credentials over static keys: OIDC from CI to cloud, workload identity in-cluster.
- Security headers set and verified: HSTS, a real Content-Security-Policy,
X-Content-Type-Options, frame protections, cookie flags (Secure,HttpOnly,SameSite). - Debug endpoints, default credentials, and directory listings verified absent — by a scanner, per release, not by assumption.
Pipeline: test what you ship
- SAST tuned to your codebase (an untuned SAST stage becomes wallpaper within a sprint).
- DAST against staging on a schedule and against every release candidate; authenticated scans, or you are testing your login page only. A managed DAST scanner or a tuned ZAP pipeline both satisfy this — owning triage is what matters.
- Infrastructure-as-code scanning for the misconfiguration class before it deploys.
- Build provenance: artifacts signed, deploys accept signed artifacts only.
- A break-glass process documented for shipping an emergency fix past gates — because if there is no sanctioned path, engineers will invent unsanctioned ones.
Runtime and detection
- Structured security logging: auth events, authorization denials, input validation failures, admin actions — with user, IP, and request ID, shipped off-host.
- Alerting on patterns, not single events: spray of 403s across object IDs, login failures per source, sudden egress from build or app hosts.
- Rate limiting on authentication and expensive endpoints.
- WAF as a mitigation layer with tuned rules — never as the reason a known injection bug stays unfixed.
- Dependency inventory live in production (what is actually running, not what the repo says), reconciled against SBOMs.
Response: assume a bad week
- On-call knows where security alerts land and who decides severity.
- Playbooks exist for the three most likely events: leaked credential, vulnerable dependency disclosed in something you ship, and account takeover of a privileged user.
- Key rotation for every secret class is a documented, tested procedure with a known duration.
- Post-incident reviews feed new checklist items — this list should grow a line or two per year from your own incidents, or it is not being used.
Making the checklist survive contact with Q3
Three habits separate teams whose application security checklist works from teams that laminate it:
- Automate enforcement, not reminders. Every item above that can be a CI gate or a scheduled scan should be one. Humans review the exceptions.
- Assign each section an owner with the authority to fail builds. Shared ownership is no ownership.
- Re-audit quarterly against reality, not against intentions: pull the actual headers, the actual scan logs, the actual last rotation date.
Teams starting from zero should sequence it: dependencies and secrets first (highest breach likelihood per hour invested), then access-control testing, then pipeline scanning, then runtime detection.
FAQ
How is this application security checklist different for 2026?
Mainly weighting. Supply chain items moved from "advanced" to "core" tracking the OWASP Top 10 2025 changes, fail-closed exception handling got explicit treatment, and short-lived credentials replaced "rotate your API keys" as the default recommendation.
What should a small team implement first?
Lockfile enforcement, SCA scanning on PRs, secret scanning, and security headers. All four are near-zero maintenance once configured and cover the most-exploited paths.
How do we measure whether the checklist is working?
Track mean time to remediate by severity, percentage of checklist items enforced automatically versus manually, and scanner-finding recurrence rate (fixed issues that return). All three trend visibly within a quarter.
Do we need a framework like ASVS instead of a checklist?
They complement. OWASP ASVS is the exhaustive verification standard; a checklist like this is the operational digest your pipeline enforces daily. Use ASVS to audit the checklist's blind spots annually.