owasp / asvs

Application Security Verification Standard

OWASP Application Security Verification Standard

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Introduction

The primary aim of the OWASP Application Security Verification Standard (ASVS) Project is to provide an open application security standard for web apps and web services of all types.

The standard provides a basis for designing, building, and testing technical application security controls, including architectural concerns, secure development lifecycle, threat modelling, agile security including continuous integration / deployment, serverless, and configuration concerns.

We gratefully recognise the organizations who have supported the project either through significant time provision or financially on our "Supporters" page!

Please log issues if you find any bugs or if you have ideas. We may subsequently ask you to open a pull request based on the discussion in the issue. We are also actively looking for translations of the 4.n branch.

Project Leaders and Working Group

The project is led by the five project leaders Andrew van der Stock, Daniel Cuthbert, Jim Manico, Josh Grossman, and Elar Lang.

The are supported by the ASVS Working Group which consists of Shanni Prutchi, Ralph Andalis, Meghan Jacquot, and Iman Sharafaldin.

Roadmap to ASVS 5.0

We have now published our roadmap and objectives for version 5.0 of the ASVS in this wiki page.

Latest Stable Version - 4.0.3

The latest stable version is version 4.0.3 (dated October 2021), which can be found:

• OWASP Application Security Verification Standard 4.0.3 English (PDF)
• OWASP Application Security Verification Standard 4.0.3 English (Word)
• OWASP Application Security Verification Standard 4.0.3 English (CSV)
• OWASP Application Security Verification Standard 4.0.3 (GitHub Tag)

The master branch of this repository will always be the "bleeding edge version" which might have in-progress changes or other edits open. The next release target will be version 5.0.

For information on changes between 4.0.2 and 4.0.3 of the standard, see this wiki page and for a full diff, see this pull request.

Translations

The OWASP Community effort with regards to translations is a best effort. Whilst we do our utmost to ensure the content is valid, from a structural perspective, there is only so much we can do to ensure the translations are correct. We rely on you, the community, to help make the ASVS as usable as possible to all around the globe, and translating the main branch into your language is important to the project.

If you think you can help with translations, or indeed ensuring the current list of translations below are correct, we'd love for you to join the community and make the ASVS amazing for all. For more information on translating the ASVS see the translations section of CONTRIBUTING.md.

• v4.0.3
  • OWASP Application Security Verification Standard 4.0.3 Spanish (PDF) and other formats. (Thanks to Carlos Allendes and Hans Herrera)
  • OWASP Application Security Verification Standard 4.0.3 Simplified Chinese (PDF) and other formats. (Thanks to Unc1e)
  • OWASP Application Security Verification Standard 4.0.3 Arabic (PDF) and other formats. (Thanks to Aref Shaheed and Mhd Ghassan Alhabash)
  • OWASP Application Security Verification Standard 4.0.3 Russian (PDF) and other formats. (Thanks to Andrei Titov)
  • OWASP Application Security Verification Standard 4.0.3 French (PDF) and other formats. (Thanks to Cédric Lallier, Alexandre Joly, Sebastien Gioria, and Marc Aubry)
  • OWASP Application Security Verification Standard 4.0.3 German (PDF) and other formats. (Thanks to Jörg Brünner)
  • OWASP Application Security Verification Standard 4.0.3 Portuguese (PDF) and other formats. (Thanks to Cesar Kohl)
• v4.0.2
  • OWASP Application Security Verification Standard 4.0.2 German (PDF) and Microsoft Word format. (Thanks to Jörg Brünner)
  • OWASP Application Security Verification Standard 4.0.2 Russian (PDF) and Microsoft Word format. (Thanks to Sergey Diakonov)
• v4.0.1
  • OWASP Application Security Verification Standard 4.0.1 Persian (PDF) (Thanks to CERT of Ferdowsi University of Mashhad / Ardalan Foroughipour)
  • OWASP Application Security Verification Standard 4.0.1 Japanese (PDF) (Thanks to Software ISAC Japan / Riotaro OKADA)
  • OWASP Application Security Verification Standard 4.0.1 Turkish (PDF) (Thanks to Fatih ERSINADIM)

