Security Testing Checklist for Developers: Authentication, APIs, CI/CD, and More

Security vulnerabilities don't appear out of nowhere. They're introduced by developers writing code under deadline pressure, making reasonable assumptions that turn out to be wrong, or simply not knowing what to look for. The good news: a significant proportion of real-world vulnerabilities are predictable, recurring, and testable.

This checklist gives development teams a systematic way to verify security controls before code ships. It's organized by domain — authentication, input validation, session management, API security, dependency management, and CI/CD — so you can work through it section by section and adapt it to your stack.

This is a developer-facing checklist, not a penetration testing methodology. Use it during code review, before releases, and as a baseline for your automated test suite.

1. Authentication Testing

Authentication is the gateway to your application. Weaknesses here are high-impact by definition — if authentication fails, everything behind it is compromised.

Checklist

• Password policy enforced: Minimum length (12+ characters), no arbitrary complexity rules that reduce entropy, check against breached password lists (HaveIBeenPwned API)
• Brute force protection: Account lockout or exponential backoff after N failed attempts; CAPTCHA on high-risk login flows
• Rate limiting on login endpoint: Cannot make more than N login attempts per minute per IP/account
• Multi-factor authentication available: TOTP (Google Authenticator-compatible), WebAuthn, or SMS as minimum; MFA enforced for admin accounts
• Credential stuffing resistance: Rate limiting, CAPTCHA, and anomaly detection on login flows; device fingerprinting considered
• Password reset flow is secure:
  • Reset tokens are random, cryptographically generated (not sequential IDs)
  • Tokens expire after a short window (15–60 minutes)
  • Token is invalidated after use
  • Reset does not reveal whether an email is registered (prevent account enumeration)
  • No security questions as the sole reset mechanism
• Account enumeration prevented: Login and registration error messages don't distinguish between "user not found" and "wrong password"
• OAuth/OIDC flows verified:
  • state parameter used and validated (prevents CSRF)
  • redirect_uri strictly validated against allowlist
  • Authorization code exchanged server-side, not in client JavaScript
  • Access tokens not stored in localStorage
• Default credentials changed: Any admin or service accounts created during provisioning use non-default credentials
• Session invalidated on password change: All existing sessions are terminated when a user changes their password

Test approaches

Write automated tests that attempt invalid logins, verify lockout behavior, test token expiry, and confirm error messages don't enumerate users. HelpMeTest's natural language test creation makes it straightforward to define authentication scenarios — "attempt login with wrong password 10 times and verify account lockout response" — and run them automatically against every deployment.

2. Input Validation

Every piece of data that enters your application from an external source is untrusted. Failure to validate and sanitize inputs is the root cause of SQL injection, XSS, command injection, path traversal, and a long list of other vulnerability classes.

Checklist

• Server-side validation for all inputs: Client-side validation is UX, not security; always validate on the server
• Allowlisting preferred over denylisting: Specify what's allowed, reject everything else; don't try to block specific bad patterns
• SQL injection prevention:
  • Parameterized queries / prepared statements used everywhere; no string concatenation in SQL
  • ORM used correctly — check for raw query usage that bypasses the ORM
  • Database user has minimum required permissions (no DROP, no admin role for application user)
• XSS prevention:
  • All user-supplied content HTML-encoded when rendered in templates
  • Content-Security-Policy header configured and tested
  • X-XSS-Protection header present (legacy browsers)
  • innerHTML assignment avoided; textContent used instead where possible
  • dangerouslySetInnerHTML (React) / v-html (Vue) only used with sanitized content
• Command injection prevention: Shell commands never constructed using user input; subprocess calls use argument arrays, not string interpolation
• Path traversal prevention: File paths constructed from user input are resolved and validated against an allowlist of permitted directories
• XML injection / XXE prevention: XML parsing configured to disable external entity processing (FEATURE_SECURE_PROCESSING or equivalent)
• File upload validation:
  • File type validated by content (magic bytes), not just extension
  • Uploaded files served from a different domain or with Content-Disposition: attachment
  • File size limits enforced
  • Uploaded files scanned for malware
• Integer overflow / type confusion: Numeric inputs validated for range; language-specific integer overflow risks considered
• Mass assignment protection: Model binding configured to allowlist only expected fields (prevent setting is_admin, role, etc.)

3. Session Management

Sessions are how your application maintains identity between requests. Flaws in session management let attackers hijack authenticated users without needing their credentials.

