09 — Security Checklist#

Assess confidentiality, integrity, availability, abuse resistance, and operational security proportionate to project risk.

Scope: Backend / API-specific. This file is one part of the 09_Security.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

Project / product:
Release / version / environment:
Scope and applicable jurisdictions / markets:
Reviewer / owner:
Review date:
Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

Copy this template into each project's review records; keep the shared repository template unchecked.
Check [x] only after verifying the item with evidence. For any inapplicable item, record N/A and the reason in the project's own review notes or issue tracker using its checklist ID; do not mark it as passed.
Record evidence links or artifact references by checklist ID. Open an issue for every failed item, assign an owner and due date, and retest after remediation.
Apply the release gate below. These checklists guide review; they do not replace qualified specialist review when required.

Identity and access management#

SEC-007 Authorization is enforced server-side on every protected object, action, and tenant boundary.
SEC-045 Test tenant isolation at query, storage, cache, and API response boundaries.

Application, API, and supply-chain security#

SEC-013 CSRF, XSS, SSRF, path traversal, file upload, and request-smuggling exposures are evaluated as relevant.
SEC-014 APIs use appropriate authorization, rate limits, schema validation, replay controls, and safe error responses.
SEC-015 Dependencies, lockfiles, container images, and build tools are scanned; critical findings are triaged.
SEC-046 Track APIs, versions, and public endpoints in an inventory with accountable owners.
SEC-048 Assess business-flow abuse (bulk purchases, scraping, automated signup) beyond simple request rate limits.
SEC-049 Confirm file handling enforces type, size, storage, malware scanning, and safe serving as applicable.

Secrets, encryption, and data protection#

SEC-019 No passwords, API keys, private keys, or tokens are committed to repositories or logs.
SEC-022 Sensitive data is encrypted at rest where warranted, with protected keys and defined rotation/backup.

Infrastructure and deployment#

SEC-025 Cloud identities, network boundaries, firewall rules, public storage, and database exposure are reviewed.
SEC-026 Servers, containers, and runtime settings are hardened; unused services and debug features are disabled.
SEC-028 Infrastructure-as-code and deployment changes are reviewed, tested, and tracked.
SEC-052 Verify edge/CDN and API gateway controls match intended origin permissions and do not bypass application authorization.
SEC-027 Security headers, CORS, caching of sensitive responses, and cookie attributes are configured appropriately.
SEC-029 Backups are protected and restore procedures are tested.
SEC-030 Monitoring detects suspicious access, configuration drift, and high-risk failures.
SEC-053 Test cache headers and isolation for authenticated or user-specific API and HTML responses.

Security scope and architecture#

SEC-005 Production, staging, and development environments are appropriately isolated.

API Checks#

Apply to API endpoints, client integrations, webhooks, or data feeds present in the project. Record N/A with reasons if none exist.

Reference basis: OWASP API Security Top 10 (2023); OWASP Application Security Verification Standard (ASVS) 5.0; OWASP ASVS 5.0 control families (web frontend and API).

SEC-058 Perform object-level authorization tests for manipulated IDs on every read, write, and delete endpoint (OWASP API1).
SEC-059 Test authentication token issuance, expiry, audience/issuer, signature validation, revocation, and replay resistance where relevant.
SEC-060 Verify field-level read/write authorization against over-posting, mass assignment, and excess property exposure (API3).
SEC-061 Verify function-level authorization for administrative and privileged methods (API5).
SEC-062 Enforce and test resource limits: rate, page size, payload size, timeouts, concurrency, and costly downstream calls (API4).
SEC-063 Assess abuse of valuable business flows such as signup, purchasing, voting, and account recovery (API6).
SEC-064 Test SSRF controls for URL-fetching endpoints and all outbound destinations (API7).
SEC-065 Validate request schemas and content types and reject unknown/unsafe fields as appropriate.
SEC-066 Check CORS allowlists, credentials, preflight behavior, and API security headers without treating CORS as authentication.
SEC-067 Inventory all active API versions and hosts; disable forgotten debug, staging, and deprecated endpoints (API9).
SEC-068 Validate and constrain third-party API data before trusting it; protect API keys and outbound authentication (API10).
SEC-069 Review predictable errors and 401/403/404 behavior for information leakage and stack traces.
SEC-070 Ensure webhook authenticity, replay defenses, idempotency, and signature checking where used.
SEC-071 Audit access-control decisions and abuse events without storing secrets or unnecessary sensitive payloads.

Release gate#

All applicable high-priority checks above pass, or an authorized decision-maker has explicitly accepted and documented each residual risk.
Failed items have tracked remediation, owners, and deadlines; material blockers remain blocked until resolved.
Evidence links and the reviewer, review date, and final decision are recorded.

Domain-specific approval rule: Block release for exploitable critical/high findings without approved mitigation, missing authorization boundaries, exposed secrets, or unprotected sensitive data.

Trusted references and scope#

The checks above are adapted into practical verification questions from these authoritative publications (not copied as standards text). Verify current versions and the project's scope before sign-off.

Guidance is risk-based and project-specific; sources do not replace testing or specialist review.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

Test focus: secrets, authorization, dependency vulnerabilities, attack surfaces, and validation failures; include API and service behavior where applicable.
Cross-stack: OWASP ZAP + Gitleaks + Trivy.
Python: Bandit + pip-audit + pytest; for pytest-based suites, run python -m pytest -q.
TypeScript: ESLint + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
JavaScript: Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

security-threat-model — Identify assets, trust boundaries, and abuse paths (openai/skills, 28,705 repo stars).
sharp-edges — Assess unsafe defaults and misuse risks (trailofbits/skills, 8,150 repo stars).
semgrep — Find review candidates using static security rules (trailofbits/skills, 8,150 repo stars).

How to check: In a project-specific copy, have the agent audit the backend / API scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.