Standard Objectives

The requirements were developed with the following objectives in mind:

• Help organizations adopt or adapt a high quality secure coding standard
• Help architects and developers build secure software by designing and building security in, and verifying that they are in place and effective by the use of unit and integration tests that implement ASVS tests
• Help deploy secure software via the use of repeatable, secured builds
• Help security reviewers use a comprehensive, consistent, high quality standard for hybrid code reviews, secure code reviews, peer code reviews, retrospectives, and work with developers to build security unit and integration tests. It is even possible to use this standard for penetration testing at Level 1
• Assist tool vendors by ensuring there is an easily generatable machine readable version, with CWE mappings
• Assist organizations to benchmark application security tools by the percentage of coverage of the ASVS for dynamic, interactive, and static analysis tools
• Minimize overlapping and competing requirements from other standards, by either aligning strongly with them (NIST 800-63), or being strict supersets (OWASP Top 10 2021, PCI DSS 3.2.1), which will help reduce compliance costs, effort, and time wasted in accepting unnecessary differences as risks.

ASVS requirement lists are made available in CSV, JSON, and other formats which may be useful for reference or programmatic use.

How To Reference ASVS Requirements

Each requirement has an identifier in the format <chapter>.<section>.<requirement> where each element is a number, for example: 1.11.3:

• The <chapter> value corresponds to the chapter from which the requirement comes, for example: all 1.#.# requirements are from the Architecture chapter.
• The <section> value corresponds to the section within that chapter where the requirement appears, for example: all 1.11.# requirements are in the Business Logic Architecture section of the Architecture chapter.
• The <requirement> value identifies the specific requirement within the chapter and section, for example: 1.11.3 which as of version 4.0.3 of this standard is:

Verify that all high-value business logic flows, including authentication, session management and access control are thread safe and resistant to time-of-check and time-of-use race conditions.

The identifiers may change between versions of the standard therefore it is preferable that other documents, reports, or tools use the format: v<version>-<chapter>.<section>.<requirement>, where: 'version' is the ASVS version tag. For example: v4.0.3-1.11.3 would be understood to mean specifically the 3rd requirement in the 'Business Logic Architecture' section of the 'Architecture' chapter from version 4.0.3. (This could be summarized as v<version>-<requirement_identifier>.)

Note: The v preceding the version portion is to be lower case.

If identifiers are used without including the v<version> element then they should be assumed to refer to the latest Application Security Verification Standard content. Obviously as the standard grows and changes this becomes problematic, which is why writers or developers should include the version element.

License

The entire project content is under the Creative Commons Attribution-Share Alike v3.0 license.

asvs's Issues

17.22 is a duplicate of 17.14

Going to remove.

Please enumerate what's new in version 3.0

People using the former version 2.0, want to know what had changed so that they can update their policies.

Authentication - need a confirm old password section

I've found an app that doesn't have an old password when changing password.

I was surprised when I looked through ASVS that we don't explicitly say what makes a good passphrase change dialog:

Old passphrase
New passphrase
Confirm passphrase

2.9 seems the best place to put this in without creating a new finding, as I feel 2.9 is a bit wooly and non-specific / testable.

Thoughts?

Cryptography at rest chapter revision

Issue: The crypto chapters in ASVS have historically been unreviewable by professional code reviewers and unimplementable by professional developers.

Aim: Re-write the crypto at rest chapter to ensure code can be assessed for compliance, and that developers have clear guidance on what to implement correctly.

[V17 - Mobile Controls.xlsx] Verify that App manifest file doesn't contain Dailer secret code.

When entered into the dialer, this can lead to grant an access to hidden sensitive information.

Install the App
Go to phone app
Dial ##-------##
See hidden menu

Quick QA notes

Page 22:

V2.27 Verify that the use commonly chosen passwords ... are in place. Should be: are NOT in place?

Page 27:

V5.3 Missing full stop.

Page 28:

