Markdown Editor

Security Requirements Specification Template (OWASP ASVS 5.0)

Security requirements by ASVS 5.0 level and chapter, documented decisions, version-tagged IDs, abuse cases, verification, traceability, exceptions

आवश्यकताएँ और विश्लेषणपूर्णOWASP ASVS 5.0.0securityspec
एडिटर में खोलें.md डाउनलोड करें

उपयोग कैसे करें: Use it when an application needs agreed, testable security requirements before design and testing. Fill the target level and chapter applicability first, then the per-chapter tables and abuse cases. The main pitfall is copying every ASVS requirement instead of selecting and tailoring them with version-tagged references.

प्रीव्यू

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

FieldValue
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 version5.0.0
Target ASVS level[L1 / L2 / L3]
Last updatedYYYY-MM-DD
Classification[Confidential]
Related documents[Threat model], [SRS], [Security test plan], [Data protection impact assessment]

Approvals

RoleNameDecisionDate
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

VersionDateAuthorChange summary
0.1YYYY-MM-DD[@name]Initial draft
0.2YYYY-MM-DD[@name]Example: Raised V8 authorization to L2 after the threat model review
1.0YYYY-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 scopeOut 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

FactorAssessment
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 sectionDecision to documentWhere it is recordedOwner
V1.1 Encoding and Sanitization ArchitectureWhere untrusted data is decoded and encoded[Architecture document][@name]
V2.1 Validation and Business Logic DocumentationInput rules and business limits per function[Functional specification][@name]
V5.1 File Handling DocumentationAllowed file types, sizes and handling[This document, SR-FILE-001][@name]
V6.1 Authentication DocumentationRate limits, anti-automation, factors used[Authentication design][@name]
V7.1 Session Management DocumentationTimeouts, concurrent sessions, termination[Session design][@name]
V8.1 Authorization DocumentationRoles, permissions, data-level rules[Authorization matrix][@name]
V11.1 Cryptographic Inventory and DocumentationKeys, algorithms and their owners[Crypto inventory][@name]
V13.1 Configuration DocumentationBackend connections and secrets[Operations runbook][@name]
V14.1 Data Protection DocumentationSensitive data classes and protection levels[Data classification][@name]
V16.1 Security Logging DocumentationEvents logged, format, retention[Logging standard] (security/security-logging-standard)[@name]

4. Requirements by ASVS chapter

4.0 Chapter applicability

ChapterAppliesLevelReason or note
V1 Encoding and SanitizationYesL2Renders user-supplied text and builds queries
V2 Validation and Business LogicYesL2Booking rules and limits
V3 Web Frontend SecurityYesL2Browser front end
V4 API and Web ServiceYesL2Public REST API
V5 File HandlingYesL2Referral letter upload
V6 AuthenticationYesL2, staff raised to L3See section 2
V7 Session ManagementYesL2
V8 AuthorizationYesL2Patients, 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 CryptographyYesL2
V12 Secure CommunicationYesL2
V13 ConfigurationYesL2
V14 Data ProtectionYesL2Health-related personal data
V15 Secure Coding and ArchitectureYesL2
V16 Security Logging and Error HandlingYesL2
V17 WebRTCNoThe portal has no real-time audio or video

4.1 V1 Encoding and Sanitization

IDASVS referenceLevelRequirement (project wording)Verification
SR-ENC-001 (Example)v5.0.0-1.2.1L1Pages that display patient-entered text encode it for the HTML context in which it appearsCode review, DAST
SR-ENC-002 (Example)v5.0.0-1.2.4L1All database access uses parameterised queries or the ORM's safe query APICode review, SAST
SR-ENC-003 (Example)v5.0.0-1.2.5L1The document conversion job never builds operating system commands from user inputCode review
[SR-ENC-nnn][v5.0.0-x.y.z][L][Requirement][Method]

4.2 V2 Validation and Business Logic

