A useful web app security checklist does not ask whether security is “done.” It names the threat or failure, the control owner, the required state, the evidence, the verification method, the release decision, the recheck trigger, and the point where a security specialist must review the real system.
This field guide covers threat modeling, identity and sessions, tenant-safe authorization, validation and encoding, secrets, supply chain, uploads, outbound requests, browser controls, logs, abuse, recovery, deployment, monitoring, incident response, and tests. It is not a penetration test, compliance assessment, certification, or guarantee of complete security.
For a matching product with elevated privacy and abuse risk, use the build a dating app brief to define adult eligibility, consent, private discovery, block and report behavior, moderation, retention, and deletion. Then apply this checklist to the actual code, configuration, data flows, providers, and final environment; the commercial brief is not security evidence.
QUICK ANSWER
What should a web app security checklist include?
Start with a threat model and asset inventory, then verify authentication, sessions, server authorization, tenant isolation, input handling, output encoding, secrets, dependencies, uploads, outbound requests, browser controls, logs, abuse limits, recovery, TLS, headers, monitoring, and incident response. Give every field an owner, evidence, test, review date, release status, and specialist escalation boundary.
Prepare the system evidence before checking controls
A checklist without a defined system becomes an exercise in confident guessing. Use fictional test accounts and redacted evidence, but inventory the real components, environments, data, privileges, and providers that define the review boundary.
- System, data-flow, and trust-boundary map: List browser clients, APIs, databases, queues, storage, third-party providers, administrator paths, trust boundaries, sensitive data, and entry and exit points. Mark what is public, authenticated, privileged, tenant-scoped, or external. Source: OWASP Threat Modeling Cheat Sheet (checked 2026-07-19).
- Identity, role, record, and action matrix: For signed-out visitors, ordinary users, tenant members, managers, administrators, services, and support operators, name every allowed list, read, create, update, action, export, and recovery operation. Source: OWASP Authorization Cheat Sheet (checked 2026-07-19).
- Build, dependency, environment, and provider inventory: Record repositories, branches, build jobs, package manifests and locks, artifact sources, deploy identities, runtime versions, storage locations, external APIs, webhooks, and environment-specific credentials. Source: OWASP Software Supply Chain Security Cheat Sheet (checked 2026-07-19).
- Named review, risk-acceptance, and escalation owners: Name the engineering owner for each control, the release decision owner, the incident owner, the privacy or legal reviewer for personal or regulated data, and the security specialist who decides whether architecture review, code review, penetration testing, or another assessment is required.
Credentials and access
| Credential | Minimum access | Storage and rotation |
|---|---|---|
| Fictional ordinary-user and tenant fixtures Non-production test accounts in at least two isolated fictional tenants or workspaces | Only the normal roles and records needed to prove allowed, signed-out, wrong-role, and cross-tenant outcomes | Dedicated test environment or labeled production smoke fixtures without real customer data Delete or archive after the test under the documented retention rule and recreate for the next release |
| Security-testing access Time-bounded test identity and approved evidence access for the named reviewer | Only the environments, logs, configuration, code, and providers included in the documented review scope | Approved identity system and secret store, never issue text, screenshots, URLs, browser storage, or routine logs Revoke at review completion or scope change and preserve only redacted evidence required by policy |
Organize controls by risk and evidence, not by checkbox count
A technical-control list is easy to scan but can hide ownership and release decisions. A risk register explains threats and treatment but can miss concrete verification. The practical system connects both: every applicable control has a threat, owner, evidence, test, result, escalation boundary, and recheck trigger.
| Approach | Best for | Tradeoff |
|---|---|---|
| Control-family checklist | A repeatable engineering review across identity, access, validation, dependencies, browser behavior, deployment, and operations. | It is easy to standardize, but a generic row may look complete even when it does not address the app’s highest-risk data flow or business action. |
| Threat and risk register | A system with unusual data, payments, privileged operations, external integrations, multiple tenants, or serious legal, financial, medical, or physical impact. | It connects controls to consequences, but it needs disciplined links to code, configuration, tests, deployment evidence, owners, and dates. |
| Verification standard mapping | A team that needs consistent, versioned security requirements and test coverage for a defined assurance target. | A standard supplies a basis for verification, not automatic certification. Applicability, scope, testing depth, residual risk, and specialist judgment still need explicit decisions. |
Recommended:Use a control-family worksheet linked to the actual threat model and risk register. Select a versioned verification basis such as ASVS where appropriate, but record applicability and evidence rather than claiming the checklist makes the app secure or compliant. Source: OWASP Application Security Verification Standard (checked 2026-07-19).
Complete a web app security checklist step by step
Create the evidence ledger, model threats, verify application and browser boundaries, exercise recovery and incidents, and make an explicit risk-based release decision.
STEP 01
Create the owner-and-evidence ledger
Give every control a decision record before anyone marks it pass, fail, blocked, or accepted risk.
Owner: release security owner. Evidence: the worksheet below in version control or another approved review system, with one row per applicable control and links to redacted evidence. Verification: reject rows without an owner, dated source, test result, or recheck trigger. Escalate when scope, risk, or reviewer competence is unclear.
Use a versioned requirements basis as a yardstick and link exact requirement identifiers when the team selects them. Do not treat the basis as a certificate. Source: OWASP ASVS project (checked 2026-07-19).
WEB APP SECURITY EVIDENCE LEDGER
Review scope:
Release / artifact ID:
Environment:
Review date:
Release decision owner:
Security-review owner:
Incident owner:
CONTROL ROW
Control:
Threat / failure:
Assets and data:
Owner:
Required state:
Evidence:
Verification method:
Verification result:
Source:
Source checked: 2026-07-19
Status: pass / fail / blocked / accepted risk / not applicable
Risk acceptance owner and expiry:
Specialist review required when:
Recheck trigger:
ILLUSTRATIVE COMPLETED ROW - NOT PROOF FOR YOUR APP
Control: Session cookie attributes
Threat / failure: Session disclosure or unintended cross-site sending
Assets and data: Fictional ordinary-user session
Owner: Identity service owner
Required state: Final-domain cookie uses the documented Secure, HttpOnly, and SameSite policy
Evidence: Redacted Set-Cookie response captured from the identified release
Verification method: Fresh-browser login, inspect response, test intended same-site and cross-site flows
Verification result: Record actual observed attributes and flow outcomes
Source: MDN Set-Cookie
Source checked: 2026-07-19
Status: Do not mark until final-environment verification
Risk acceptance owner and expiry: Required for any documented exception
Specialist review required when: Federated, embedded, cross-site, or high-impact session design is involved
Recheck trigger: Identity, domain, proxy, cookie, or browser-flow changeExpected result: Every row can be traced from threat to owner, required state, redacted evidence, dated source, verification result, release status, escalation boundary, and recheck trigger.
Verify it: Choose three rows at random and ask a reviewer to reproduce the decision without verbal context. Return any ambiguous or unsupported row to blocked.
STEP 02
Model assets, trust boundaries, threats, and mitigations
Review what can go wrong in the actual system before selecting generic controls.
Owner: system architect with product and security reviewers. Evidence: current data-flow diagram, asset classification, trust boundaries, threats, likelihood and impact rationale, selected mitigations, residual risk, and review notes. Verification: trace every public and privileged entry point to data stores and external services. Escalate high-impact or unfamiliar designs.
Decompose the application, identify and rank threats, choose mitigations, then review and validate the model. Revisit it when architecture, data, privilege, or provider boundaries change. Source: OWASP Threat Modeling Cheat Sheet (checked 2026-07-19).
Expected result: The checklist is scoped to named assets, flows, actors, entry points, trust boundaries, threats, mitigations, residual risks, and review triggers.
Verify it: Pick one sensitive record and one privileged action, then follow input, identity, authorization, storage, logging, provider, response, and recovery paths end to end.
STEP 03
Verify authentication and the full session lifecycle
Separate proof of identity from session creation, use, rotation, expiry, revocation, and sensitive reauthentication.
Owner: identity service owner. Evidence: sign-up and recovery policy, authenticator configuration, session diagram, cookie attributes, expiry and revocation behavior, sensitive-action reauthentication, and redacted final-environment responses. Verification: test login, recovery, fixation resistance, logout, expiry, role change, removal, and password or authenticator change.
Authentication should use appropriate controls for the risk, while session identifiers bind authenticated traffic to access control and need protected creation, renewal, and destruction. Source: OWASP Authentication Cheat Sheet (checked 2026-07-19).
Treat session creation, exchange, renewal, expiry, revocation, fixation resistance, and lifecycle monitoring as their own security boundary between authentication and access control. Source: OWASP Session Management Cheat Sheet (checked 2026-07-19).
Verify the real Set-Cookie response and intended browser flow; cookie prefixes and Secure, HttpOnly, SameSite, Domain, Path, and expiry attributes have distinct behavior. Source: MDN Set-Cookie reference (checked 2026-07-19).
Expected result: Only intended users establish sessions, sensitive transitions re-check identity as required, and logout, expiry, recovery, removal, and privilege changes have documented effects on existing sessions.
Verify it: Capture redacted final-domain session responses, then replay protected actions before and after rotation, logout, expiry, recovery, role downgrade, and membership removal.
STEP 04
Enforce authorization and tenant boundaries on the server
Treat object IDs, tenant IDs, roles, and hidden buttons from the browser as untrusted input.
Owner: each protected service owner. Evidence: action matrix, centralized authorization policy, tenant-scoped queries, cache and job scope, export rules, and cross-account test results. Verification: test list, detail, mutation, file, search, export, job, and operator routes as signed out, wrong role, and the other tenant. Escalate unusual delegation or support impersonation.
Apply least privilege, deny by default, validate permissions on every request, and test access-control logic. Attribute and relationship checks may be more expressive than a role alone. Source: OWASP Authorization Cheat Sheet (checked 2026-07-19).
Keep tenant context server-derived and propagate it through queries, caches, storage, logs, jobs, and administration; tenant isolation needs defense in depth and cross-tenant tests. Source: OWASP Multi-Tenant Security Cheat Sheet (checked 2026-07-19).
Expected result: Every protected operation derives identity, tenant, record, relationship, and allowed action from server state before returning private data or changing state.
Verify it: Create the same known record ID in two fictional tenants and repeat raw list, detail, update, action, file, search, and export requests from both ordinary accounts.
STEP 05
Validate input and encode output for its destination
Constrain meaning at the trusted boundary and encode untrusted data for the actual HTML, attribute, URL, JavaScript, CSS, command, or query context.
Owner: endpoint or renderer owner. Evidence: server schemas, length and size limits, allowlists where applicable, parameterized database operations, safe templating, sanitization decision for rich content, and negative tests. Verification: submit malformed, oversized, boundary, encoded, and context-switching inputs. Escalate rich HTML, templates, code execution, or unusual interpreters.
Validate syntactic and semantic input on the server as early as practical, while recognizing that validation alone does not prevent every injection flaw. Source: OWASP Input Validation Cheat Sheet (checked 2026-07-19).
Use context-appropriate output encoding and safe sinks; HTML sanitization is a separate decision for intentionally authored rich content. Source: OWASP Cross Site Scripting Prevention Cheat Sheet (checked 2026-07-19).
Expected result: Invalid or unsafe values fail with bounded errors, valid values preserve intended meaning, and stored or reflected untrusted data cannot switch into an executable context through the tested paths.
Verify it: Replay the negative corpus through APIs, rendered pages, exports, notifications, logs, and background jobs, then inspect raw responses and final stored values.
STEP 06
Inventory, restrict, rotate, and redact secrets
Make secret ownership and revocation testable instead of relying on “not in source code.”
Owner: service owner plus platform owner. Evidence: secret inventory by environment, issuing system, minimum scope, storage location, consumers, rotation procedure, last rotation, revocation path, and leak response. Verification: scan source and build artifacts, inspect runtime injection, rotate one fictional or staging secret, and confirm the previous value fails. Escalate shared, long-lived, production-wide, or unowned credentials.
Centralize lifecycle management, apply least privilege, automate rotation where appropriate, restrict access, audit use, and prepare compromise response. Source: OWASP Secrets Management Cheat Sheet (checked 2026-07-19).
Expected result: Every credential has an issuer, owner, environment, scope, approved storage location, consumers, rotation and revocation process, and redaction rule.
Verify it: Choose one non-production credential, create a replacement, update only the intended consumer, verify a redacted request, revoke the old value, and confirm monitoring distinguishes the change.
STEP 07
Control dependencies, build inputs, and release provenance
Review the path from source and package metadata to the exact artifact deployed.
Owner: build and release owner. Evidence: locked dependencies, trusted registries, review and update policy, vulnerability triage, protected build identity, artifact digest, release provenance, and rollback artifact. Verification: reproduce the identified build, compare the deployed digest, and exercise one dependency alert. Escalate abandoned critical components or unclear artifact origin.
Treat source, dependencies, build infrastructure, package repositories, artifacts, and deployment as one software supply-chain boundary with integrity and access controls. Source: OWASP Software Supply Chain Security Cheat Sheet (checked 2026-07-19).
Expected result: The team can identify what source and dependencies produced the deployed artifact, who or what authorized it, which findings were addressed or accepted, and how to return to a known release.
Verify it: Build from the locked inputs in a clean environment, record the artifact identifier, compare it with deployment evidence, and trace one vulnerable or retired dependency through triage and release decision.
STEP 08
Constrain file uploads from request to retrieval
Treat filename, extension, declared type, content, parser, storage, preview, and download as separate attack surfaces.
Owner: upload feature owner. Evidence: extension and type allowlist, size and count limits, generated storage names, isolated storage, parser and scanning policy, authorization on retrieval, response headers, retention, deletion, and abuse limits. Verification: test mismatched types, double extensions, oversized and compressed inputs, malicious fixtures under approval, and cross-tenant retrieval. Escalate executable, archive, document-macro, or public-hosting requirements.
Allow only business-required extensions, do not trust Content-Type alone, change stored filenames, apply size limits, store outside the web root where possible, protect retrieval, and consider scanning or content reconstruction. Source: OWASP File Upload Cheat Sheet (checked 2026-07-19).
Expected result: Only approved content reaches isolated storage under generated identifiers, and every preview, transformation, download, retention, and deletion path preserves authorization and bounded resource use.
Verify it: Upload the approved negative corpus, inspect stored names and parser results, request each object as signed out and the other tenant, then delete it and verify derived copies follow policy.
STEP 09
Restrict server-side outbound requests and SSRF paths
Do not let a user-controlled URL become unrestricted access from a trusted network position.
Owner: integration or fetch-service owner. Evidence: allowed destinations and schemes, canonical parsing, DNS and redirect policy, blocked private and metadata ranges, egress controls, response size and timeout limits, and monitoring. Verification: test alternative IP representations, DNS changes, redirects, credentials in URLs, internal ranges, and oversized or slow responses. Escalate arbitrary URL fetchers and cloud metadata reachability.
Prefer allowlisted destinations when the business flow supports them; validate and constrain host, address, scheme, redirects, network reachability, and response handling rather than relying on a single string check. Source: OWASP Server Side Request Forgery Prevention Cheat Sheet (checked 2026-07-19).
Expected result: Outbound requests reach only intended destinations through bounded protocols and resources, with internal, metadata, redirect, parsing, and DNS-rebinding cases addressed by layered controls.
Verify it: Run the approved SSRF fixture set through every URL, webhook, import, preview, image, document, and integration path while observing egress logs and bounded failures.
STEP 10
Set CSRF, CORS, and CSP from the real browser flows
Configure three different browser boundaries without treating one as a substitute for another.
Owner: web platform owner. Evidence: state-changing request model, CSRF defense, exact CORS origin and credential policy, CSP header and violation rollout, cookie policy, framing decision, and browser tests. Verification: test same-site, cross-site, credentialed, preflight, embedded, and script-injection cases. Escalate broad cross-origin credentials, embedded apps, third-party script sprawl, or legacy inline execution.
Use framework protections or synchronizer or signed double-submit tokens as appropriate, combine with SameSite and origin verification, and never use GET for state changes. Source: OWASP Cross-Site Request Forgery Prevention Cheat Sheet (checked 2026-07-19).
CORS is an HTTP-header protocol for permitting selected cross-origin reads; credentialed requests require explicit origins and matching browser behavior. Source: MDN Cross-Origin Resource Sharing guide (checked 2026-07-19).
CSP constrains resource loading and script execution through a policy delivered by HTTP headers; roll out and test a policy suited to the actual application. Source: W3C Content Security Policy Level 3 (checked 2026-07-19).
Expected result: State changes resist cross-site request abuse, only documented origins receive permitted cross-origin responses, and the deployed CSP reduces unintended execution without breaking required flows.
Verify it: Exercise authenticated state changes from allowed and unallowed origins, inspect preflights and credentials, then review CSP enforcement and reports for every required script, worker, frame, connection, image, and style source.
STEP 11
Design security logging with privacy boundaries
Capture enough bounded evidence to investigate decisions without creating a second sensitive-data store.
Owner: service and observability owners with privacy review. Evidence: event taxonomy, stable request and actor references, authorization and state-change results, retention and access policy, redaction tests, time synchronization, integrity controls, alert mappings, and deletion requirements. Verification: trigger allowed, denied, invalid, duplicate, provider-failure, and operator events, then inspect raw stored fields. Escalate sensitive or regulated data in telemetry.
Log security-relevant successes and failures consistently, protect logs from tampering and unauthorized access, avoid secrets and unnecessary sensitive data, and make events useful for detection and investigation. Source: OWASP Logging Cheat Sheet (checked 2026-07-19).
Expected result: Investigators can correlate important decisions and failures with bounded identifiers, while passwords, sessions, tokens, keys, payment payloads, private content, and unnecessary personal data stay out of routine logs.
Verify it: Run one case from each event category, query by the saved bounded IDs, inspect access and retention behavior, and fail the row if a secret or unnecessary payload appears.
STEP 12
Bound rates, resources, retries, and abuse decisions
Protect expensive and sensitive operations at the identity, tenant, destination, and system levels.
Owner: feature owner plus platform reliability owner. Evidence: per-operation cost model, identity and tenant quotas, global limits, request and response size limits, timeouts, concurrency controls, backoff, circuit behavior, queue capacity, abuse response, and user recovery. Verification: burst, sustained, distributed, duplicate, slow, and large-input tests. Escalate financially expensive or public anonymous workloads.
Availability controls need defense in depth across application, server, and infrastructure layers; limits should protect resources without creating simple lockout abuse against legitimate users. Source: OWASP Denial of Service Cheat Sheet (checked 2026-07-19).
Expected result: Costly and state-changing operations have documented budgets and bounded failure behavior, technical retries do not duplicate durable effects, and operators can distinguish legitimate load from abuse.
Verify it: Run approved load and abuse fixtures in a safe environment, inspect resource use and durable record counts, then prove limits recover without manual database repair.
STEP 13
Exercise security tests and route exceptions to specialists
Turn each required state into a reproducible check and stop where specialist judgment or authorization is required.
Owner: control owner for fixes, independent reviewer for evidence, release owner for risk decisions. Evidence: unit, integration, browser, dependency, configuration, negative, cross-tenant, production-smoke, and recovery results linked to the release. Verification: reproduce findings after fixes and record residual risk. Escalate high-impact findings, unfamiliar exploit classes, cryptography, regulated data, or testing that could affect users or systems.
Use a defined verification standard as a coverage basis and record the version and requirement identifiers selected for the actual application. Coverage and evidence do not remove the need for risk analysis or expert testing. Source: OWASP ASVS project (checked 2026-07-19).
A structured web security testing guide can help plan technical tests, but testing must have explicit authorization, scope, environment, data handling, and stop conditions. Source: OWASP Web Security Testing Guide project (checked 2026-07-19).
Expected result: Applicable controls have reproducible release-linked results, failures have owners, exceptions have named acceptance and expiry, and specialist review is requested where the team cannot responsibly verify the risk.
Verify it: Select one pass, one fail, one not-applicable row, and one accepted risk. Reproduce the evidence and verify that applicability, owner, expiry, escalation, and release effect are explicit.
STEP 14
Verify the identified deployment, TLS, headers, and rollback
Check the final public environment and exact release rather than assuming local or preview evidence carries over.
Owner: release and platform owners. Evidence: artifact ID, environment configuration review, migration record, certificate and HTTPS behavior, final response headers, cookie attributes, DNS and proxy boundary, previous release, rollback trigger, and smoke results. Verification: fresh browser and direct HTTP checks against the final domain. Escalate HSTS preload, broad subdomain policy, cryptographic changes, or rollback that can lose data.
Use HTTPS and review security headers for the application’s actual behavior. Header recommendations require context and final-environment verification. Source: OWASP HTTP Headers Cheat Sheet (checked 2026-07-19).
HSTS tells browsers to use HTTPS for future requests, but includeSubDomains and preload have wider and longer-lived consequences that require complete coverage and careful rollout. Source: MDN Strict-Transport-Security reference (checked 2026-07-19).
Expected result: The final domain serves the identified artifact over intended HTTPS behavior with reviewed headers, environment separation, migrations, smoke evidence, a known previous release, and a risk-appropriate rollback plan.
Verify it: From a fresh browser and direct client, inspect redirects, certificate, headers, cookies, assets, API behavior, cross-origin flows, one allowed action, one denial, monitoring, and rollback readiness.
STEP 15
Prove backup, restore, monitoring, and incident response
Backups are only evidence after a bounded restore succeeds, and alerts are only useful when an owner can act.
Owner: data and incident owners. Evidence: backup scope and encryption, retention, restore objective, isolated restore result, integrity checks, alert inventory, escalation contacts, containment and credential-revocation procedures, evidence handling, customer and legal decision owners, and post-incident actions. Verification: rehearse one record or tenant recovery plus one tabletop incident. Escalate regulated data, breach notification, destructive containment, cryptographic loss, or unclear legal duties.
Protect sensitive data with a documented cryptographic architecture, key lifecycle, access boundary, and recovery plan; encryption does not replace access control or integrity checks. Source: OWASP Cryptographic Storage Cheat Sheet (checked 2026-07-19).
Protect backups, restrict access, separate them from the live database where appropriate, and regularly exercise restore rather than treating backup creation as recovery evidence. Source: OWASP Database Security Cheat Sheet (checked 2026-07-19).
Security logs should support detection, alerting, investigation, and response while preserving confidentiality, integrity, availability, retention, and access controls. Source: OWASP Logging Cheat Sheet (checked 2026-07-19).
Publish a safe vulnerability-reporting channel and triage process as one input to response; a reporting address alone is not an incident-response program. Source: OWASP Vulnerability Disclosure Cheat Sheet (checked 2026-07-19).
Expected result: A named operator can detect a bounded scenario, preserve evidence, contain it, revoke affected access, restore the required scope, communicate through approved owners, and record follow-up work.
Verify it: Restore a fictional record set into an isolated environment, compare counts and authorization, then run a tabletop from alert to triage, containment, recovery, communication decision, and retrospective owner.
Minimum web app security test matrix
Run these against an identified release with fictional accounts and bounded evidence. Passing them does not prove the absence of vulnerabilities; it proves only the documented cases under the tested conditions.
| Test | Scenario | Expected result |
|---|---|---|
| happy path | Sign in as an ordinary member of tenant A, create one fictional record, read and update only allowed fields, complete one sensitive action with the required confirmation, export the allowed scope, and sign out. | Authentication, session, authorization, validation, durable state, logging, export, and logout match the documented policy with no unnecessary sensitive data in evidence. |
| invalid input | Repeat list, detail, update, file, export, URL-fetch, and state-changing requests signed out, as the wrong role, and from tenant B using malformed, oversized, context-switching, cross-site, and disallowed-origin inputs. | Requests fail closed with bounded responses, no cross-tenant data or internal fetch result is exposed, no forbidden state changes, and logs contain safe diagnostic identifiers. |
| retry | Repeat one state-changing request, interrupt its response, replay it after session rotation, retry one external call, and exercise rate-limit recovery without changing the intended operation. | Technical retries do not duplicate durable effects, stale or changed intent is rejected, session policy remains enforced, backoff is bounded, and the result is diagnosable. |
| production smoke | On the final HTTPS domain, verify artifact identity, redirects, certificate, cookies, headers, CSP, CORS, one allowed tenant action, one cross-tenant denial, upload or outbound-request boundaries if present, alert delivery, and cleanup. | The deployed environment matches the reviewed configuration and security evidence, while exceptions remain blocked or explicitly accepted by the named owner with an expiry. |
Security-checklist failures and exact diagnostics
A missing owner, evidence link, result, or recheck trigger is a blocked control, not a pass. Diagnose the system boundary before adding a generic header or library.
| Symptom | Likely cause | Check | Fix |
|---|---|---|---|
| Every row is marked pass but no result can be reproduced | The checklist records intentions or framework defaults instead of release-linked code, configuration, runtime, and test evidence. | Choose three rows and ask an independent reviewer to identify the release, evidence, command or procedure, observed result, and applicability decision. | Return unsupported rows to blocked, assign owners, capture redacted evidence from the identified artifact and environment, and record the result and recheck trigger. |
| A user can access another tenant’s known record ID | A list, detail, mutation, file, job, cache, search, or export path queried globally or trusted a browser-supplied tenant or role. | Replay the raw request as the other ordinary tenant and inspect server-derived identity, tenant, relationship, action, query scope, cache key, and response. | Centralize deny-by-default authorization, include tenant and allowed action in every private boundary, and keep cross-tenant regression fixtures for all route types. |
| A browser control breaks the app or still allows an unintended flow | CSRF, CORS, CSP, cookies, framing, or headers were copied as a generic preset without modeling the real same-site, cross-site, embedded, API, and third-party flows. | Trace the failing browser request, origin, credentials, preflight, cookie attributes, CSP directive and report, redirect, and final response headers. | Document the intended browser flow, choose the smallest exact origins and directives, deploy in a controlled rollout, and retest allowed plus denied cases. |
| A dependency alert exists but no release decision follows | The inventory has no owner, exploitability or exposure review, upgrade path, compensating control, acceptance expiry, or deployed-artifact link. | Map the finding to the locked dependency, call path, runtime exposure, deployed artifact, available fix, and owner before assigning severity by package name alone. | Patch or replace when practical, otherwise record scoped mitigations, named risk acceptance and expiry, monitoring, and a scheduled recheck. |
| A backup exists but the app cannot recover the required scope | Backup creation was monitored, but restore permissions, keys, dependencies, ordering, integrity, authorization, and post-restore reconciliation were never exercised. | Restore a fictional bounded dataset in isolation and compare schema, counts, versions, relationships, access rules, secrets or keys, and dependent services. | Repair the restore runbook and dependencies, repeat the isolated restore, record time and integrity evidence, and keep narrower record or tenant recovery separate from full rollback. |
| An alert fires but nobody can contain or explain the event | Monitoring has no decision owner, stable identifiers, severity mapping, current contact path, containment permissions, evidence rules, or practiced recovery procedure. | Run a tabletop from one synthetic alert and record every handoff, missing permission, unavailable identifier, unsafe log field, and delayed decision. | Assign incident roles, add bounded evidence and escalation paths, pre-authorize safe containment, protect investigation data, and rehearse again with a timed outcome. |
Keep security evidence current after release
Deploy
Tie every result to the source revision, dependency lock, artifact or release ID, environment, configuration, migration, final domain, review date, and named decision owner.
Deploy progressively according to risk, verify HTTPS, headers, cookies, browser policies, tenant isolation, external boundaries, alerts, and rollback on the final environment before broader exposure.
Do not release a failed or blocked high-impact control by relabeling it not applicable. Record the actual residual risk, acceptance owner, expiry, compensating controls, monitoring, and specialist input.
Monitor
Monitor authentication and recovery anomalies, denied access, cross-tenant probes, validation failures, upload and outbound-request denials, secret and dependency events, abuse limits, privileged changes, deployment drift, backup failures, and alert-delivery health.
Use bounded request, actor, tenant, record, release, event, and incident identifiers. Exclude passwords, session values, tokens, keys, raw payment or provider payloads, private content, and unnecessary personal data from routine logs.
Reopen affected rows when code, configuration, identity, domain, certificate, proxy, dependency, provider, data classification, permission, browser flow, threat intelligence, or incident evidence changes.
Recover
Maintain separate procedures for session revocation, credential rotation, one-record repair, one-tenant restore, dependency rollback, release rollback, provider reconciliation, and whole-system restore.
Preserve approved investigation evidence with access, integrity, retention, and privacy controls. Route breach, notification, legal, and customer-communication decisions to named qualified owners.
After an incident or near miss, update the threat model, affected control rows, tests, monitoring, runbooks, owners, and recheck triggers rather than closing only the visible symptom.
What this checklist can and cannot establish
This is an engineering evidence framework. It helps a team make scoped controls and release decisions reviewable; it cannot establish complete security, legal or regulatory compliance, certification, or the absence of vulnerabilities.
- Use the actual application, artifact, environment, data, identities, providers, threats, and business impact to select controls and testing depth. A copied checklist is not a threat model.
- Keep evidence redacted and access controlled. Do not paste credentials, session values, personal data, private code, raw provider payloads, exploit details, or customer records into public issues or screenshots.
- Require specialist security review for high-impact or unfamiliar architecture, cryptography, identity federation, complex tenancy, arbitrary file or URL processing, third-party scripts, exposed administration, or serious findings.
- Require separate privacy, legal, and compliance review for personal, regulated, contractual, cross-border, payment, medical, financial, employment, child, or other sensitive data and obligations.
- Authorize testing explicitly. Define targets, environment, accounts, data, tools, traffic limits, times, contacts, stop conditions, evidence handling, and cleanup before active or production testing.
- Record residual risk honestly. A blocked control stays blocked; an accepted risk needs a named accountable owner, rationale, expiry, monitoring, and recheck trigger.
Questions about web app security checklists
Does completing this checklist make a web app secure?
No. It makes a defined set of controls, evidence, tests, exceptions, and owners reviewable for an identified release. Unknown threats, implementation defects, configuration drift, provider failures, human error, and untested conditions can remain. Use risk-based specialist review and continuous rechecking for the real system.
Does an OWASP ASVS mapping prove compliance or certification?
No. ASVS provides a basis for defining and testing technical security requirements. A useful mapping records the ASVS version, applicable requirement, evidence, test, result, and reviewer. Compliance and certification depend on separate scope, obligations, assessor rules, operational practices, and evidence beyond a checklist.
When should a team hire a security specialist or penetration tester?
Escalate when the app handles high-impact data or actions, complex identity or tenancy, cryptography, payments, arbitrary files or URLs, exposed administration, unusual infrastructure, serious findings, or risks the team cannot independently verify. Testing needs explicit authorization, scope, stop conditions, and evidence rules.
What should a small app review first?
Start with assets and trust boundaries, server authentication and authorization, cross-account denial, validation and encoding, secret storage, dependency and artifact identity, HTTPS and session cookies, safe logs, abuse limits, backup restore, monitoring, and a named incident owner. Add depth based on actual risk.
How do I test tenant isolation?
Create the same known record ID in two fictional tenants. Repeat raw list, detail, update, action, file, search, job, cache, export, and recovery requests as both ordinary accounts, signed out, and with the wrong role. Verify the server scopes before returning data, not after a global lookup.
Should secrets ever appear in checklist evidence?
No. Evidence can identify the issuer, owner, environment, purpose, scope, storage boundary, consumer, rotation date, and a redacted success or revocation result. Never store the credential value, session token, signing secret, private key, or sensitive provider payload in the checklist.
Is Content Security Policy enough to prevent XSS?
No. CSP is a defense-in-depth browser policy. The application still needs safe templating, context-appropriate output encoding, safe sinks, deliberate sanitization for permitted rich HTML, dependency control, and tests. A copied policy can break required flows while leaving unsafe execution paths available.
How should AI-generated code change the security review?
Review generated code with the same or greater evidence requirements as other code. Verify identity, authorization, input and output handling, secret boundaries, dependencies, provider calls, tests, deployment configuration, monitoring, and recovery against the real artifact. Do not treat generation speed as security evidence.
How often should the checklist be refreshed?
Recheck affected rows for every relevant release and whenever architecture, data, identity, permissions, domain, proxy, dependency, provider, browser flow, certificate, threat intelligence, incident evidence, or legal obligation changes. Give accepted risks and temporary exceptions explicit expiry dates.
Build with the evidence fields visible
Turn one reviewed web app workflow into editable code
Describe the records, roles, tenant boundaries, input rules, provider edges, tests, deployment, monitoring, and recovery. Use this checklist to review the generated application and its final environment.
Build an App with PlaycodePlaycode does not replace your security, privacy, legal, compliance, or penetration-testing review for the real application.