V5.21 "Verify that remove the unneeded "

Page 37:

V10.16 current leading practice I think current best practice makes more sense.

Page 39:

V11.13 X-CONTENT-TYPE-OPTIONS should be X-Content-Type-Options

Page 45:

V16.1 Verify that URL redirects and forwards only allow whitelisted destinations. I think it might be worth mentioning that it is also acceptable to redirect to non-whitelisted destinations if the user is warned first. This is what Facebook does. Something like V16.1 Verify that URL redirects and forwards only allow whitelisted destinations or show a user warning when redirecting to an untrusted domain.

Page 46:

Typo: Provide unqiue security requirements unique*

Page 47:

There is a check for ASLR. Would it be worth also adding a check for Position Independent Executable (PIE)?

Cryptography in transit

Issue: the crypo in transit chapter is practically impossible to verify. It's very old school J2EE centric, which doesn't help modern applications.

Solution:

Use the SSL/TLS threat model and best practice guides from Mozilla, Microsoft and Qualys to ensure that we have a reasonable set of controls, with adequate guideance to test these empirically from either a configuration or code point of view, as well as a simple set of references for developers to follow that will end up with a reasonable outcome from an ASVS assessment.

Platform issues such as certificate pinning and so on should be considered, but only to note that this should be a platform issue, rather than a developer temporary fix.

17.9 is missing some .

words. I can't believe we haven't been pinged on this yet.

17.16 and 17.17 are not mobile specific

It is unfortunate but common for PHP applications to be incorrectly configured with world writable access to the interpreted sources (A5 of the OWASP Top 10) or that old known vulnerable versions of libraries or frameworks are used (A9 of the OWASP Top 10).
Neither is a verification requirement for applications, only for mobile.

Table of Contents page numbers is off by 1 for everything after Application Security Verification Levels page 9

Table of Contents page numbers is off by 1 for everything after Application Security Verification Levels page 9

For example:
Level 0: Cursory show page 11 but in reality is page 10

17.3 - missing the "why" for this control

Doesn't say why the control is necessary. I'm going to add "potentially unencrypted" to the control

Appendix B page 44 – May want to write out Abbreviations for HTML and LDAP

Appendix B page 44 – May want to write out Abbreviations for HTML and LDAP

HTML – The main markup language for the creation of web pages and other information displayed in a web browser.

Write out HTML as HyperText Markup Language (HTML)

LDAP – An application protocol for accessing and maintaining distributed directory information services over a network.

Write out LDAP as Lightweight Directory Access Protocol (LDAP)

Page 31 - The Malicious Code Section wording as a bit difficult to read, wordy

Page 31 - The Malicious Code Section wording as a bit difficult to read, wordy

We should try to use positive wording

Examples:

V13.1 Verify that no malicious code is in any code that was either developed or modified in order to create the application.
V13.3 Verify that all code implementing or using authentication controls is not affected by any malicious code.
V13.6 Verify that all input validation controls are not affected by any malicious code.
V13.7 Verify that all code implementing or using output validation controls is not affected by any malicious code.

Possible Solutions:

13.1 Verify that the code used to develop or create the application is free of malicious code.

13.3 Verify that malicious code cannot affect code that implements or uses authentication controls

13.6 Verify that malicious code cannot affect input validation controls.

13.7 Verify that malicious code cannot affect code that implements or uses output validation controls.

“Affect” may be changed to, “interact with” or “impact”

4.9 - cleanup the word "role" and "such that"

I'd love to see "role" taken out of ASVS 2.0 v4.9

Consider changing:

V4.9 Verify that the same access control rules implied by the presentation layer are enforced on the server side for that user role, such that controls and parameters cannot be re-enabled or re-added from higher privilege users.

To....

V4.9 Verify that the same access control rules implied by the presentation layer are enforced on the server side.

Simple and clear wins the day.

Aloha,
Jim

Page 46 – Appendix C – May Want to Include the Actual MITRE Page Title

Page 46 – Appendix C – May Want to Include the Actual MITRE Page Title