Checklist

• Session tokens are cryptographically random: Generated with a CSPRNG, not sequential or time-based
• Session token length is sufficient: 128 bits (16 bytes) of entropy minimum
• Session regenerated after login: New session ID issued after successful authentication (prevents session fixation)
• Session invalidated on logout: Token deleted server-side, not just cleared client-side
• Session timeout configured:
  • Idle timeout (session expires after N minutes of inactivity)
  • Absolute timeout (session expires after N hours regardless of activity)
• Session cookies configured correctly:
  • HttpOnly flag set (prevents JavaScript access)
  • Secure flag set (HTTPS only)
  • SameSite=Strict or SameSite=Lax (prevents cross-site request forgery)
  • Appropriate Domain and Path scope
• CSRF protection:
  • Synchronizer Token Pattern or Double Submit Cookie implemented for state-changing requests
  • SameSite cookie attribute used as a defense-in-depth measure
  • Custom request headers (e.g., X-Requested-With) verified for AJAX endpoints
• JWT security (if using JWTs):
  • Algorithm explicitly specified — not taken from the token header (prevents alg: none attacks)
  • Asymmetric algorithm (RS256) preferred over symmetric (HS256) for distributed verification
  • Token expiry (exp claim) is short (15 minutes to 1 hour for access tokens)
  • Refresh token rotation implemented
  • Tokens not stored in localStorage (use HttpOnly cookies or memory)
• Concurrent session handling: Application has a policy for concurrent sessions (allowed, limited, or requires MFA for new device)

4. Access Control and Authorization

Authentication verifies who you are. Authorization verifies what you're allowed to do. These are separate concerns, and authorization failures are among the most common vulnerabilities in real-world applications.

Checklist

• Authorization checked on every request: Not just on page load or initial API call — every subsequent request is authorized server-side
• IDOR prevention:
  • Object IDs are not sequential integers (use UUIDs or similar opaque identifiers)
  • Access control check performed on the object, not just the URL (verify the authenticated user owns or has permission to access the requested resource)
• Horizontal privilege escalation prevented: User A cannot access or modify User B's resources
• Vertical privilege escalation prevented: Regular users cannot access admin functionality; role checks are enforced server-side
• Principle of least privilege applied: Service accounts, API keys, and user roles have minimum permissions required
• Admin functionality protected: Admin routes require not just authentication but admin role verification on every request
• Directory listing disabled: Web server not configured to list directory contents
• Sensitive files not in web root: Configuration files, backup files, and .git directories not accessible via HTTP

5. API Security

APIs introduce a distinct set of security concerns. They're often exposed to more clients (mobile apps, third parties, SPAs), have less mature security controls than web UI flows, and frequently lack the same level of scrutiny during code review.

Checklist

• Authentication required on all non-public endpoints: No unauthenticated access to data or state-changing operations
• Authorization enforced at the data layer: Not just at the route level — check permissions when querying the database
• Rate limiting on all endpoints: Not just authentication — prevent enumeration and denial-of-service on any endpoint
• Input validation on all API parameters: Query strings, path parameters, request body fields, and headers
• Sensitive data not in URLs: Authentication tokens, API keys, and PII never in query strings (logged by servers and proxies)
• Error responses don't expose internals: Stack traces, database error messages, and internal paths not returned to clients
• API versioning and deprecation: Old API versions are monitored, rate-limited, and eventually disabled — not left running indefinitely
• GraphQL-specific (if applicable):
  • Query depth limiting configured
  • Query complexity limiting configured
  • Introspection disabled in production
  • Field-level authorization implemented
• API keys and tokens:
  • Keys are rotatable and can be revoked instantly
  • Keys have defined scopes (not all-or-nothing)
  • Keys logged with each request for audit purposes
  • Keys not logged in application logs in full (mask or hash)
• CORS configured correctly:
  • Access-Control-Allow-Origin set to specific allowed origins, not *
  • Credentials (cookies, Authorization headers) not allowed with wildcard origin
  • Preflight requests return correct headers

6. Dependency and Supply Chain Security

Modern applications depend on hundreds of open-source packages. Each dependency is a potential attack vector — either through known vulnerabilities in existing versions or through supply chain attacks (malicious packages, dependency confusion).

Checklist

