# Security Requirements Specification: [Application name]

> Security requirements for one application, selected by OWASP
> Application Security Verification Standard (ASVS) level and organised
> by ASVS chapter, with abuse cases that show what each group of
> requirements defends against. It is based on OWASP ASVS 5.0.0
> (released 30 May 2025), which groups about 350 requirements into 17
> chapters and three levels. Requirement numbers are cited in the
> version-tagged form ASVS recommends (`v5.0.0-<chapter>.<section>.<requirement>`);
> the requirement statements in this template are original paraphrases.
> Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Decide the target level first (section 2). Level 1 is the minimum
  baseline, Level 2 is the target ASVS suggests for most applications,
  Level 3 is for the most sensitive ones.
- Work chapter by chapter in section 4. For each chapter either list the
  requirements that apply or record why the chapter does not apply.
- Write abuse cases (section 5) with the product owner and a tester.
  They make the security requirements concrete and give testers a
  starting point.
- Keep the version tag on every ASVS reference. ASVS numbers change
  between versions, and an untagged number is assumed to mean the
  latest version.
- Link to the threat model (`security/threat-model`) for the analysis;
  this document records the resulting requirements.
-->

## Document control

<!-- Guidance: Identify the specification and its target ASVS level so every copy can be traced to one version. -->

| Field | Value |
|---|---|
| Document ID | [SECREQ-APP-001] |
| Application | [Application name and release] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@security-architect] |
| Approvers / reviewers | [Product owner, engineering lead, security lead, privacy officer] |
| ASVS version | 5.0.0 |
| Target ASVS level | [L1 / L2 / L3] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential] |
| Related documents | [Threat model], [SRS], [Security test plan], [Data protection impact assessment] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Product owner | [@name] | [Approved / Approved with comments / Rejected] | YYYY-MM-DD |
| Engineering lead | [@name] | [Decision] | YYYY-MM-DD |
| Security lead | [@name] | [Decision] | YYYY-MM-DD |
| Privacy officer | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial draft |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Raised V8 authorization to L2 after the threat model review |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved as release 1 baseline |

## Contents

<!-- Guidance: Keep this list in step with the headings. -->