MITRE - Common Weakness Enumeration – Vulnerability Trends, http://cwe.mitre.org/documents/vuln-trends.html

May want to remove the “,” and the actual page Title is “Vulnerability Type Distributions in CVE“

This and PCI Security Standards Council are the only ones that say why the site is useful

[V19 - Configuration Management.xlsx] Verify that back-up flag isn't available for the mobile App binary.

Appendix B - Page 46 – OWASP Testing Guide Link Should be Consistent

Appendix B - Page 46 – OWASP Testing Guide Link Should be Consistent

May consider changing the URL from http://www.owasp.org/index.php/Testing_Guide to https://www.owasp.org/index.php/OWASP_Testing_Project to be more direct

It would also then match the same link on page 44

Consider the differences between 4.9 and 4.11 and possibly merge

Hi,

What is the difference between:

V4.9. Verify that the same access control rules implied by the presentation layer are enforced on the server side for that user role, such that controls and parameters cannot be re-enabled or re-added from higher privilege users.

And:

V4.11. Verify that all access controls are enforced on the server side.

In fact I'm having a hard time seeing a scenario where I would fail V4.9.

Cheers,
Boy

17.5 - missing API tokens

I'm going to add API tokens to it

Appendix B - Page 46 - OWASP Top 10 Guide Link Should be Consistent

Appendix B - Page 46 - OWASP Top 10 Guide Link Should be Consistent

OWASP Top Ten Project - http://www.owasp.org/index.php/Top_10 this is different from the same on page 44

http://www.owasp.org/index.php/Top10

But it looks like the same page

Additionally should the Mobile top 10 be included since there is a big mobile section, V17?
https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks

Rename HTTP Configuration -> Configuration

17.2 - missing advertising IDs

It's too iOS -6.x specific.

V11.8 and V11.10 are duplicates

My apologies if this has already been brought up previously. The requirements V11.8 and V11.10 appear to be very similar in intent. Can anyone help me understand what the primary difference between them is?

V11.8: Verify that HTTP headers and / or other mechanisms for older browsers have been included to protect against clickjacking attacks.

V11.10: Verify that the HTTP header, X-Frame-Options is in use for sites where content should not be viewed in a 3rd-party X-Frame. A common middle ground is to send SAMEORIGIN, meaning only websites of the same origin may frame it.

Add client side encoding section

Data protection - add in assumption or requirement that the protecting is occuring on a trusted device

There is an unstated assumption in the Data Protection chapter that data protection is occurring on a trusted device. This is not always true.

I feel that we either need to make it clear that there is an assumption, or make it a requirement for Levels 2 and 3 that Data Protection is enforced on a trusted device, much in the same way as all other chapters.

It is unclear why there are “Skipped/Missing” verification requirements

It is unclear why there are “Skipped/Missing” verification requirements

It is unclear if the missing requirements were forgotten or have been removed.

It may help reader and user of ASVS to have either a generic paragraph stating why there are some missing or include the line and say something like “No longer relevant” or “Deleted from this version of ASVS”

The entire V6 verification is is not included any more.

The following verification requirements are missing or have been removed:
2.3
2.10
2.11
3.9
4.6
4.7
4.8
5.9
7.4
8.12
11.1

Mapping 1.0->2.0->2.1 table required

Hey folks,
Maybe I’ve missed this, but I’ve combed the list looking for an answer and haven’t come up with much. I’ve been trying to update a bunch of my stuff to align with the the new 2.0 document and I’m noticing that the numbering system is off. For example, There is no requirement V1, V6, V12, V14. And within most of the other ones, there are individual requirements missing, V2.3, V2.10, V2.11, and so forth in the other sections too.

I could understand if this was done to keep the requirements in the same slots, as the previous published versions, but even then, from version to version, the same requirements have moved, old V1.5 is now V2.17…

Was there a reason for all of this? On a side note, I’m also happy to help contribute to this project, as I’ve been using this standard for a while, and think it’s important, just let me know how I can help out.

Best Regards,
Gerrit Padgham

