# 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.

<!--
Guidance: How to use this template
- Run the review at design time, before the main build, and again before
  release. A design review that happens after launch is an audit.
- Fill sections 2 to 6 with the engineering team first. The per-chapter
  review in section 7 is only as good as the data flow diagram it is based on.
- Use the ASVS 5.0.0 document itself as the checklist for section 7. This
  template names the chapters and sections and gives prompts in its own
  words; it does not reproduce the requirements, so keep the standard open.
- Cite requirements in the version-pinned form ASVS recommends,
  `v5.0.0-<chapter>.<section>.<requirement>` (for example `v5.0.0-8.2.2`),
  because numbers changed completely between 4.0 and 5.0.
- Every "Partial" or "Not met" status needs a finding ID in section 8, and
  every finding needs an owner and a date in section 9.
-->

## Document control

<!-- Guidance: A security review is evidence for auditors and for the go-live decision. Record exactly which design version was reviewed and which ASVS version was used. -->

| Field | Value |
|---|---|
| Document ID | [SDR-EXPENSES-001] |
| System / feature | [Expense claims web app and API] |
| Design version reviewed | [Design doc v1.2, commit `a1b2c3d`] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Approved with conditions / Rejected] |
| Review lead | [@security-engineer] |
| Engineering owner | [@tech-lead] |
| Review dates | YYYY-MM-DD to YYYY-MM-DD |
| ASVS version | 5.0.0 |
| Classification | [Internal / Confidential] |
| Next review due | YYYY-MM-DD or at next major design change |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Security review lead | [@name] | [Approved / Approved with conditions / Rejected] | YYYY-MM-DD |
| Engineering owner | [@name] | [Accepted findings and plan] | YYYY-MM-DD |
| Product owner | [@name] | [Accepted residual risk] | YYYY-MM-DD |
| CISO or delegate | [@name] | [Required for High residual risk] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record changes in findings and status, not wording edits. -->

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Scope, assets and data flow diagram |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Per-chapter review complete, 9 findings raised |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved with conditions SR-001 and SR-002 |

## Contents

<!-- Guidance: Keep aligned with the headings below. -->