1. [Purpose and scope](#1-purpose-and-scope)
2. [Target verification level](#2-target-verification-level)
3. [Context and security documentation](#3-context-and-security-documentation)
4. [Requirements by ASVS chapter](#4-requirements-by-asvs-chapter)
5. [Abuse cases](#5-abuse-cases)
6. [Project-specific security requirements](#6-project-specific-security-requirements)
7. [Verification approach](#7-verification-approach)
8. [Traceability](#8-traceability)
9. [Exceptions and risk acceptance](#9-exceptions-and-risk-acceptance)
10. [Glossary and references](#10-glossary-and-references)

## 1. Purpose and scope

<!-- Guidance: Say what the specification covers and what it does not. Questions: which components, interfaces and environments are in scope, which are provided by a platform team and inherited? Pitfall: specifying the web front end and forgetting the APIs and batch jobs behind it. -->

This specification states the security requirements that [Application
name] must meet for [release]. It is the reference for design,
implementation, security testing and acceptance.

*Example:* The Brindlecote Clinics patient booking portal (a fictional
healthcare provider) lets patients book, move and cancel appointments,
upload referral letters and read appointment letters. It has a web
front end, a public REST API used by a mobile app, and an
administration area for clinic staff.

| In scope | Out of scope (inherited or covered elsewhere) |
|---|---|
| [Web front end, public API, admin area, file upload service] | [Identity provider, covered by its own assessment] |
| [Production and staging environments] | [Corporate network and endpoints] |
| [Third-party libraries shipped with the application] | [Clinical record system, accessed only through its API] |

## 2. Target verification level

<!-- Guidance: Choose the level from the risk of the application, not from the effort you want to spend. ASVS levels are cumulative: Level 2 includes every Level 1 requirement. Pitfall: declaring Level 2 overall and then silently skipping chapters. -->

| Factor | Assessment |
|---|---|
| Data handled | [Personal, health, financial, credentials] |
| Users | [Public, authenticated customers, staff, administrators] |
| Exposure | [Internet-facing, partner network, internal] |
| Impact of compromise | [Describe for confidentiality, integrity and availability] |
| Legal or contractual drivers | [Data protection law, sector rules, customer contracts] |

**Target:** [Level], because [reason]. Chapters raised above or lowered
below the target level are listed in the table in section 4.0 with the
reason.

*Example:* Level 2 overall, because the portal handles health-related
personal data and is internet-facing. V6 Authentication for staff
accounts is raised to Level 3 for the requirement on hardware-based,
phishing-resistant factors, because staff can see every patient's bookings.

Level overview (from the ASVS 5.0.0 introduction, paraphrased): Level 1
holds roughly 20% of the requirements and covers first-layer defences;
Level 2 adds roughly 50% more, so a Level 2 application meets about 70%
of the requirements; Level 3 adds the final 30% or so, mostly defence in
depth and harder controls.

## 3. Context and security documentation

<!-- Guidance: ASVS 5.0 asks for documented security decisions in many chapters (the ".1 Documentation" sections). Record here where each decision lives, so testers can compare implementation with intent. Pitfall: requirements that say "according to the documentation" when no such document exists. -->

| ASVS documentation section | Decision to document | Where it is recorded | Owner |
|---|---|---|---|
| V1.1 Encoding and Sanitization Architecture | Where untrusted data is decoded and encoded | [Architecture document] | [@name] |
| V2.1 Validation and Business Logic Documentation | Input rules and business limits per function | [Functional specification] | [@name] |
| V5.1 File Handling Documentation | Allowed file types, sizes and handling | [This document, SR-FILE-001] | [@name] |
| V6.1 Authentication Documentation | Rate limits, anti-automation, factors used | [Authentication design] | [@name] |
| V7.1 Session Management Documentation | Timeouts, concurrent sessions, termination | [Session design] | [@name] |
| V8.1 Authorization Documentation | Roles, permissions, data-level rules | [Authorization matrix] | [@name] |
| V11.1 Cryptographic Inventory and Documentation | Keys, algorithms and their owners | [Crypto inventory] | [@name] |
| V13.1 Configuration Documentation | Backend connections and secrets | [Operations runbook] | [@name] |
| V14.1 Data Protection Documentation | Sensitive data classes and protection levels | [Data classification] | [@name] |
| V16.1 Security Logging Documentation | Events logged, format, retention | [Logging standard] (`security/security-logging-standard`) | [@name] |

## 4. Requirements by ASVS chapter

<!-- Guidance: One subsection per ASVS chapter. For each requirement give a project ID, the ASVS reference with version tag, the level, a statement in your own words that fits this application, and the verification method. If a chapter does not apply, keep the heading and say why. Pitfall: copying all ~350 ASVS statements into the document; select, tailor and reference instead. -->

### 4.0 Chapter applicability

| Chapter | Applies | Level | Reason or note |
|---|---|---|---|
| V1 Encoding and Sanitization | Yes | L2 | Renders user-supplied text and builds queries |
| V2 Validation and Business Logic | Yes | L2 | Booking rules and limits |
| V3 Web Frontend Security | Yes | L2 | Browser front end |
| V4 API and Web Service | Yes | L2 | Public REST API |
| V5 File Handling | Yes | L2 | Referral letter upload |
| V6 Authentication | Yes | L2, staff raised to L3 | See section 2 |
| V7 Session Management | Yes | L2 | |
| V8 Authorization | Yes | L2 | Patients, clinic staff, administrators |
| V9 Self-contained Tokens | [Yes / No] | [Level] | [Only if the application issues or validates such tokens] |
| V10 OAuth and OIDC | [Yes / No] | [Level] | [If the application acts as client, resource server or provider] |
| V11 Cryptography | Yes | L2 | |
| V12 Secure Communication | Yes | L2 | |
| V13 Configuration | Yes | L2 | |
| V14 Data Protection | Yes | L2 | Health-related personal data |
| V15 Secure Coding and Architecture | Yes | L2 | |
| V16 Security Logging and Error Handling | Yes | L2 | |
| V17 WebRTC | No | | The portal has no real-time audio or video |

### 4.1 V1 Encoding and Sanitization

| ID | ASVS reference | Level | Requirement (project wording) | Verification |
|---|---|---|---|---|
| SR-ENC-001 *(Example)* | v5.0.0-1.2.1 | L1 | Pages that display patient-entered text encode it for the HTML context in which it appears | Code review, DAST |
| SR-ENC-002 *(Example)* | v5.0.0-1.2.4 | L1 | All database access uses parameterised queries or the ORM's safe query API | Code review, SAST |
| SR-ENC-003 *(Example)* | v5.0.0-1.2.5 | L1 | The document conversion job never builds operating system commands from user input | Code review |
| [SR-ENC-nnn] | [v5.0.0-x.y.z] | [L] | [Requirement] | [Method] |

### 4.2 V2 Validation and Business Logic

| ID | ASVS reference | Level | Requirement (project wording) | Verification |
|---|---|---|---|---|
| SR-BL-001 *(Example)* | v5.0.0-2.2.1 | L1 | Booking requests are validated against the documented rules for dates, clinics and appointment types, using allow lists | Unit and API tests |
| SR-BL-002 *(Example)* | v5.0.0-2.3.1 | L1 | The booking flow processes steps only in the defined order; a request that skips the slot hold step is rejected | API test |
| SR-BL-003 *(Example)* | v5.0.0-2.3.2 | L2 | A patient can hold at most the documented number of future appointments per clinic | API test |
| SR-BL-004 *(Example)* | v5.0.0-2.4.1 | L2 | Slot search and booking are protected against automated bulk requests that would exhaust appointments | Load test, abuse case AC-02 |

### 4.3 V5 File Handling

| ID | ASVS reference | Level | Requirement (project wording) | Verification |
|---|---|---|---|---|
| SR-FILE-001 *(Example)* | v5.0.0-5.2.1 | L1 | Uploaded referral letters larger than the documented maximum size are rejected before processing | API test |
| [SR-FILE-nnn] | [v5.0.0-5.x.y] | [L] | [Requirement on file type checks, storage location, download headers] | [Method] |

### 4.4 V6 Authentication

| ID | ASVS reference | Level | Requirement (project wording) | Verification |
|---|---|---|---|---|
| SR-AUTH-001 *(Example)* | v5.0.0-6.2.1 | L1 | Patient passwords have a minimum length of at least 8 characters, with 15 or more encouraged on the sign-up screen | Functional test |
| SR-AUTH-002 *(Example)* | v5.0.0-6.2.12 | L2 | New and changed passwords are checked against a set of known breached passwords | Functional test |
| SR-AUTH-003 *(Example)* | v5.0.0-6.3.1 | L1 | Credential stuffing and brute force are limited as set out in the authentication design | Abuse case AC-01 |
| SR-AUTH-004 *(Example)* | v5.0.0-6.3.3 | L2 (L3 for staff) | Access requires multi-factor authentication; staff use a hardware-based, phishing-resistant factor with a user action, as the Level 3 condition of this requirement asks | Configuration review |
| SR-AUTH-005 *(Example)* | v5.0.0-6.4.3 | L2 | Password reset cannot bypass an enabled second factor | Functional test |

### 4.5 V7 Session Management

| ID | ASVS reference | Level | Requirement (project wording) | Verification |
|---|---|---|---|---|
| SR-SES-001 *(Example)* | v5.0.0-7.2.1 | L1 | Session tokens are verified only by the backend | Code review |
| SR-SES-002 *(Example)* | v5.0.0-7.2.4 | L1 | A new session token is issued at every sign-in and re-authentication, and the old one is ended | Functional test |
| SR-SES-003 *(Example)* | v5.0.0-7.3.1 | L2 | Inactive sessions require re-authentication after the documented idle time | Functional test |
| SR-SES-004 *(Example)* | v5.0.0-7.3.2 | L2 | Every session has a documented absolute maximum lifetime | Functional test |
| SR-SES-005 *(Example)* | v5.0.0-7.4.1 | L1 | After logout or expiry the session cannot be used again | Functional test |

### 4.6 V8 Authorization

| ID | ASVS reference | Level | Requirement (project wording) | Verification |
|---|---|---|---|---|
| SR-AZ-001 *(Example)* | v5.0.0-8.2.1 | L1 | Each function is available only to roles granted it in the authorization matrix | API test per role |
| SR-AZ-002 *(Example)* | v5.0.0-8.2.2 | L1 | A patient can read and change only their own appointments and letters | Abuse case AC-03 |
| SR-AZ-003 *(Example)* | v5.0.0-8.2.3 | L2 | Clinic staff see only the fields their role needs; reception staff do not see referral content | API test |
| SR-AZ-004 *(Example)* | v5.0.0-8.3.1 | L1 | Authorization is enforced on the server, never only in the mobile app or browser | Code review, API test |

### 4.7 V11 Cryptography and V12 Secure Communication

| ID | ASVS reference | Level | Requirement (project wording) | Verification |
|---|---|---|---|---|
| SR-CRY-001 *(Example)* | v5.0.0-11.4.2 | L2 | Passwords are stored with an approved, computationally expensive password hashing function | Code review |
| SR-COM-001 *(Example)* | v5.0.0-12.1.1 | L1 | Only current recommended TLS versions are enabled, preferring the newest | Configuration scan |
| SR-COM-002 *(Example)* | v5.0.0-12.2.1 | L1 | All client connections to external HTTP services use TLS with no fallback to plain text | Configuration scan |

### 4.8 V13 Configuration and V14 Data Protection

| ID | ASVS reference | Level | Requirement (project wording) | Verification |
|---|---|---|---|---|
| SR-CFG-001 *(Example)* | v5.0.0-13.3.1 | L2 | Backend secrets are created, stored and rotated in the secrets manager (`security/secrets-management-standard`) | Configuration review |
| SR-DP-001 *(Example)* | v5.0.0-14.2.1 | L1 | Sensitive data such as appointment reasons never appears in URLs or query strings | DAST, log review |

### 4.9 V16 Security Logging and Error Handling

| ID | ASVS reference | Level | Requirement (project wording) | Verification |
|---|---|---|---|---|
| SR-LOG-001 *(Example)* | v5.0.0-16.2.1 | L2 | Each security log entry records when, where, who and what, enough to rebuild a timeline | Log review |
| SR-LOG-002 *(Example)* | v5.0.0-16.3.1 | L2 | Successful and failed sign-ins are logged | Functional test |
| SR-LOG-003 *(Example)* | v5.0.0-16.3.2 | L2 | Failed authorization attempts are logged | Abuse case AC-03 |
| SR-LOG-004 *(Example)* | v5.0.0-16.4.1 | L2 | Logging components encode data to prevent log injection | Code review |
| SR-LOG-005 *(Example)* | v5.0.0-16.5.1 | L2 | Unexpected errors return a generic message without internal details | DAST |

### 4.10 Remaining chapters

[Add tables for V3 Web Frontend Security, V4 API and Web Service, V9
Self-contained Tokens, V10 OAuth and OIDC and V15 Secure Coding and
Architecture in the same format, or state why a chapter does not apply.
Use the ASVS 5.0.0 text on GitHub for the full list of requirements per
level.]

## 5. Abuse cases

<!-- Guidance: An abuse case describes how an attacker or careless insider would try to misuse a feature, and which requirements stop it. Write one for each high-value function. Questions: what does the attacker want, what do they already have, what do they try, what must the system do? Pitfall: abuse cases that only restate a vulnerability name with no story. -->

| ID | Feature | Attacker and goal | Attack steps | Expected system behaviour | Requirements |
|---|---|---|---|---|---|
| AC-01 *(Example)* | Patient sign-in | Criminal with leaked password lists wants account access | Tries thousands of email and password pairs from many addresses | Throttles and challenges per the authentication design, logs attempts, alerts on the pattern | SR-AUTH-002, SR-AUTH-003, SR-LOG-002 |
| AC-02 *(Example)* | Slot booking | Reseller bot wants to hoard scarce slots | Scripts searches and holds across many accounts | Limits holds per patient, detects automation, releases held slots | SR-BL-002, SR-BL-003, SR-BL-004 |
| AC-03 *(Example)* | Appointment letters | Signed-in patient wants another patient's letters | Changes the letter ID in the API request | Returns not found, logs the attempt | SR-AZ-002, SR-AZ-004, SR-LOG-003 |
| AC-04 *(Example)* | Referral upload | Attacker wants to run code or overload the service | Uploads a very large or disguised file | Rejects by size and type before processing | SR-FILE-001 |
| [AC-nn] | [Feature] | [Actor and goal] | [Steps] | [Expected behaviour] | [SR IDs] |

The sequence below shows abuse case AC-03 and the controls that stop it.

```mermaid
sequenceDiagram
  participant A as Signed-in patient (attacker)
  participant G as API gateway
  participant S as Booking service
  participant L as Security log
  A->>G: GET letter with another patient's ID
  G->>S: Forward request with session identity
  S->>S: Check owner of letter against session identity
  S->>L: Record failed authorization attempt
  S-->>G: 404 Not found
  G-->>A: 404 Not found
```

## 6. Project-specific security requirements

<!-- Guidance: Record requirements that ASVS does not cover or that your context makes stricter: legal duties, contractual clauses, business-specific fraud controls. Pitfall: duplicating an ASVS requirement under a new ID, which splits the evidence. -->

| ID | Requirement | Source | Level of need | Verification |
|---|---|---|---|---|
| SR-PRJ-001 *(Example)* | Clinic staff access to a patient record outside their clinic needs a recorded reason | Data protection policy | Must | Functional test, audit log review |
| SR-PRJ-002 *(Example)* | Appointment letters are deleted from the portal after the retention period in the records schedule | Records policy | Must | Scheduled job test |
| [SR-PRJ-nnn] | [Requirement] | [Source] | [Must / Should] | [Method] |

Data protection duties depend on jurisdiction. As dated examples
(checked 2026-10-30): in the EU, Article 32 (security of processing) of
the GDPR, Regulation (EU) 2016/679, https://eur-lex.europa.eu/eli/reg/2016/679/oj;
in the UK, the UK GDPR together with the Data Protection Act 2018, as
amended by the Data (Use and Access) Act 2025,
https://www.legislation.gov.uk/ukpga/2018/12; in the US, for HIPAA
covered entities and business associates, the Security Rule in 45 CFR
Part 164, Subpart C (sections 164.302 to 164.318),
https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C.
This is not legal advice; check the current official text and a
qualified professional.

## 7. Verification approach

<!-- Guidance: Say how each requirement will be shown to be met, and by whom. Questions: which methods, which tools, at which stage, what evidence is kept? Pitfall: relying on one penetration test before launch to verify everything. -->

| Method | Used for | When | Evidence |
|---|---|---|---|
| Code review | Encoding, authorization logic, cryptography | Each pull request | Review record |
| Static analysis (SAST) | Injection, unsafe functions | Each build | Scan report |
| Dynamic testing (DAST) | Headers, error handling, URL data | Each release candidate | Scan report |
| Functional and API tests | Session, authentication, business limits | Each build | Test results |
| Configuration review | TLS, secrets, identity provider settings | Each environment change | Checklist |
| Penetration test | Abuse cases and chained attacks | Before go-live and yearly | Report (`security/pentest-report`) |

## 8. Traceability

<!-- Guidance: Link each security requirement to the threat or abuse case it addresses and to its test, so that a gap is visible. Pitfall: tests that pass but trace to no requirement. -->

| Requirement | Threat or abuse case | Test or evidence | Status |
|---|---|---|---|
| SR-AUTH-003 *(Example)* | AC-01, threat T-04 | TC-SEC-012 | [Planned / Passed / Failed] |
| SR-BL-004 *(Example)* | AC-02 | TC-PERF-007 | [Status] |
| SR-AZ-002 *(Example)* | AC-03, threat T-07 | TC-SEC-021 | [Status] |
| SR-FILE-001 *(Example)* | AC-04 | TC-SEC-030 | [Status] |

Keep the project-wide links in `requirements/traceability-matrix`.

## 9. Exceptions and risk acceptance

<!-- Guidance: Record every applicable requirement that will not be met, with the risk, compensating control, owner and expiry. Pitfall: open-ended exceptions that nobody reviews. -->

| ID | Requirement not met | Reason | Compensating control | Risk owner | Expires |
|---|---|---|---|---|---|
| EX-01 *(Example)* | SR-SES-004 for the legacy kiosk client | Kiosk cannot re-authenticate mid-visit | Kiosk sessions end at clinic closing time | [@name] | YYYY-MM-DD |
| [EX-nn] | [SR ID] | [Reason] | [Control] | [@owner] | YYYY-MM-DD |

## 10. Glossary and references

<!-- Guidance: Define terms and list the sources with versions. -->

### 10.1 Glossary

| Term | Meaning |
|---|---|
| ASVS | OWASP Application Security Verification Standard |
| Abuse case | A description of how a feature could be misused, with the behaviour the system must show |
| Level (L1, L2, L3) | ASVS verification level; higher levels include all lower-level requirements |
| Version-tagged reference | An ASVS requirement number prefixed with the ASVS version, for example `v5.0.0-8.2.2` |

### 10.2 References

| Reference | Use |
|---|---|
| OWASP ASVS 5.0.0 (30 May 2025), https://asvs.owasp.org/ and https://github.com/OWASP/ASVS | Chapters, levels, requirement numbers |
| `security/threat-model` | Threats that the requirements address |
| `security/secure-coding-standard` | Coding rules that implement many V1, V2 and V15 requirements |
| `security/security-review` | Design review against this specification |
| `requirements/srs-iso-29148` | Overall software requirements, which cite this document |
| `requirements/nfr-catalogue` | Other quality requirements |

## Standard and licence note

Based on the OWASP Application Security Verification Standard (ASVS)
version 5.0.0, released 30 May 2025 by the OWASP Foundation under the
Creative Commons Attribution-ShareAlike 4.0 International licence
(CC BY-SA 4.0), https://asvs.owasp.org/. This template cites ASVS chapter
and section names, requirement numbers and levels, and paraphrases the
level descriptions and requirements in original wording; it does not
copy ASVS requirement text. If you paste ASVS requirement text into your
copy, that material remains under CC BY-SA 4.0: attribute OWASP, link the
licence, state any changes, and share your adaptation of it under the
same licence. Check the current ASVS release before use, as requirement
numbers change between versions. The laws named in section 6 are dated
examples only. Template licence: MIT.