Security Design Review: [System or feature name]

Security design review for a web application, API or feature, organised by the seventeen verification chapters of the OWASP Application Security Verification Standard (ASVS) version 5.0.0 (released May 2025): scope and assets, data flows, trust boundaries, threats, the ASVS level targeted, a per-chapter review with status and findings, a findings register, a remediation plan and sign-off. Replace every [bracketed] value and every value marked Example. The worked examples describe a fictional expense-claims web app with a mobile client.

Document control

Approvals

Revision history

Contents

1. Introduction
2. Scope and assets
3. Data flow diagram
4. Trust boundaries
5. Threat summary
6. ASVS level targeted
7. Per-chapter review
8. Findings register
9. Remediation plan
10. Residual risk and decision
11. Sign-off
12. Appendices

1. Introduction

This section states the purpose, method and inputs of the review so that readers understand its limits before they read the conclusions.

1.1 Purpose

This review assesses whether the design of [System name] provides security controls appropriate to the data it handles and the threats it faces, before [build / release / a major change]. It produces a list of findings with severities and an agreed remediation plan.

1.2 Review approach

The review combined [design document reading, architecture walkthrough with the team, threat modelling with STRIDE, and configuration inspection]. Each ASVS 5.0.0 chapter was assessed against the targeted level in section 6. ASVS 5.0 places documentation requirements at the start of most chapters (for example V8.1 Authorization Documentation), so missing design documentation is itself recorded as a finding. No penetration testing was performed; that is planned for [YYYY-MM-DD] and will be reported separately.

1.3 Inputs and references

1.4 Moving from ASVS 4.0.3

If earlier reviews used ASVS 4.0.3, do not reuse their requirement numbers. Version 5.0.0 reorganised the standard into seventeen chapters, moved threat modelling and secure development lifecycle topics out of scope, split authentication, tokens and OAuth into separate chapters, and added chapters on web frontend security and WebRTC. Map old findings to the new chapters using the OWASP mapping material and record the old ID in the finding description.

2. Scope and assets

Scope, assets and actors define what the review covers and whose interests the controls protect.

2.1 Scope

In scope:

• Example: Web front end (React single-page app), served from a CDN.
• Example: Claims API (Node.js) and its PostgreSQL database.
• Example: Receipt upload and storage in object storage.
• Example: Integration with the corporate identity provider (OIDC) and the payroll system (SFTP export).

Out of scope:

• Example: The identity provider itself, reviewed under [SDR-IDP-003].
• Example: Corporate laptops and mobile device management.
• Example: CI/CD pipeline hardening, covered by the supply chain security assessment [SCS-002]. ASVS 5.0 treats build and hosting as adjacent to, not part of, its scope.

2.2 Assets

2.3 Actors

3. Data flow diagram

The diagram shows the main components, the numbered data flows and the trust boundaries (grouped zones) used in the rest of this review.

4. Trust boundaries

Each boundary below lists the flows that cross it and the controls the review expects to find there.

5. Threat summary

Threats were identified with STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) per flow and boundary. Likelihood and impact are rated 1 to 5 and combined as $\text{Risk} = \text{Likelihood} \times \text{Impact}$, giving a score from 1 to 25.

6. ASVS level targeted

ASVS 5.0.0 defines three verification levels of increasing depth. Level 1 contains the most critical first-layer defences and is the place to start. Level 2 adds the requirements that most applications handling business or personal data should meet, and compliance with L2 means meeting all L1 and L2 requirements. Level 3 adds defence-in-depth requirements for the most critical applications, such as those moving money or holding health data. Organisations are encouraged to tailor the standard, omitting chapters that do not apply.

7. Per-chapter review

The summary table gives the result for each ASVS 5.0.0 chapter at the targeted level; the prompts in 7.2 guide the conversation per chapter.

7.1 Summary table

7.2 Review prompts per chapter

Use these prompts to guide the discussion for each chapter. They are paraphrased starting points, not a substitute for the ASVS requirements.

V1 Encoding and Sanitization (sections: architecture, injection prevention, sanitization, memory and unmanaged code, safe deserialization). Is output encoded for its interpreter at the point of use? Are queries parameterised? Is dynamic code execution avoided? Are untrusted serialised objects ever deserialised? Example reference: v5.0.0-1.2.1 (context-relevant output encoding, L1).

V2 Validation and Business Logic (documentation, input validation, business logic security, anti-automation). Is input validated against expected values and structures? Can workflow steps be skipped, repeated or reordered? Are limits enforced on high-value or high-frequency actions? Example: v5.0.0-2.3.1 (business flows processed in order, L1).

V3 Web Frontend Security (documentation, unintended content interpretation, cookie setup, browser security headers, origin separation, external resource integrity, other browser concerns). Are cookies prefixed and marked Secure? Are HSTS, CSP and related headers set? Are third-party scripts pinned with integrity checks? Example: v5.0.0-3.4.1 (HSTS on all responses, L1).

