Use an ASVS-aligned checklist with a Level 2 baseline for most business web apps, covering authentication, input validation, session management, cryptography, configuration hardening, dependency management, logging, and security testing. This gives development and security teams a structured, verifiable standard instead of an ad hoc list of best guesses.
TL;DR:
- Map each control to its ASVS section and a concrete acceptance criterion; prioritize exploitable unauthenticated flaws before configuration gaps and long term architecture work.
- Enforce server side authorization on every request, require phishing resistant MFA for privileged accounts, and rotate session tokens after login, password resets, or privilege changes.
- Run SAST and SCA in continuous integration on every build, while scheduling staging tests and penetration tests according to application risk.
- For APIs, validate request and response schemas strictly, authenticate every machine client, enforce gateway rate limits, and review third party permissions before launch.
- Mark controls complete only with verifiable evidence, such as a passing test, enforced configuration screenshot, or signed code review tied to the relevant ASVS section.
Table of Contents
- How to use this web app security checklist
- Authentication and access control
- Input validation and output encoding
- Session management and cookie security
- Data protection and cryptography
- Configuration, deployment, and platform hardening
- Dependency and software supply chain controls
- Logging, monitoring, and incident response
- Security testing and SDLC integration
- API and third-party integrations
- Prioritization and triage: how to use this checklist in practice
- Arslan Web Studio: practical experience and when to hire help
- Why security has to live inside the developer’s everyday workflow
- Get your web app security checklist implemented, not just written
- FAQ
- Sources
How to use this web app security checklist
This checklist applies to production web apps and APIs, and it works best when developers, DevOps engineers, and security reviewers all check items against the same standard.
- Map each checklist item to its matching ASVS section and write a concrete acceptance criterion for it.
- Sort findings into three buckets: urgent and exploitable, medium risk, and long-term architecture work.
- Treat Level 1 as a minimum floor and Level 2 as the working target for anything handling business or customer data.
Pro Tip: Attach the ASVS section number to every ticket you open, so remediation work stays traceable back to the standard.
Authentication and access control
Authentication failures and broken access control sit at the top of nearly every incident report, which is why they open most ASVS-aligned reviews.
- Centralize identity through SAML or OIDC rather than maintaining custom login flows for each app.
- Require phishing-resistant MFA for administrators and privileged accounts, following patterns like those in CISA’s Azure AD baseline, which blocks legacy authentication and enforces risk-based policies for high-risk users.
- Enforce authorization checks on the server for every request, never trusting a hidden field or disabled button on the client.
- Apply least-privilege role models so a compromised account can’t pivot into unrelated data or admin functions.
- Rotate service account secrets on a defined schedule and store them in an approved vault rather than in code or config files.
Statistic Callout: The OWASP Top 10:2025 lists Broken Access Control among the most critical web application risks, alongside security misconfiguration and software supply chain failures. Access control failures tend to be high-impact because they expose data or functions that should never have been reachable in the first place.
Input validation and output encoding
Injection and cross-site scripting both trace back to the same root problem: untrusted input treated as trusted code or markup.
- Validate every input on the server, since client-side checks can be bypassed and should be treated as a usability layer, not a security control.
- Enforce strict schemas and canonicalize data before validating it, closing off encoding tricks attackers use to slip past filters.
- Apply context-aware output encoding, because the escaping rules for HTML, JavaScript, and URL parameters are different and mixing them up reopens the hole.
- Use parameterized queries or an ORM for all database access instead of building SQL strings by hand.
- Review templates for auto-escaping settings, since many frameworks allow developers to opt out of safe rendering without realizing the risk.
A single unescaped field in a search result or comment thread is often all it takes to run arbitrary script in another user’s browser session.
Session management and cookie security
Session handling connects authentication to everything a user does afterward, so weaknesses here undermine controls built everywhere else.
Generate session identifiers with a cryptographically secure random source, and rotate the token whenever a user’s privilege level changes, such as after login or a password reset. Set the Secure, HttpOnly, and SameSite attributes on every session cookie, and keep expiry windows short enough to limit the damage from a stolen token. Session tokens should be random, unpredictable, and invalidated server-side on logout and on any credential change, not just cleared from the browser.
Data protection and cryptography
Cryptography checks exist to confirm that data is actually protected in transit and at rest, not just theoretically encryptable.
Enforce modern TLS configurations and keep certificate renewal automated so expired certificates never silently downgrade a connection. Use vetted, well-maintained cryptographic libraries for encryption and hashing, and avoid writing custom algorithms, since even small implementation errors tend to produce exploitable weaknesses. Store encryption keys in a managed key store or hardware-backed module rather than alongside the data they protect, and rotate them on a defined schedule. The OWASP Top 10:2025 lists cryptographic failures as a recurring category precisely because teams reach for shortcuts under deployment pressure.
Configuration, deployment, and platform hardening
A secure codebase can still ship with an insecure configuration, which is why hardening checks sit alongside code review rather than replacing it.
- Disable debug endpoints, verbose error pages, and admin interfaces before anything reaches production.
- Harden containers and host images to a minimal footprint, removing unused packages and services.
- Scope cloud IAM roles to the minimum permissions a service actually needs, rather than reusing broad roles across environments.
- Scan infrastructure-as-code templates in the pipeline so a misconfigured security group never reaches a live environment.
- Compare each environment against a documented secure configuration baseline, similar in spirit to CISA’s published baseline for identity platforms.
Dependency and software supply chain controls
Most applications now carry more third-party code than first-party code, which makes dependency hygiene a frontline control rather than a background task.
- Run software composition analysis in CI on every build and pin or lock dependency versions.
- Remove packages that are no longer used and watch for typosquatting or repository impersonation attempts.
- Define update cadence and security expectations for suppliers rather than treating every dependency bump as optional.
CISA’s supply chain guidance recommends nightly regression builds and artifact provenance checks to catch injected malicious code early.
Logging, monitoring, and incident response
Controls that fail silently are the ones that cause the most damage, so visibility matters as much as prevention.
Centralize logs in a SIEM and make sure authentication failures, privilege changes, and admin actions are all captured. Build detection rules around the behaviors that matter most to your app, and test incident response playbooks before an actual incident forces you to improvise. Protect log stores from tampering and set retention periods long enough to support an investigation months after the fact.
Security testing and SDLC integration
Security testing works best when it’s distributed across the build pipeline instead of concentrated in a single pre-launch pentest.
- Add SAST and SCA scanning to continuous integration so flaws surface before merge, not after deployment.
- Schedule DAST or IAST runs against staging environments and plan penetration tests at a cadence that matches your risk level.
- Run threat modeling during the design phase and map resulting test cases to ASVS sections and the OWASP Top 10.
- Require release gates that block deployment until findings are remediated or risk is formally accepted.
NIST SP 800-218 (SSDF) recommends integrating SAST, SCA, and threat modeling directly into the SDLC rather than bolting testing on at the end.
Pro Tip: Catching a flaw in CI costs far less than catching the same flaw in a late-stage penetration test, so push testing as early into the pipeline as the tooling allows.
API and third-party integrations
APIs extend your attack surface to every system that calls them, so they need their own checklist items rather than inheriting web app checks by assumption.
Validate request and response schemas strictly, enforce rate limits, and require authenticated credentials for every machine client, not just human users. Put authorization and throttling rules at the gateway layer so a single compromised client can’t exhaust shared resources. Version APIs deliberately and review the permissions granted to any third-party integration before it goes live, since over-broad consent scopes are a common path for abuse.
Prioritization and triage: how to use this checklist in practice
Not every finding deserves the same urgency, so score each one by impact multiplied by likelihood and map it back to its ASVS section.
- Fix immediately: exploitable issues reachable without authentication, such as broken access control or missing input validation.
- Address mid-term: configuration gaps and missing MFA that raise risk but require specific conditions to exploit.
- Plan long-term: architectural changes like migrating to a centralized identity provider or re-architecting session handling.
Pro Tip: Mark a checklist item complete only when you have evidence, a passing test, a screenshot of enforced configuration, or a signed-off code review, not just a verbal confirmation.
Arslan Web Studio: practical experience and when to hire help
We have built and hardened more than 200 client projects at Arslan Web Studio, spanning custom web applications, e-commerce platforms, and corporate sites, and we fold checklist items like these into our web application solutions as a standard part of delivery. Teams with in-house engineering capacity can often work through configuration and dependency items on their own. When a project needs authentication architecture changes, ongoing hardening, or sustained monitoring support, bringing in a specialist tends to move faster than building that capability from scratch.
Why security has to live inside the developer’s everyday workflow
Checklists fail when they live in a separate document nobody opens during a sprint. The fix is a paved road: make the secure dependency, the secure template, and the secure auth pattern the default choice, not an extra step. Pair that with periodic reviews and short, recurring team training, and the checklist stops being a one-time audit and becomes how the team already works.
— Arsan
Get your web app security checklist implemented, not just written
Reading a checklist is the easy part. Closing out dozens of ASVS-mapped findings across authentication, session handling, and dependency management takes engineering hours most internal teams don’t have spare. At Arslan Web Studio, we build that work into our web application solutions and pair it with the ongoing support that keeps controls from drifting out of date after launch.
- Web Application Solutions: secure architecture and development for custom apps and internal tools.
- E-commerce Development: hardened checkout, session, and payment integration flows.
- Ongoing Support: continuous monitoring and remediation as new risks surface.
| Service | What it covers |
|---|---|
| Web Application Solutions | Secure design, development, and ASVS-aligned hardening |
| E-commerce Development | Checkout security, payment data handling, session controls |
| Business & Corporate Website | Hardened builds with secure configuration baselines |
Request a security scoping call through our services page and we’ll walk through which checklist items matter most for your current build.
FAQ
What is the recommended ASVS level for a business web app?
ASVS Level 2 is the recommended baseline for most business applications that handle meaningful user or transaction data. Level 1 covers only minimum, automatable checks, while Level 3 is reserved for high-assurance applications with elevated risk.
How often should we run penetration tests versus automated scans?
Automated SAST and SCA scans should run on every build inside continuous integration, since they catch issues before code merges. Penetration testing cadence should match risk level, with higher-risk applications tested more frequently, following the continuous-testing approach described in NIST SP 800-218.
What belongs in a web app security checklist for APIs?
An API-focused checklist should require strict schema validation, authenticated machine clients, rate limiting at the gateway, and version control for every endpoint. Reviewing third-party integration permissions before launch closes off a common path attackers use to abuse over-broad consent scopes.
Which security headers should every web app set?
Content-Security-Policy, HTTP Strict Transport Security, and X-Frame-Options are core headers that reduce the impact of cross-site scripting, downgrade attacks, and clickjacking. These headers work alongside, not instead of, server-side input validation and output encoding.
How do we know a checklist item is actually complete?
A checklist item is complete only when there’s verifiable evidence behind it, such as a passing automated test, a documented configuration review, or a signed-off code review tied to the relevant ASVS section. A verbal confirmation or an unverified assumption doesn’t meet that bar.