1. [Introduction](#1-introduction)
2. [Scope and assets](#2-scope-and-assets)
3. [Data flow diagram](#3-data-flow-diagram)
4. [Trust boundaries](#4-trust-boundaries)
5. [Threat summary](#5-threat-summary)
6. [ASVS level targeted](#6-asvs-level-targeted)
7. [Per-chapter review](#7-per-chapter-review)
8. [Findings register](#8-findings-register)
9. [Remediation plan](#9-remediation-plan)
10. [Residual risk and decision](#10-residual-risk-and-decision)
11. [Sign-off](#11-sign-off)
12. [Appendices](#12-appendices)

## 1. Introduction

<!-- Guidance: Why the review is happening, what was examined and how. Readers should know the limits of the review before reading its conclusions. -->

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

| Input | Version / link |
|---|---|
| Design document | [link, version] |
| Architecture description | [link] |
| Existing threat model | [link or "none"] |
| Data classification policy | [link] |
| OWASP ASVS | 5.0.0 (May 2025) |
| Organisation's tailored ASVS profile | [link or "none, full standard used"] |
| Previous security reviews | [link or "none"; note if they used ASVS 4.0.3] |

### 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

<!-- Guidance: Name what is in and out of scope as concretely as possible: components, environments, integrations. Then list the assets an attacker would want, with their classification. -->

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

| ID | Asset | Classification | Why it matters |
|---|---|---|---|
| A-01 | Expense claims and amounts | Confidential | Fraud and financial loss if altered |
| A-02 | Receipt images | Confidential, may contain personal data | Privacy breach, card numbers on receipts |
| A-03 | Employee bank details | Restricted | Payment redirection fraud |
| A-04 | Approver decisions and audit log | Confidential, integrity critical | Non-repudiation of approvals |
| A-05 | API signing keys and database credentials | Secret | Full compromise |
| [A-nn] | [Asset] | [Class] | [Impact] |

### 2.3 Actors

| Actor | Trust level | Access |
|---|---|---|
| Employee | Authenticated, low privilege | Own claims only |
| Approver | Authenticated, elevated | Claims of direct reports |
| Finance administrator | Authenticated, high privilege | All claims, payroll export |
| Payroll system | Machine identity | Receives daily export |
| Anonymous internet user | Untrusted | Login page and public assets only |

## 3. Data flow diagram

<!-- Guidance: Draw processes, data stores, external entities and flows, and mark trust boundaries. Number the flows so threats and findings can refer to them. -->

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

```mermaid
flowchart LR
  subgraph Internet
    U["Employee browser"]
  end
  subgraph Cloud["Cloud account (trusted zone)"]
    API["Claims API"]
    DB[("PostgreSQL")]
    OBJ[("Receipt storage")]
  end
  CDN["CDN (static app)"]
  IDP["Identity provider"]
  PAY["Payroll system"]
  U -->|"F1 HTTPS"| CDN
  U -->|"F2 HTTPS + bearer token"| API
  U -->|"F3 OIDC login"| IDP
  API -->|"F4 TLS SQL"| DB
  API -->|"F5 pre-signed URL"| OBJ
  U -->|"F6 upload via pre-signed URL"| OBJ
  API -->|"F7 SFTP nightly export"| PAY
```

| Flow | From | To | Data | Protection |
|---|---|---|---|---|
| F2 | Browser | Claims API | Claims, amounts, bank details | TLS 1.2+, OIDC access token |
| F6 | Browser | Receipt storage | Receipt images | TLS, pre-signed URL valid 5 minutes, size limit |
| F7 | Claims API | Payroll | Approved payments | SFTP with key authentication, file signed |
| [Fn] | [Source] | [Destination] | [Data] | [Controls] |

## 4. Trust boundaries

<!-- Guidance: Every place where data or control crosses from a less trusted to a more trusted zone. Most serious findings sit on a boundary. -->

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

| ID | Boundary | Crossing flows | Controls expected at the boundary | ASVS chapters |
|---|---|---|---|---|
| TB-1 | Internet to cloud API | F2, F6 | Authentication, authorization per object, input validation, rate limiting | V2, V4, V6, V8 |
| TB-2 | API to database | F4 | Least-privilege database role, parameterised queries | V1, V13 |
| TB-3 | Cloud to payroll network | F7 | Mutual authentication, integrity of export file, allow-listed source | V12, V11 |
| TB-4 | Identity provider to API | F3 | Token signature, issuer and audience validation | V9, V10 |
| [TB-n] | [Boundary] | [Flows] | [Controls] | [Vn] |

## 5. Threat summary

<!-- Guidance: A short list of the threats that matter most, from a STRIDE or similar pass over the diagram. ASVS 5.0 no longer contains a threat modelling chapter, so link the detailed threat model rather than expecting the checklist to cover it. -->

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.

| ID | Threat | STRIDE | Flow / boundary | L | I | Risk | Related chapter |
|---|---|---|---|---|---|---|---|
| T-01 | Employee reads or edits another employee's claim by changing the claim ID | E, I | F2 / TB-1 | 4 | 4 | 16 | V8 Authorization |
| T-02 | Malicious file uploaded as a receipt and later opened by finance | T | F6 | 3 | 4 | 12 | V5 File Handling |
| T-03 | Approver denies having approved a fraudulent claim | R | F2 | 2 | 4 | 8 | V16 Security Logging and Error Handling |
| T-04 | Payroll export altered in transit to redirect payments | T | F7 / TB-3 | 2 | 5 | 10 | V12 Secure Communication |
| T-05 | Credential stuffing against the login flow | S | F3 | 3 | 3 | 9 | V6 Authentication |
| T-06 | Forged or replayed access token accepted by the API | S, E | F2 / TB-4 | 2 | 5 | 10 | V9 Self-contained Tokens |
| [T-nn] | [Threat] | [Letter] | [Flow] | [1-5] | [1-5] | [score] | [Chapter] |

## 6. ASVS level targeted

<!-- Guidance: Choose L1, L2 or L3 and justify it from the asset classification. In 5.0 the levels are priority-based: L1 holds the first-layer defences, L2 adds the bulk of requirements most applications should meet, L3 adds defence in depth for the most critical systems. -->

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.

| Item | Value |
|---|---|
| Target level | [L2] |
| Rationale | *Example:* Handles bank details and personal data (A-02, A-03) and triggers payments; a breach has financial and regulatory impact. |
| Chapters raised to L3 | *Example:* V11 Cryptography for bank details; V16 for audit logging of approvals |
| Chapters not applicable | *Example:* V17 WebRTC (no real-time media); V4.3 GraphQL and V4.4 WebSocket (not used) |
| ASVS version used | 5.0.0 |

## 7. Per-chapter review

<!-- Guidance: One row per ASVS chapter. Status values: Met, Partial, Not met, Not applicable, Not reviewed. "Met" needs evidence. Link findings by ID. The prompts below are this template's own questions, not ASVS text. -->

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

| Chapter | Name | Status | Evidence | Findings |
|---|---|---|---|---|
| V1 | Encoding and Sanitization | [Met] | *Example:* ORM with bound parameters; React output encoding; no `eval` | None |
| V2 | Validation and Business Logic | [Not met] | *Example:* Schema validation on every endpoint, but a claim can be approved by its submitter | SR-002 |
| V3 | Web Frontend Security | [Partial] | *Example:* CSP present; no Subresource Integrity on third-party script | SR-007 |
| V4 | API and Web Service | [Met] | *Example:* OpenAPI schema enforced; Content-Type set on every response | None |
| V5 | File Handling | [Partial] | *Example:* Size limit set; content type trusted from client | SR-008 |
| V6 | Authentication | [Met] | *Example:* SSO via corporate IdP with MFA enforced | None |
| V7 | Session Management | [Partial] | *Example:* 8-hour token lifetime; logout does not revoke refresh token | SR-003 |
| V8 | Authorization | [Not met] | *Example:* No per-object ownership check on `GET /claims/{id}` | SR-001 |
| V9 | Self-contained Tokens | [Met] | *Example:* JWT signature, issuer, audience and expiry validated by middleware | None |
| V10 | OAuth and OIDC | [Partial] | *Example:* Tokens held in browser JavaScript rather than a backend-for-frontend | SR-003 |
| V11 | Cryptography | [Partial] | *Example:* Disk encryption only; no documented key lifecycle; bank details not field-encrypted | SR-004 |
| V12 | Secure Communication | [Met] | *Example:* TLS 1.2 and 1.3 only; internal calls use TLS with certificate validation | None |
| V13 | Configuration | [Partial] | *Example:* Secrets in CI environment variables; no rotation | SR-009 |
| V14 | Data Protection | [Met] | *Example:* No sensitive data in URLs; caches bypassed for receipts | None |
| V15 | Secure Coding and Architecture | [Partial] | *Example:* No documented remediation time frame for vulnerable dependencies | SR-006 |
| V16 | Security Logging and Error Handling | [Partial] | *Example:* Approvals logged without actor IP; logs editable by admins | SR-005 |
| V17 | WebRTC | [Not applicable] | No real-time media or TURN server | None |

### 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

<!-- Guidance: One row per finding. Severity uses the scale in 12.2. Describe the weakness and its impact on this system specifically; link the threat and ASVS requirement so the trace is visible. Only cite a requirement number you have checked in the 5.0.0 text. -->

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

| ID | Title | ASVS ref | Threat | Severity | Description and impact | Recommendation | Owner | Status |
|---|---|---|---|---|---|---|---|---|
| SR-001 | Missing object-level authorization on claims | v5.0.0-8.2.2 | T-01 | Critical | *Example:* `GET` and `PATCH /claims/{id}` check only that the user is logged in. Any employee can read or change any claim by enumerating IDs. | Enforce ownership or approver relationship in a shared authorization layer; add negative tests | [@name] | [Open] |
| SR-002 | Self-approval possible | v5.0.0-2.3.1 and V2.1 documentation | T-03 | High | *Example:* A user who is both submitter and approver can approve their own claim. | Block approval when approver equals submitter; require a second approver above [EUR 1,000] | [@name] | [Open] |
| SR-003 | Tokens exposed to browser JavaScript and not revoked on logout | v5.0.0-10.1.1, v5.0.0-7.4.1 | T-06 | Medium | *Example:* Access and refresh tokens stored in localStorage for 8 hours are exposed to any XSS and survive logout. | Backend-for-frontend holding tokens; short-lived session cookie; revoke refresh token on logout | [@name] | [Open] |
| SR-004 | Bank details not encrypted at field level, no key policy | v5.0.0-11.1.1 | T-04 | High | *Example:* Database administrators and backups expose bank details in clear text; no documented key lifecycle. | Field-level encryption with keys in [KMS]; documented key lifecycle; restrict decrypt to the payment job | [@name] | [In progress] |
| SR-005 | Audit log not tamper-evident | v5.0.0-16.4.2 | T-03 | Medium | *Example:* Finance administrators can delete approval log rows. | Write audit events to an append-only store; alert on gaps | [@name] | [Open] |
| SR-008 | Upload content not validated | v5.0.0-5.2.2 | T-02 | Medium | *Example:* Content type is taken from the client header; a script renamed `.jpg` is stored and served. | Check extension and magic bytes server-side; serve with `Content-Disposition: attachment` | [@name] | [Open] |
| [SR-nnn] | [Title] | [v5.0.0-x.y.z] | [T-nn] | [Severity] | [Description and impact] | [Recommendation] | [@name] | [Status] |

## 9. Remediation plan

<!-- Guidance: Agree dates with the engineering owner, not alone. Critical and High findings normally block release unless the residual risk is formally accepted. ASVS 5.0 expects remediation time frames to be documented, so reuse the organisation's policy here. -->

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.

| Finding | Action | Ticket | Owner | Target date | Blocks release | Verification |
|---|---|---|---|---|---|---|
| SR-001 | Central policy check plus tests for cross-user access | [SEC-101] | [@name] | YYYY-MM-DD | Yes | Automated negative tests and retest by security |
| SR-002 | Segregation-of-duties rule in approval service | [SEC-102] | [@name] | YYYY-MM-DD | Yes | Unit tests and manual retest |
| SR-004 | Field encryption for bank details and key policy | [SEC-104] | [@name] | YYYY-MM-DD | No, accepted until date | Configuration review |
| [SR-nnn] | [Action] | [Ticket] | [@name] | YYYY-MM-DD | [Yes / No] | [How it will be verified] |

The timeline below shows the plan against the release date.

```mermaid
gantt
  title Remediation plan
  dateFormat YYYY-MM-DD
  section Blocking
  SR-001 authorization layer :a1, 2026-11-02, 10d
  SR-002 segregation of duties :a2, 2026-11-02, 5d
  section Non-blocking
  SR-004 field encryption :a3, 2026-11-16, 15d
  SR-005 append-only audit log :a4, 2026-11-23, 10d
  section Release
  Retest and go-live :milestone, 2026-11-20, 0d
```

## 10. Residual risk and decision

<!-- Guidance: State the overall conclusion and any risk the business accepts. Accepted risk needs a named owner and an expiry date. -->

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.

| Accepted risk | Finding | Justification | Accepted by | Expires |
|---|---|---|---|---|
| *Example:* Bank details unencrypted at field level | SR-004 | Compensating controls: encrypted backups, restricted DBA access, monitoring | [@product-owner] | YYYY-MM-DD |
| [Risk] | [SR-nnn] | [Justification] | [@name] | YYYY-MM-DD |

## 11. Sign-off

<!-- Guidance: Sign-off confirms that findings, plan and residual risk are understood. Final approvals are also recorded under Document control. -->

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.

| Role | Name | Signature or approval reference | Date |
|---|---|---|---|
| Security review lead | [@name] | [Ticket or e-signature reference] | YYYY-MM-DD |
| Engineering owner | [@name] | [Reference] | YYYY-MM-DD |
| Product owner | [@name] | [Reference] | YYYY-MM-DD |
| Risk owner for accepted risks | [@name] | [Reference] | YYYY-MM-DD |

## 12. Appendices

<!-- Guidance: Definitions and scales used in the review, so the document stands on its own. -->

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

### 12.1 Glossary

| Term | Meaning |
|---|---|
| ASVS | OWASP Application Security Verification Standard |
| BOLA / IDOR | Broken object level authorization / insecure direct object reference |
| DFD | Data flow diagram |
| STRIDE | Spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege |
| Trust boundary | A point where data or control passes between zones of different trust |
| Residual risk | Risk remaining after planned controls are in place |

### 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.

| Severity | Risk score | Typical meaning |
|---|---|---|
| Critical | 20 to 25 | Remote, unauthenticated or trivial exploitation with major impact |
| High | 12 to 19 | Significant data exposure or fraud possible by an authenticated user |
| Medium | 6 to 11 | Exploitation requires conditions or has limited impact |
| Low | 1 to 5 | Defence in depth or hardening improvement |

### 12.3 References

| Reference | Use |
|---|---|
| OWASP ASVS 5.0.0 (github.com/OWASP/ASVS, folder 5.0) | Chapters, sections, levels and requirement IDs used in sections 6 to 8 |
| OWASP Threat Modeling resources | Data flow and STRIDE approach |
| [Internal security policy] | Classification and remediation targets |
| [Design document] | System under review |

## 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.