An application can pass a vulnerability scan and still let one customer download another customer’s records. It can require multifactor authentication and still expose accounts through a weak recovery process. These failures illustrate a fundamental problem: security tools can identify weaknesses, but they cannot replace sound design, clear ownership, and verification.
For business owners, technology leaders, and development teams, application security needs to be a repeatable operating process—not a final inspection before launch. Every important control should have an accountable owner, a testable requirement, and evidence that it works.
The checklist below provides a practical starting point for web applications and APIs. Use it during design, before release, and whenever meaningful changes affect your application’s security.
Build Requirements, Not Just a List of Tools
The OWASP Application Security Verification Standard (ASVS) provides a foundation for detailed, testable technical requirements. NIST’s Secure Software Development Framework (SSDF) complements that approach with lifecycle practices for preparing teams, protecting software, developing securely, and responding to vulnerabilities.
Your requirements should reflect what the application actually does. A public information site and a financial platform do not need identical controls. Both, however, need explicit security decisions rather than assumptions.
A security control is not complete because someone enabled it. It is complete when the team can demonstrate that it works—and knows who will maintain it.
The Application Security Checklist
1. Define What Needs Protection
- Inventory applications, APIs, sensitive data, third-party integrations, and production environments.
- Map how sensitive information enters, moves through, and leaves the application.
- Document security requirements before development, including access, encryption, retention, and deletion needs.
- Identify potential misuse of account recovery, payments, exports, and administrative workflows.
Accountable owner: Application or product owner, supported by engineering and security.
Evidence: An application inventory, data-flow diagram, and approved requirements. For example, a payment workflow should define who can change payout details and what additional verification is required. Record who can accept unresolved risks; developers should not inherit that decision by default.
2. Protect Authentication and Account Recovery
- Support multifactor authentication and prioritize phishing-resistant methods for privileged access.
- Throttle repeated login attempts and monitor suspicious authentication activity.
- Test password resets and recovery paths, including expired or reused recovery tokens.
- Require reauthentication before sensitive actions, such as changing authentication factors.
Accountable owner: Identity or application engineering lead.
Evidence: Tests showing that automated guessing is restricted and recovery cannot bypass account protections. As the OWASP Authentication Cheat Sheet explains, authentication includes more than the login screen. A strong front door provides little protection if account recovery offers an easier entrance.
3. Enforce Authorization on Every Request
- Deny access unless a request is explicitly permitted.
- Enforce permissions on the server, not through hidden buttons or browser-side checks.
- Test access to other users’ records by changing identifiers and request parameters.
- Include cross-tenant, administrative, and API authorization tests where applicable.
Accountable owner: Application engineering lead.
Evidence: Automated tests demonstrating that unauthorized requests fail without exposing data or performing prohibited actions. If a customer changes an invoice identifier in an API request, the server must verify ownership—not merely confirm that the customer is logged in. Follow OWASP’s authorization guidance on least privilege and permission validation.
4. Secure Sessions Throughout Their Lifecycle
- Use HTTPS throughout authenticated sessions.
- Set session cookies with Secure, HttpOnly, and an appropriate SameSite policy.
- Renew session identifiers after authentication or privilege changes.
- Enforce server-side expiration and invalidate sessions on logout.
Accountable owner: Application engineering lead, with platform support.
Evidence: Reviewed cookie settings and tests confirming that expired or logged-out sessions cannot be reused. Closing a browser tab is not session invalidation. For cookie-authenticated applications, verify appropriate protection against cross-site request forgery; cookie settings alone should not be treated as a complete defense.
5. Prevent Injection and Unsafe Output
- Use parameterized database queries instead of concatenating user input.
- Use automatic output escaping and context-appropriate encoding.
- Avoid passing untrusted input into shell commands.
- Review exceptions that disable framework protections.
Accountable owner: Development lead.
Evidence: Code-review records and tests covering injection-sensitive paths. A search field should pass its value as a database parameter, not append it to a query string. Likewise, content safe for display as text may not be safe inside JavaScript. CISA’s secure-by-design guidance recommends parameterized queries and automatically escaping template frameworks.
6. Keep Credentials Out of Code
- Store application secrets in a managed secrets system.
- Restrict each service to the secrets it actually needs.
- Scan repositories and build workflows for exposed credentials.
- Revoke and replace compromised secrets rather than simply deleting them from source files.
Accountable owner: Platform or DevOps lead.
Evidence: Access policies, scanning results, and a tested revocation procedure. A database password removed from the latest commit may remain in repository history, build artifacts, or someone else’s copy. Treat exposure as a credential compromise, not a housekeeping task. Prefer short-lived workload credentials where supported.
7. Manage Dependencies and Secure Defaults
- Maintain an inventory of third-party components and track security updates.
- Prioritize applicable known-exploited vulnerabilities, considering exposure and impact.
- Remove shared default passwords, hardcoded credentials, and unnecessary services.
- Define support periods and a reliable process for delivering security fixes.
Accountable owner: Engineering or platform lead.
Evidence: A component inventory, remediation records, and documented support commitments. Knowing that a vulnerable package exists is only the beginning; someone must determine whether it affects the application and oversee remediation. CISA and the FBI’s Product Security Bad Practices guidance addresses these recurring weaknesses.
8. Test Before Release—and After Changes
- Combine code review, static analysis, dependency checks, and dynamic testing.
- Manually test business logic and access controls.
- Define which findings block deployment and who can approve exceptions.
- Retest fixes and retain release-specific results.
Accountable owner: Release owner, supported by engineering and security.
Evidence: A security report identifying the tested version, unresolved findings, and approvals. Automated tools may detect an injection flaw but miss a refund workflow that permits repeated reimbursements. The OWASP Web Security Testing Guide supports testing throughout development rather than relying on a single prelaunch assessment.
9. Make Suspicious Activity Visible
- Log authentication failures, authorization failures, and important administrative actions.
- Exclude passwords, access tokens, and unnecessary sensitive information.
- Protect logs against unauthorized access and modification.
- Test alerts and identify who responds, including outside normal business hours.
Accountable owner: Security operations or the designated operational lead.
Evidence: A sample event traced from application logging through alert handling. Generate a controlled test event and confirm that the right responder receives useful context. A log entry nobody reviews is not an effective detection process. Establish escalation and containment procedures before an incident forces those decisions.
Turn the Checklist Into an Operating Process
Use a shared tracking sheet with these fields:
Control | Owner | Status | Evidence | Remediation deadline | Exception expiry
This is a practical implementation suggestion, not a format mandated by the referenced standards. Mark each control Pass, Fail, or Not applicable—with justification. Missing evidence should not quietly become a pass.
Make evidence specific to the application version and environment. A passing test from an earlier release may no longer prove that a redesigned permissions system works. Link failures to remediation work, assign deadlines according to risk, and require documented approval for temporary exceptions.
Revisit affected controls when adding integrations, changing authentication, introducing sensitive data, or modifying administrative capabilities. Third-party identity, hosting, or payment services can reduce implementation work, but your team still owns its configuration and integration decisions.
Start With One Application and Demand Evidence
Checklist completion is not certification, and it cannot guarantee security. Its value is making responsibilities, weaknesses, and decisions visible.
Choose one business-critical application, assign an accountable owner, and review these nine areas against current evidence. Address exposed credentials, broken access controls, and other urgent risks first. Then expand this checklist into application-specific, testable requirements using ASVS. The goal is not a finished spreadsheet. It is a dependable process that keeps working as your software changes.