Web App Security Checklist

Most web application breaches exploit weaknesses that have been understood for years: broken access control, injection, weak authentication, misconfiguration, and vulnerable dependencies. This checklist covers the controls that prevent them, aligned with the OWASP Top Ten, with notes for modern server-rendered frameworks and AI features. It complements web application security and api security best practices, and reflects the standards FISTA Solutions applies in its web and mobile practice.

Who should use this checklist?

Engineering leads and security reviewers releasing web applications, platform teams owning shared web infrastructure, and product owners who need to know what secure means before launch.

Is authentication sound?

1. Central identity provider with single sign-on where applicable; no home-grown password storage where avoidable.
2. Strong password policy and MFA where credentials are managed locally; passwords hashed with a modern algorithm.
3. Session management: secure, HTTP-only, same-site cookies; rotation on login; expiry and revocation.
4. Account protection: rate limiting on authentication endpoints, lockout or challenge on abuse, secure reset flows.
5. Token handling for APIs: short-lived access tokens, secure refresh, audience and scope validation.

Reference: ai access control for the broader access model.

Is authorization enforced server-side?

Check	Evidence
Every data access checks the caller's permission on the server	Code review; tests
Object-level authorization prevents ID enumeration	Tests
Role and tenant boundaries enforced in queries, not only in UI	Tests
Server actions and API routes verify identity and permission	Code review
Admin functions separated and additionally protected	Review

Reference: the modern web platform architecture whitepaper.

Are inputs validated and outputs encoded?

1. Schema validation on all inputs at the boundary: API bodies, query parameters, form data, headers.
2. Parameterized queries everywhere; no string-built queries.
3. Output encoding appropriate to context; framework escaping not bypassed without review.
4. File uploads validated by type and size, stored outside the web root, scanned where warranted.
5. Server-side request forgery protections on any URL fetching.
6. Deserialization of untrusted data avoided or constrained.

Are security headers and policies set?

1. Content security policy restricting script, style, and connection sources.
2. Strict transport security, frame protections, content-type options, referrer policy, permissions policy.
3. Cross-origin resource sharing restricted to known origins.
4. Cross-site request forgery protections on state-changing requests.
5. Headers verified in production, not only in development.

Are dependencies controlled?

1. Dependency scanning in CI with failure on high-severity findings.
2. Lockfiles committed; versions pinned; updates reviewed.
3. Minimal dependency footprint; unused packages removed.
4. Build integrity: reproducible builds, signed artifacts where feasible.
5. Third-party scripts on pages inventoried and restricted by content security policy.

Reference: ai supply chain security for the AI-specific supply chain.

Are secrets managed?

1. Secrets in a vault or platform secret store; none in code, configuration files, or client bundles.
2. Environment separation: development secrets never used in production.
3. Rotation on schedule and on personnel change.
4. Secret scanning in repositories and CI.
5. Framework conventions for server-only environment variables respected and verified.

Reference: ai secrets management.

Is data protected?

1. Encryption in transit everywhere; at rest for sensitive data.
2. Data classification governing storage, logging, and third-party sharing.
3. Personal data handled per privacy policy: minimization, retention, subject rights.
4. Caching never stores personalized or sensitive responses at shared layers.
5. Backups encrypted and access-controlled.

Reference: caching strategies for web apps and ai data privacy compliance.

Are logging and monitoring in place?

1. Security-relevant events logged: authentication, authorization failures, admin actions, input validation failures.
2. Logs redacted of secrets and sensitive data; access-controlled; retained per policy.
3. Alerting on abuse patterns: credential stuffing, enumeration, unusual admin activity.
4. Incident response runbook for web incidents.

Reference: the AI observability whitepaper for the AI-feature counterpart.

Is infrastructure hardened?

1. Least-privilege cloud roles and network rules.
2. Rate limiting and abuse protection at the edge.
3. Web application firewall where appropriate.
4. Patched runtimes and images; minimal base images.
5. Infrastructure as code reviewed and scanned.

Reference: edge rendering and cdns.

Are AI features secured?

1. Prompt injection defenses and content separation.
2. Least-privilege tools and output validation for any agentic feature.
3. Provider data terms and redaction for content sent to models.
4. Adversarial tests in CI.

Reference: the LLM security checklist.

Has security testing been completed?

1. Static and dynamic scanning in CI.
2. Dependency and secret scanning passing.
3. Security review of authentication, authorization, and data flows for this release.
4. Penetration test completed for major releases with findings resolved or accepted with rationale.
5. Findings tracked with owners and dates.

How should gaps be handled?

Authentication, authorization, secrets, and injection gaps block release. Header, dependency, and logging gaps block release beyond a limited audience. Infrastructure and testing gaps are closed on a dated plan with risk acceptance recorded.

How FISTA Solutions builds secure web applications

FISTA Solutions applies this checklist as part of the definition of done in its web and mobile practice: central authentication, server-side authorization on every access, validated inputs and encoded outputs, security headers and content security policy, scanned and pinned dependencies, vaulted secrets, redacted logging with alerting, hardened infrastructure, and security testing in CI with periodic penetration tests. AI features are secured through the AI enablement platform and AI agents practice, and forward deployed engineers run security reviews with client teams. The record behind the approach is 150+ projects with 99.9% uptime.

To run a security review on a web application, message FISTA on WhatsApp, or read nextjs performance checklist for the companion performance review.