V4 API and Web Service (generic web service security, HTTP message structure validation, GraphQL, WebSocket). Does each response declare the correct content type? Are request smuggling and parser differences between proxies and servers prevented? Are GraphQL queries limited?

V5 File Handling (documentation, upload and content, storage, download). Are size, extension and content of uploads checked, including inside archives? Can stored files ever be executed by the server? Example: v5.0.0-5.2.1 (size limits, L1).

V6 Authentication (documentation, password security, general authentication, factor lifecycle and recovery, MFA, out-of-band, cryptographic authenticators, identity providers). Are brute force and credential stuffing controlled? Is MFA required where the level demands it? Is account recovery as strong as login?

V7 Session Management (documentation, fundamentals, timeout, termination, abuse defences, federated re-authentication). Are sessions verified by a trusted backend? Does logout make the session unusable? Are inactivity and absolute timeouts documented and enforced?

V8 Authorization (documentation, general design, operation level, other considerations). Is access checked for both the function and the specific data item? Is enforcement done in a trusted service layer? Example: v5.0.0-8.2.2 (data-specific access, mitigating IDOR and BOLA, L1).

V9 Self-contained Tokens (token source and integrity, token content). Is every token's signature or MAC validated before its contents are trusted? Are issuer, audience and validity period checked?

V10 OAuth and OIDC (generic, client, resource server, authorization server, OIDC client, OpenID provider, consent). Are tokens kept away from components that do not need them? Are redirect URIs matched exactly? Example: v5.0.0-10.4.1 (exact redirect URI allowlist, L1).

V11 Cryptography (inventory and documentation, implementation, encryption algorithms, hashing, random values, public key, in-use data). Is there a cryptographic inventory and key lifecycle policy? Are weak modes and paddings excluded? Example: v5.0.0-11.3.1 (no ECB or weak padding, L1).

V12 Secure Communication (general TLS, HTTPS to external services, service-to-service). Are only current TLS versions enabled? Do internal connections authenticate and encrypt as well as external ones?

V13 Configuration (documentation, backend communication, secret management, unintended information leakage). Are secrets in a vault with least-privilege access? Are debug endpoints, directory listings and version banners disabled? Example: v5.0.0-13.3.1 (secrets management solution, L2).

V14 Data Protection (documentation, general, client-side). Is sensitive data classified and kept out of URLs, caches and browser storage? Example: v5.0.0-14.2.1 (no sensitive data in URLs or query strings, L1).

V15 Secure Coding and Architecture (documentation, architecture and dependencies, defensive coding, safe concurrency). Are remediation time frames defined for vulnerable components and met? Are mass assignment and race conditions prevented? Example: v5.0.0-15.2.1 (components within documented remediation time frames, L1).

V16 Security Logging and Error Handling (documentation, general logging, security events, log protection, error handling). Are authentication and authorization events logged with enough context? Are logs protected from modification? Do errors return generic messages? Example: v5.0.0-16.3.1 (authentication events logged, L2).

V17 WebRTC (TURN server, media, signaling). If the system carries real-time media, are TURN servers restricted, media encrypted and signaling protected against flooding? Mark the chapter not applicable otherwise.

8. Findings register

Findings are numbered SR-NNN and keep their number when closed.

9. Remediation plan

Remediation targets by severity: Critical before release, High within [30 days] or before release if exploitable from the internet, Medium within [90 days], Low at the team's discretion with a ticket.

The timeline below shows the plan against the release date.

10. Residual risk and decision

Overall result: [Approved / Approved with conditions / Rejected].

Example: The design is approved with conditions. SR-001 and SR-002 must be fixed and retested before go-live. SR-004 is accepted until YYYY-MM-DD because backups are already encrypted and access to them is limited to two administrators.

11. Sign-off

By signing, each party confirms they have read the findings, agree with the remediation plan and, where applicable, accept the residual risk described in section 10.

12. Appendices

The appendices hold the glossary, the severity scale and the references used throughout the review.

12.1 Glossary

12.2 Severity scale

Severity is assigned from the risk score in section 5 and adjusted with a written reason when exploitability or exposure differs from the threat estimate.

12.3 References

Standard and licence note

Based on the OWASP Application Security Verification Standard version 5.0.0 (May 2025) by the OWASP Foundation, licensed under Creative Commons Attribution-ShareAlike 4.0 (https://creativecommons.org/licenses/by-sa/4.0/). This template uses the titles of the seventeen ASVS 5.0.0 chapters (V1 Encoding and Sanitization to V17 WebRTC), their section names, the three-level model and the v5.0.0-<chapter>.<section>.<requirement> reference format; the review prompts are original paraphrases and no requirement text is reproduced. Obtain the ASVS from owasp.org or the OWASP ASVS GitHub repository for the normative requirements. As an adaptation of an OWASP structure, this template is shared under CC BY-SA 4.0. Structure aligned with OWASP ASVS 5.0.0 for the per-chapter review; STRIDE is used as a general threat-modelling practice.