Page 14 – I am not sure I agree with having a 3.1 and 3.2 when this is the only Level that even mentions this.

Page 14 – I am not sure I agree with having a 3.1 and 3.2 when this is the only Level that even mentions this.

While each level has a variety of sub levels we need to group organizations in “bands” that best fit their maturity.

Could these 4 things be out into a level 3 item or do they really represent a level 4?

17.6 - Missing a level of detail

I think this issue applies to both Android and iOS - they both take screenshots and save the state of the application as they are backgrounded to make it appear like they are being re-hydrated faster than they actually are. I've put in a temporary fix, but I think we can make this much better.

17.2 Rewording

Currently 17.2 says:
"Verify that unique device ID (UDID) values are not used as security controls."

Prefer:
"Verify that ID values stored on the device and retrievable by other applications, such as the UDID or IMEI number are not used as authentication tokens."

Q about V7.13: PII refers to "personally identifiable information"?

Does PII refers to "personally identifiable information"?

Appendix A page 38-41 – Inconsistent Capitalization in the Suggested ASVS Level Description

Appendix A page 38-41 – Inconsistent Capitalization in the Suggested ASVS Level Description

Wording in the Suggested Level All start with a small character except for the ones in Retail, Food, Hospitality

For Example:
Level 1: all Internet-accessible applications.

Level 2: Suitable for business applications, product catalogue information, internal corporate information, and applications with limited user information (e.g. contact information). Applications with small or moderate amounts of payment data or checkout functionality.

Page 16 – List of Requirement Areas Should Match the Section Header Wording

Page 16 – List of Requirement Areas Should Match the Section Header Wording

Should “V11. HTTP“ be “V11. HTTP Security“ to match the category like the others?

Should “V16. File and Resource“ be “V16. Files and Resources“ to match the category like the others?

Renaming files in repository

Would it be possible to rename files by including a leading 0 (zero)
e.g.:
V2 - Authentication.xlsx
would be
V02 - Authentication.xlsx

this making it more logical ordering

Add - Architecture and Threat Modelling Chapter

Page 15 Scope of verification Misspelling Be should be By

Page 15 Scope of verification Misspelling Be should be By

Be default, ASVS assumes that the scope of the verification includes all code that was developed or modified in order to create the application or release.

Should be:

By default, ASVS assumes that the scope of the verification includes all code that was developed or modified in order to create the application or release.

Call out XSS explicitly in section 5.

XSS is not even mentioned, so where relevant, include without duplicating issues.

Duplicate Wording in Controls

Both V3.15 and V10.11 Talk about HSTS headers. I think V3.15 should be reduced to just the Secure Flag being set on the session tokens, using cookies, and then leave V10.11 as it is with the HSTS header.

TLS - additions

Please create new content in the old chapter.

The following terms are in the Appendix B but I cannot find them in the document Appendix B - Page 43-45

The following terms are in the Appendix B but I cannot find them in the document
Appendix B - Page 43-45

The following are not found in the document except here (it is unclear why they are here):
Application Component
Back Doors
Blacklist
Common Criteria
Internal Verification
Denial of Service (DOS) Attacks
Easter Eggs
OWASP Risk Rating Methodology
Salami Attack
Time Bomb
UAT
Also for UAT:

UAT – Traditionally a test environment that behaves like the production environment where all software testing is performed before going live.

Should UAT be also written out?

Also, if this is User Acceptance Testing I do not see how this is different from Integration or Validation environments. UAT many times is conducted in a validation environment.

May also want to add to the Appendix:
V17.21 Verify that the application makes use of Address Space Layout Randomization (ASLR).

Address Space Layout Randomization (ASLR) – A technique to help protect against buffer overflow attacks.

HTTP Configuration

Duplicate
CSP
Sniffing headers

Pls rephrase V2.27

"v2.27 Verify that the use of commonly chosen passwords and weak passphrases (such as “let me in” or “Password1!”) are in place."

"[] measures against the use [] are in place"
or
"[] use of [] are blocked"

Convert docx into Markdown