• Dependency inventory maintained: All direct and transitive dependencies are known and documented
• Dependency scanning automated: Tools like npm audit, pip-audit, OWASP Dependency-Check, or Snyk run in CI on every commit
• Known vulnerable versions not in use: No dependencies with unpatched CVEs rated High or Critical
• Dependency update process defined: Regular dependency updates scheduled, not only when vulnerabilities are discovered
• Lock files committed: package-lock.json, Pipfile.lock, go.sum, etc. committed and used in CI to prevent version drift
• Dependency sources verified: Only install from official registries; consider private registries with allowlists for enterprises
• SBOM (Software Bill of Materials): Generated and maintained for regulatory compliance (required by EO 14028 for US government contractors)
• Container base images: Using minimal, up-to-date base images; image scanning in CI (Trivy, Grype, or Snyk Container)

7. CI/CD Security Checks

Your CI/CD pipeline is both a high-value attack target and the best place to enforce security controls automatically. Security checks that run on every commit catch vulnerabilities at the moment they're introduced, not weeks later during a penetration test.

Checklist

• Secret detection: Tools like git-secrets, detect-secrets, or truffleHog scan commits for accidentally committed credentials, API keys, and tokens
• SAST (Static Application Security Testing): Tools like Semgrep, CodeQL, or Checkmarx analyze code for security issues without running it
• Dependency scanning: Automated vulnerability scanning on every dependency change
• Container scanning: Images scanned for vulnerabilities before deployment
• Security headers verified: Automated check that all expected security headers (Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, etc.) are present in application responses
• Infrastructure as Code scanning: Tools like tfsec, Checkov, or kics scan Terraform, CloudFormation, and Kubernetes manifests for security misconfigurations before deployment
• Pipeline secrets management: CI/CD secrets stored in a secrets manager (GitHub Secrets, Vault, AWS Secrets Manager) — not in environment files committed to the repository
• Pipeline access controls: Limited personnel can approve deployments to production; deployment requires review
• Audit logging: All CI/CD actions are logged with actor identity and timestamp
• Automated security regression tests: Tests that verify security controls — authentication requirements, rate limiting behavior, security headers — run on every deployment

HelpMeTest integrates directly into this layer. Using Robot Framework and Playwright, you can write test scenarios that verify authentication flows reject unauthenticated requests, confirm rate limiting kicks in after threshold breaches, and check that security headers are present on every response — running automatically on every pull request before code is merged.

8. Cryptography and Data Protection

Checklist

• Passwords hashed with a modern algorithm: bcrypt, Argon2, or scrypt — never MD5, SHA1, or unsalted SHA256
• Sensitive data encrypted at rest: Encryption keys managed separately from data (KMS, HSM, or Vault)
• Sensitive data encrypted in transit: TLS 1.2+ on all connections; TLS 1.0 and 1.1 disabled
• TLS certificate management: Certificates renewed before expiry; automated renewal with Let's Encrypt or ACM preferred
• PII minimization: Only collect and retain data you actually need; define retention periods and implement automated deletion
• Sensitive data not logged: Passwords, tokens, full credit card numbers, SSNs, and similar PII are never written to application logs
• Key rotation process defined: Encryption keys, API keys, and certificates have defined rotation schedules

Making This Checklist Work in Practice

A checklist that lives in a document is better than no checklist. A checklist integrated into your development workflow is vastly better.

Consider these integration points:

Code review: Add security items to your PR template. Reviewers explicitly sign off on authentication, authorization, and input validation for any changes that touch those areas.

Automated tests: Write automated tests for security controls that should be stable — rate limiting, authentication requirements, security header presence. Run them on every deployment.

Pre-commit hooks: Use detect-secrets and linting tools as pre-commit hooks to catch secrets and obvious issues before they ever reach the repository.

Scheduled scans: Run OWASP ZAP or Snyk scans on a schedule against staging environments, even when no changes have been deployed. Catch environment drift before it becomes a vulnerability.

The goal is to make security verification as automatic as unit tests — something that runs without anyone having to remember to do it.

Conclusion

Security vulnerabilities in web applications follow predictable patterns. Authentication weaknesses, insufficient input validation, broken access control, and insecure dependencies account for a disproportionate share of real-world breaches.

Working through this checklist systematically — for new features, during code review, and as automated tests — doesn't make your application unhackable. It makes your application resilient against the attacks that actually happen, closes the gaps that automated scanners and penetration testers look for first, and builds security into your development culture rather than treating it as an afterthought.

The checklist is a starting point. The goal is a development team that internalizes these patterns and stops writing vulnerable code in the first place.