IDASVS referenceLevelRequirement (project wording)Verification
SR-BL-001 (Example)v5.0.0-2.2.1L1Booking requests are validated against the documented rules for dates, clinics and appointment types, using allow listsUnit and API tests
SR-BL-002 (Example)v5.0.0-2.3.1L1The booking flow processes steps only in the defined order; a request that skips the slot hold step is rejectedAPI test
SR-BL-003 (Example)v5.0.0-2.3.2L2A patient can hold at most the documented number of future appointments per clinicAPI test
SR-BL-004 (Example)v5.0.0-2.4.1L2Slot search and booking are protected against automated bulk requests that would exhaust appointmentsLoad test, abuse case AC-02

4.3 V5 File Handling

IDASVS referenceLevelRequirement (project wording)Verification
SR-FILE-001 (Example)v5.0.0-5.2.1L1Uploaded referral letters larger than the documented maximum size are rejected before processingAPI 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

IDASVS referenceLevelRequirement (project wording)Verification
SR-AUTH-001 (Example)v5.0.0-6.2.1L1Patient passwords have a minimum length of at least 8 characters, with 15 or more encouraged on the sign-up screenFunctional test
SR-AUTH-002 (Example)v5.0.0-6.2.12L2New and changed passwords are checked against a set of known breached passwordsFunctional test
SR-AUTH-003 (Example)v5.0.0-6.3.1L1Credential stuffing and brute force are limited as set out in the authentication designAbuse case AC-01
SR-AUTH-004 (Example)v5.0.0-6.3.3L2 (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 asksConfiguration review
SR-AUTH-005 (Example)v5.0.0-6.4.3L2Password reset cannot bypass an enabled second factorFunctional test

4.5 V7 Session Management

IDASVS referenceLevelRequirement (project wording)Verification
SR-SES-001 (Example)v5.0.0-7.2.1L1Session tokens are verified only by the backendCode review
SR-SES-002 (Example)v5.0.0-7.2.4L1A new session token is issued at every sign-in and re-authentication, and the old one is endedFunctional test
SR-SES-003 (Example)v5.0.0-7.3.1L2Inactive sessions require re-authentication after the documented idle timeFunctional test
SR-SES-004 (Example)v5.0.0-7.3.2L2Every session has a documented absolute maximum lifetimeFunctional test
SR-SES-005 (Example)v5.0.0-7.4.1L1After logout or expiry the session cannot be used againFunctional test

4.6 V8 Authorization

IDASVS referenceLevelRequirement (project wording)Verification
SR-AZ-001 (Example)v5.0.0-8.2.1L1Each function is available only to roles granted it in the authorization matrixAPI test per role
SR-AZ-002 (Example)v5.0.0-8.2.2L1A patient can read and change only their own appointments and lettersAbuse case AC-03
SR-AZ-003 (Example)v5.0.0-8.2.3L2Clinic staff see only the fields their role needs; reception staff do not see referral contentAPI test
SR-AZ-004 (Example)v5.0.0-8.3.1L1Authorization is enforced on the server, never only in the mobile app or browserCode review, API test

4.7 V11 Cryptography and V12 Secure Communication

IDASVS referenceLevelRequirement (project wording)Verification
SR-CRY-001 (Example)v5.0.0-11.4.2L2Passwords are stored with an approved, computationally expensive password hashing functionCode review
SR-COM-001 (Example)v5.0.0-12.1.1L1Only current recommended TLS versions are enabled, preferring the newestConfiguration scan
SR-COM-002 (Example)v5.0.0-12.2.1L1All client connections to external HTTP services use TLS with no fallback to plain textConfiguration scan

4.8 V13 Configuration and V14 Data Protection

IDASVS referenceLevelRequirement (project wording)Verification
SR-CFG-001 (Example)v5.0.0-13.3.1L2Backend 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.1L1Sensitive data such as appointment reasons never appears in URLs or query stringsDAST, log review

4.9 V16 Security Logging and Error Handling

IDASVS referenceLevelRequirement (project wording)Verification
SR-LOG-001 (Example)v5.0.0-16.2.1L2Each security log entry records when, where, who and what, enough to rebuild a timelineLog review
SR-LOG-002 (Example)v5.0.0-16.3.1L2Successful and failed sign-ins are loggedFunctional test
SR-LOG-003 (Example)v5.0.0-16.3.2L2Failed authorization attempts are loggedAbuse case AC-03
SR-LOG-004 (Example)v5.0.0-16.4.1L2Logging components encode data to prevent log injectionCode review
SR-LOG-005 (Example)v5.0.0-16.5.1L2Unexpected errors return a generic message without internal detailsDAST

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

IDFeatureAttacker and goalAttack stepsExpected system behaviourRequirements
AC-01 (Example)Patient sign-inCriminal with leaked password lists wants account accessTries thousands of email and password pairs from many addressesThrottles and challenges per the authentication design, logs attempts, alerts on the patternSR-AUTH-002, SR-AUTH-003, SR-LOG-002
AC-02 (Example)Slot bookingReseller bot wants to hoard scarce slotsScripts searches and holds across many accountsLimits holds per patient, detects automation, releases held slotsSR-BL-002, SR-BL-003, SR-BL-004
AC-03 (Example)Appointment lettersSigned-in patient wants another patient's lettersChanges the letter ID in the API requestReturns not found, logs the attemptSR-AZ-002, SR-AZ-004, SR-LOG-003
AC-04 (Example)Referral uploadAttacker wants to run code or overload the serviceUploads a very large or disguised fileRejects by size and type before processingSR-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

IDRequirementSourceLevel of needVerification
SR-PRJ-001 (Example)Clinic staff access to a patient record outside their clinic needs a recorded reasonData protection policyMustFunctional test, audit log review
SR-PRJ-002 (Example)Appointment letters are deleted from the portal after the retention period in the records scheduleRecords policyMustScheduled 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

MethodUsed forWhenEvidence
Code reviewEncoding, authorization logic, cryptographyEach pull requestReview record
Static analysis (SAST)Injection, unsafe functionsEach buildScan report
Dynamic testing (DAST)Headers, error handling, URL dataEach release candidateScan report
Functional and API testsSession, authentication, business limitsEach buildTest results
Configuration reviewTLS, secrets, identity provider settingsEach environment changeChecklist
Penetration testAbuse cases and chained attacksBefore go-live and yearlyReport (security/pentest-report)

8. Traceability

RequirementThreat or abuse caseTest or evidenceStatus
SR-AUTH-003 (Example)AC-01, threat T-04TC-SEC-012[Planned / Passed / Failed]
SR-BL-004 (Example)AC-02TC-PERF-007[Status]
SR-AZ-002 (Example)AC-03, threat T-07TC-SEC-021[Status]
SR-FILE-001 (Example)AC-04TC-SEC-030[Status]

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

9. Exceptions and risk acceptance

IDRequirement not metReasonCompensating controlRisk ownerExpires
EX-01 (Example)SR-SES-004 for the legacy kiosk clientKiosk cannot re-authenticate mid-visitKiosk 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

TermMeaning
ASVSOWASP Application Security Verification Standard
Abuse caseA 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 referenceAn ASVS requirement number prefixed with the ASVS version, for example v5.0.0-8.2.2

10.2 References

ReferenceUse
OWASP ASVS 5.0.0 (30 May 2025), https://asvs.owasp.org/ and https://github.com/OWASP/ASVSChapters, levels, requirement numbers
security/threat-modelThreats that the requirements address
security/secure-coding-standardCoding rules that implement many V1, V2 and V15 requirements
security/security-reviewDesign review against this specification
requirements/srs-iso-29148Overall software requirements, which cite this document
requirements/nfr-catalogueOther 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.

संबंधित टेम्पलेट