i.e. this file OWASP_ASVS_Version_2.docx

Data Protection - add in treatment plans

There are no treatment plans within the ASVS. We can't be specific but we also don't currently give any guidance.

4.17 - aggregate access control protection needs refactoring

This needs serious cleanup....

v4.17 Aggregate access control protection – verify the system can protect against aggregate or continuous access of secured functions, resources, or data. For example, possibly by the use of a resource governor to limit the number of edits per hour or to prevent the entire database from being scraped by an individual user.

perhaps...

v4.17 Verify the system can protect against aggregate or continuous access of secured functions, resources, or data. For example, consider the use of a resource governor to limit the number of edits per hour or to prevent the entire database from being scraped by an individual user.

Aloha,
Jim

Retire obfuscation and reverse engineering "controls"

Issue: ASVS has always been a "20% of the controls to cover 80% of the issue" standard. Reverse engineering and obfuscation are not controls, but delaying tactics for software that fits into a tiny corner case. Additionally, as an open standard, any control that requires a significant investment in third party tools to be compliant is unacceptable.

Remove all references to reverse engineering and obfuscation.
Align 17.7 with the results of OWASP Top M10 2015
Retire 17.11
Retire 17.25

To allow easy transition to 2.1, 17.11 and 11.25 should simply be blanked out to avoid a renumbering effort on the part of ASVS users and tools.

Encrypt before store clarification

Hi there!

I checked the ASVS version 2 document , and came across this at page 37 near the bottom:

“Verify that sensitive data is stored in a cryptographically secure manner (even when stored in the iOS keychain).”

If I’m interpreting it right, then ASVS is saying that I have to encrypt my data before storing it in the keychain. I use the iOS keychain, but I’ve never encrypted data before storing it in it. The reason that I always thought this would be particularly useless is that someone can find the encryption key by checking the binary data of my app’s code.

Am I missing something?

Kind regards,

Joris ten Tusscher

Addition to introduction - what skills do you need to use the ASVS

Hi all,

What skills, level or type of knowledge areas should have a team development to understand the requirements of ASVS?

Thanks in advance for your answers or ideas you can give me.

Best regards

Beto.

Ari said:

I think that is a very good question that we actually should focus more on later editions of the ASVS.

There are at least these things you need to consider:

• what are the most essential pieces of general knowledge the team must have, e.g. understanding the concept of injection or validation
• what coding principles are followed and why (defensive coding, complying with external or internal architecture standards etc — this of course varies but typically a team should have some guiding security and implementation principles, some of which are relatively universal)
• what does the team need to understand about the technology stack they’re using (and I think this is very important thing), that is, how does it work
• what parts of the ASVS are handled already by the technology stack (also an important thing to consider)

In practice, I would think that at the very least, the team needs to understand how HTTP works, how things like HTTP parameters and requests get handled in their application, and what an injection is (as a general concept, not just XSS and SQLi). Also they should have a clear concept how authorisation is supposed to work in the application and be able to validate that with the requirements. I’m less concerned about authentication, as it typically is handled by an external component and just kind of plugged in to the application.

I would put less emphasis on for example session handling (unless you do that in your application, which you shouldn’t) and cryptography (rarely needed). Proper configuration of cookies, secured connections etc. are important, but luckily they can be relatively easily fixed if the team doesn’t get them right already during development.

As for ASVS, would it make sense to somehow categorize verification items based on where they are (or should be) handled, e.g. infrastructure, middleware, program code, centralised libraries etc? Or maybe as part of the ASVS itself, but as a supplemental guide? I can help with this, although it is obvious that there’s no one single categorisation as it depends on what technology is used and how. But I still assert that typically a software development team should only consider a subset of the verification items, while other items are considered by other teams (e.g. infra).

Page 19 – Should V37 and V38 prevent the same issue?

Page 19 – Should V37 and V38 prevent the same issue?

V37 Verify that the session id is changed on login to prevent session fixation.
V38 Verify that the session id is changed upon re-authentication.

Should we add “to prevent session fixation.” To v38?

Add web service section