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.
Document control
| 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
1. Purpose and scope
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
| 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
| 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
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
| 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.
6. Project-specific security requirements
| 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
| 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
| 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
| 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
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.