├── .gitignore ├── CONTRIBUTORS.md ├── README.md ├── current └── asvs.yaml ├── scripts └── generate-curriculum.py └── src └── asvs-4.0.2-en.txt /.gitignore: -------------------------------------------------------------------------------- 1 | # Byte-compiled / optimized / DLL files 2 | __pycache__/ 3 | *.py[cod] 4 | *$py.class 5 | 6 | # C extensions 7 | *.so 8 | 9 | # Distribution / packaging 10 | .Python 11 | build/ 12 | develop-eggs/ 13 | dist/ 14 | downloads/ 15 | eggs/ 16 | .eggs/ 17 | lib/ 18 | lib64/ 19 | parts/ 20 | sdist/ 21 | var/ 22 | wheels/ 23 | pip-wheel-metadata/ 24 | share/python-wheels/ 25 | *.egg-info/ 26 | .installed.cfg 27 | *.egg 28 | MANIFEST 29 | 30 | # PyInstaller 31 | # Usually these files are written by a python script from a template 32 | # before PyInstaller builds the exe, so as to inject date/other infos into it. 33 | *.manifest 34 | *.spec 35 | 36 | # Installer logs 37 | pip-log.txt 38 | pip-delete-this-directory.txt 39 | 40 | # Unit test / coverage reports 41 | htmlcov/ 42 | .tox/ 43 | .nox/ 44 | .coverage 45 | .coverage.* 46 | .cache 47 | nosetests.xml 48 | coverage.xml 49 | *.cover 50 | *.py,cover 51 | .hypothesis/ 52 | .pytest_cache/ 53 | 54 | # Translations 55 | *.mo 56 | *.pot 57 | 58 | # Django stuff: 59 | *.log 60 | local_settings.py 61 | db.sqlite3 62 | db.sqlite3-journal 63 | 64 | # Flask stuff: 65 | instance/ 66 | .webassets-cache 67 | 68 | # Scrapy stuff: 69 | .scrapy 70 | 71 | # Sphinx documentation 72 | docs/_build/ 73 | 74 | # PyBuilder 75 | target/ 76 | 77 | # Jupyter Notebook 78 | .ipynb_checkpoints 79 | 80 | # IPython 81 | profile_default/ 82 | ipython_config.py 83 | 84 | # pyenv 85 | .python-version 86 | 87 | # pipenv 88 | # According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control. 89 | # However, in case of collaboration, if having platform-specific dependencies or dependencies 90 | # having no cross-platform support, pipenv may install dependencies that don't work, or not 91 | # install all needed dependencies. 92 | #Pipfile.lock 93 | 94 | # PEP 582; used by e.g. github.com/David-OConnor/pyflow 95 | __pypackages__/ 96 | 97 | # Celery stuff 98 | celerybeat-schedule 99 | celerybeat.pid 100 | 101 | # SageMath parsed files 102 | *.sage.py 103 | 104 | # Environments 105 | .env 106 | .venv 107 | env/ 108 | venv/ 109 | ENV/ 110 | env.bak/ 111 | venv.bak/ 112 | 113 | # Spyder project settings 114 | .spyderproject 115 | .spyproject 116 | 117 | # Rope project settings 118 | .ropeproject 119 | 120 | # mkdocs documentation 121 | /site 122 | 123 | # Jetbrains 124 | .idea/ 125 | 126 | # mypy 127 | .mypy_cache/ 128 | .dmypy.json 129 | dmypy.json 130 | 131 | # Pyre type checker 132 | .pyre/ 133 | -------------------------------------------------------------------------------- /CONTRIBUTORS.md: -------------------------------------------------------------------------------- 1 | # Contributors 2 | Hello there, welcome. 3 | 4 | We're super excited that you're thinking of contributing, and helping improve this project. 5 | This project strives to help provide a structured learning pathway, and mappings of core concepts in Application Security for the community. 6 | 7 | We're all volunteers here, and we can only do so much in our spare time to make this world a little better. To help this project keep doing that, we all understand that by submitting a pull request agree to release your submission under Creative Commons Attribution-ShareAlike v4.0 to the OWASP Foundation, and that you had the rights to do so. 8 | 9 | ## Getting Started 10 | 11 | Contributions are being accepted via Pull Requests to this repository. 12 | If you are new to contributing via GitHub, Digital Ocean has [a pretty good guide](https://www.digitalocean.com/community/tutorials/how-to-create-a-pull-request-on-github) on how this works. If you need a primer on [how to use Git](https://docs.github.com/en/github/using-git), GitHub has some excellent guides. Please note, we do require [commit signing](https://docs.github.com/en/github/authenticating-to-github/about-commit-signature-verification) for merges to the main branch so please also configure that. 13 | 14 | Once a Pull Request is created, please allow a few days for the repository maintainers to review your submission. If you don't hear from us (in over a week), please reach out to us on the OWASP Slack in the #education-committee channel. 15 | 16 | ### Conventions and Norms 17 | 18 | - [ TO DO ] 19 | . 20 | 21 | 22 | ### What can I help with? 23 | 24 | Well, we're glad you asked. Thank you. 25 | Here are some suggestions, of things we need help with. Not a complete list, but, a start. 26 | 27 | - [STUFF TODO] 28 | 29 | 30 | # About this Repository 31 | ## Background 32 | 33 | To help identify the skills, and knowledge that is needed to perform the role of an Application Security Professional, we first look to the expected outcomes of such an individual. The clearest form these expectations are articulated are as Application Security Standards. 34 | 35 | The best example of a well adopted framework within the OWASP Foundation is the Application Security Verification Standard (ASVS). Through tight collaboration and support from the team behind the ASVS, it was elected as the first source standard that will inform this curriculum. 36 | 37 | To ensure the longevity and continued evolution of this project to fulfill the continually evolving needs and landscape of Application Security, we've taken a methododical approach, with an aspiration towards increased automation, to utilise multiple standards as sources to inform the outcome curriculum. 38 | 39 | Think of this as a mapping of AppSec Standards against [Bloom's Taxanomy](https://en.wikipedia.org/wiki/Bloom%27s_taxonomy) to help inform the level of educational learning objective a person needs to achieve to perform a specified task. As such some understanding of Bloom's taxonomy is going to be needed. Here are some resources; [BloomsTaxonomy.net](https://www.bloomstaxonomy.net/) and [[Wikipedia](https://en.wikipedia.org/wiki/Bloom%27s_taxonomy). 40 | 41 | . 42 | 43 | ### The Repository Structure 44 | The original source content (eg. ASVS) files are pulled from the project's source repository into the `src` directory. These source text files are then transformed into the corresponding `.yaml` files in `current` using the the scripts stored in `src`. 45 | 46 | Here's an overview of the repository structure: 47 | ``` 48 | ➜ Application-Security-Curriculum git:(master) tree 49 | . 50 | ├── README.md 51 | ├── current 52 | │   └── asvs.yaml 53 | ├── scripts 54 | │   └── generate-curriculum.py 55 | └── src 56 | └── asvs-4.0.2-en.txt 57 | 58 | ``` 59 | 60 | To provide educational guidance, we map each item of knowledge that needs to be taught from the `actions` to the level that needs to be taught/understood using [Bloom's Taxonomy](https://www.psia-nw.org/blooms-taxonomy-levels-of-understanding/). 61 | 62 | ![Bloom's Taxanomy](https://www.bloomstaxonomy.net/application/files/thumbnails/large/3315/8103/5712/Blooms-Taxonomy-650x366.jpg) 63 | 64 | In the data structure representing the `units` to be taught (shown in later sections) we use the representation where 65 | level `1` = `remember`, and 66 | level `6` = `create` 67 | 68 | 69 | 70 | ### What to do 71 | 72 | You will need to locate the source `.yaml` file, that the script has generated. In this case, the `asvs.yaml` file in the `current` folder. 73 | 74 | Transformation script outputs the follow: 75 | ``` 76 | - 77 | chapter_id: V2 78 | module: Authentication 79 | chapter_name: Authentication Verification Requirements 80 | section_id: V2.5 81 | section_name: Credential Recovery Requirements 82 | req_id: V2.5.1 83 | req_description: Verify that a system generated initial activation or recovery secret is not sent in clear text to the user. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) 84 | level1: ✓ 85 | level2: ✓ 86 | level3: ✓ 87 | cwe: 640 88 | nist: 5.1.1.2 89 | ``` 90 | 91 | The `contribution` focus right now is to add the following to the above. 92 | ``` 93 | units: 94 | - 95 | unit: '' 96 | terms: '' 97 | level: 98 | actions: 99 | - 100 | action: '' 101 | level: 102 | mappings: 103 | - 104 | notes: '' 105 | ``` 106 | So that the stucture is expanded like this example below: 107 | ``` 108 | chapter_id: V2 109 | module: Authentication 110 | chapter_name: Authentication Verification Requirements 111 | section_id: V2.5 112 | section_name: Credential Recovery Requirements 113 | req_id: V2.5.1 114 | req_description: Verify that a system generated initial activation or recovery secret is not sent in clear text to the user. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)) 115 | level1: ✓ 116 | level2: ✓ 117 | level3: ✓ 118 | cwe: 640 119 | nist: 5.1.1.2 120 | units: 121 | - 122 | unit: '' 123 | terms: '' 124 | level: 125 | actions: 126 | - 127 | action: '' 128 | level: 129 | mappings: 130 | - 131 | notes: '' 132 | ``` 133 | 134 | The above forms the skeleton for each "requirement" for the ASVS standard. 135 | 136 | Next, for each requirement, we'll need to deconstruct the requirements, so that we map them to corresponding learning `units`, such as the shown in the snippet below: 137 | 138 | ``` 139 | - 140 | chapter_id: V1 141 | module: Designing a Secure System 142 | chapter_name: Architecture, Design and Threat Modeling Requirements 143 | section_id: V1.5 144 | section_name: Input and Output Architectural Requirements 145 | req_id: V1.5.2 146 | req_description: Verify that serialization is not used when communicating with untrusted clients. If this is not possible, ensure that adequate integrity controls (and possibly encryption if sensitive data is sent) are enforced to prevent deserialization attacks including object injection. 147 | level1: 148 | level2: ✓ 149 | level3: ✓ 150 | cwe: 502 151 | nist: 152 | units: 153 | - 154 | unit: 'Data Security' 155 | terms: 156 | - 'serialization' 157 | - 'deserialization' 158 | - 'integrity controls' 159 | - 'encryption' 160 | - 'sensitive data' 161 | level: 5 162 | - 163 | unit: 'Network Security' 164 | terms: 165 | - 'communicating with untrusted clients' 166 | - 'encryption' 167 | level: 5 168 | - 169 | unit: 'Attack Types' 170 | terms: 171 | - 'deserialization attacks' 172 | - 'object injection' 173 | level: 5 174 | actions: 175 | - 176 | action: 'Verify that serialization is not used' 177 | level: 2 178 | mappings: 179 | - 'Data Security' 180 | - 'Network Security' 181 | - 182 | action: 'ensure that adequate' 183 | level: 5 184 | mappings: 185 | - 'Data Security' 186 | - 'Network Security' 187 | - 'Attack Types' 188 | notes: 'We should define "adequate controls" for using serialization with untrusted client, most likely referring to separate guidance from OWASP.' 189 | ``` 190 | 191 | Here's the current recommended approach to creating the necessary information. 192 | (If you have pedagogy background, we welcome your improvements) 193 | 194 | Using the example above this, we look at the `req_description` to determine the actions required of the person implementing the controls or the person reviewing it. 195 | 196 | Breaking down the requirements description: 197 | ``` 198 | Verify that serialization is not used when communicating with untrusted clients. If this is not possible, ensure that adequate integrity controls (and possibly encryption if sensitive data is sent) are enforced to prevent deserialization attacks including object injection. 199 | ``` 200 | 201 | We first identify the actions needed : 202 | Action 1: `Verify that serialization is not used` 203 | Action 2: `... ensure that adequate ...` 204 | 205 | Create a new action stub for each action identified. 206 | `action:` 207 | ``` 208 | - 209 | action: '' 210 | level: 211 | mappings: 212 | - 213 | ``` 214 | Based on the verbs being used, referencing Blooms' Taxonomy, and your AppSec knowledge, identify the minimum level of knowledge require to perform the task. 215 | 216 | Using `Action 1` as the example, we identify it to be a Level 2. 217 | To successfully complete this action, the person only needs to be able to identify, recognise, and classify that "serialization" is used. 218 | 219 | Thus, apply the number 2 label, as shown below: 220 | ``` 221 | actions: 222 | - 223 | action: 'Verify that serialization is not used' 224 | level: 2 225 | mappings: 226 | - 227 | ``` 228 | 229 | Next, we need to identify the `mappings`. 230 | These are predefined `units` that these actions are being "mapped" to. 231 | Refer to this mapping file (TODO @rewtd), for the list of units available to use. 232 | 233 | Based on your current understanding, list all relevant units that apply to that "action" from the mapping list. 234 | 235 | In this example, with the relevant study "units" (topics) we produce the following: 236 | ``` 237 | - 238 | action: 'Verify that serialization is not used' 239 | level: 2 240 | mappings: 241 | - 'Data Security' 242 | - 'Network Security' 243 | ``` 244 | 245 | Repeat this process until all actions are mapped. 246 | If there's any judgement calls, ambiguity and/or other notes, do add a notes section to the action. 247 | 248 | 249 | Then we move on to identifying the "units" and the knowledge level that needs to be acquired to fulfill the requirements. 250 | 251 | Taking a look at the `units` section: 252 | ``` 253 | units: 254 | - 255 | unit: 'Data Security' 256 | terms: 257 | - 'serialization' 258 | - 'deserialization' 259 | - 'integrity controls' 260 | - 'encryption' 261 | - 'sensitive data' 262 | level: 5 263 | - 264 | unit: 'Network Security' 265 | terms: 266 | - 'communicating with untrusted clients' 267 | - 'encryption' 268 | level: 5 269 | - 270 | unit: 'Attack Types' 271 | terms: 272 | - 'deserialization attacks' 273 | - 'object injection' 274 | level: 5 275 | ``` 276 | 277 | From the `actions` that needs to be taken by the person executing this requirement, we identify 3 `units` (topics) that need to be taught. 278 | 279 | They are `Data Security`, `Network Security` and `Attack Types`. 280 | Across all the `actions`, identify the key terms/phrases that appears in the requirements that relates to the corresponding topic. To identify the relevant terms, look at the text, identify the adverbs and nouns that define the scope of the statement. In the example above, they are: 281 | 282 | - 'serialization' 283 | - 'deserialization' 284 | - 'integrity controls' 285 | - 'encryption' 286 | - 'sensitive data' 287 | - 'communicating with untrusted clients' 288 | - 'encryption' 289 | - 'deserialization attacks' 290 | - 'object injection' 291 | 292 | Take for example, `Network Security`. In the text we identify the key phrases, `communicating with untrusted clients` and `encryption`. This maps onto the `units` section like this: 293 | ``` 294 | - 295 | unit: 'Network Security' 296 | terms: 297 | - 'communicating with untrusted clients' 298 | - 'encryption' 299 | ``` 300 | Repeat this for all `action`, and until all `unit` are done. 301 | 302 | Now, for the last bit. Looking back at the `action` that references a the `unit`, look for the highest level of knowledge required across all `unit` for this requirement. This will identify the highest level of knowledge required to fulfil this requirement and all the corresponding actions. 303 | 304 | Following the `Network Security` example, we identify that the highest level across all `action` is Level 5. So, we assign level 5 to this `unit` as follow: 305 | 306 | ``` 307 | - 308 | unit: 'Network Security' 309 | terms: 310 | - 'communicating with untrusted clients' 311 | - 'encryption' 312 | level: 5 313 | ``` 314 | Repeat until all `unit` is complete. 315 | Repeat until all requirements for the standard has been mapped. 316 | 317 | In short, the whole process is basically 318 | ``` 319 | Action words -> Blooms level req to do the action -> determine to highest bloom level to req understand. 320 | Terms - groups together the knowledge required --^ 321 | ``` 322 | This then produces a list of "Units" with corresponding levels of knowledge required to accomplish requirements of ASVS. 323 | 324 | It's a bit repetitive. 325 | If you've got a way to automate this process reliably, please do reach out. 326 | 327 | Thanks heaps for contributing. 328 | 329 | 330 | TODO: Keywords Mapping to be provided by @rewtd 331 | 332 | 333 | # Notes & References 334 | 335 | - https://www.teachthought.com/learning/a-simplified-blooms-taxonomy-poster-for-students/ 336 | - https://www.celt.iastate.edu/teaching/effective-teaching-practices/revised-blooms-taxonomy/blooms-revised-taxonomy-model/ 337 | 338 | 339 | # Thank you 340 | ## For authoring contributions 341 | 342 | - rewtd 343 | - hellodanielting 344 | 345 | 346 | 347 | ## For other supporting contributions 348 | 349 | - organsation name here - contribution [date] 350 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Application-Security-Curriculum 2 | 3 | [![Grant Ongers - Scaling AppSec through Education - DEF CON 29 AppSec Village](https://yt-embed.herokuapp.com/embed?v=5Rzfvs2Jde4)](https://www.youtube.com/watch?v=5Rzfvs2Jde4 "Grant Ongers - Scaling AppSec through Education - DEF CON 29 AppSec Village") 4 | -------------------------------------------------------------------------------- /scripts/generate-curriculum.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python3 2 | 3 | import argparse 4 | import os 5 | import yaml 6 | 7 | blooms = {1: 'Remember', 2: 'Understand', 3: 'Apply', 4: 'Analyze', 5: 'Evaluate', 6: 'Create'} 8 | 9 | 10 | def main(folder: str, single_source_file: str = None) -> None: 11 | # select source file to parse 12 | if single_source_file: 13 | data = source_load(single_source_file) 14 | 15 | if data: 16 | curriculum = {} 17 | for requirement in data: 18 | if requirement['module'] not in curriculum: 19 | print("New module found: {}, adding to curriculum".format(requirement['module'])) 20 | curriculum[requirement['module']] = {} 21 | 22 | module = curriculum[requirement['module']] 23 | 24 | if 'units' in requirement: 25 | print("Requirement {} has units".format(requirement['req_id'])) 26 | 27 | for unit in requirement['units']: 28 | try: 29 | if unit['unit']: 30 | if unit['unit'] in module: 31 | print("Unit '{}' already in module '{}'".format(unit['unit'], requirement['module'])) 32 | existing_unit = module[unit['unit']] 33 | 34 | # add these terms to existing terms for unit 35 | for term in unit['terms']: 36 | print("Processing term: {}".format(term)) 37 | if term in existing_unit: 38 | print("Term is already present in unit, updating knowledge level if needed") 39 | existing_unit[term] = max(existing_unit[term], unit['level']) 40 | else: 41 | print("Term not present in unit, adding") 42 | existing_unit[term] = unit['level'] 43 | else: 44 | # add unit and terms to module 45 | print("New unit: {}".format(unit['unit'])) 46 | module[unit['unit']] = {term: unit['level'] for term in unit['terms']} 47 | except KeyError: 48 | print("Requirement {} has a malformed concepts list".format(requirement['req_id'])) 49 | else: 50 | pass 51 | 52 | print(curriculum) 53 | else: 54 | for discovered_source_file in os.scandir(folder): 55 | current_source = source_load(discovered_source_file) 56 | 57 | 58 | def source_load(file_to_load: str) -> object: 59 | data = None 60 | with open(file_to_load, 'r') as stream: 61 | try: 62 | data = yaml.safe_load(stream) 63 | except yaml.YAMLError as exc: 64 | print(exc) 65 | 66 | return data 67 | 68 | 69 | if __name__ == "__main__": 70 | # get absolute path to this script for walking this repo 71 | script_directory = os.path.dirname(os.path.abspath(__file__)) 72 | source_directory = os.path.normpath(os.path.join(script_directory, "../src")) 73 | 74 | parser = argparse.ArgumentParser(description="Parse source files for YAML output.") 75 | parser.add_argument( 76 | "-s", 77 | "--source-file", 78 | type=str, 79 | default="", 80 | help="source files to parse to update yaml from.", 81 | ) 82 | 83 | args = parser.parse_args() 84 | main(source_directory, args.source_file) 85 | -------------------------------------------------------------------------------- /src/asvs-4.0.2-en.txt: -------------------------------------------------------------------------------- 1 | chapter_id,chapter_name,section_id,section_name,req_id,req_description,level1,level2,level3,cwe,nist 2 | V1,"Architecture, Design and Threat Modeling Requirements",V1.1,Secure Software Development Lifecycle Requirements,V1.1.1,Verify the use of a secure software development lifecycle that addresses security in all stages of development. ([C1](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,, 3 | V1,"Architecture, Design and Threat Modeling Requirements",V1.1,Secure Software Development Lifecycle Requirements,V1.1.2,"Verify the use of threat modeling for every design change or sprint planning to identify threats, plan for countermeasures, facilitate appropriate risk responses, and guide security testing.",,✓,✓,1053, 4 | V1,"Architecture, Design and Threat Modeling Requirements",V1.1,Secure Software Development Lifecycle Requirements,V1.1.3,"Verify that all user stories and features contain functional security constraints, such as ""As a user, I should be able to view and edit my profile. I should not be able to view or edit anyone else's profile""",,✓,✓,1110, 5 | V1,"Architecture, Design and Threat Modeling Requirements",V1.1,Secure Software Development Lifecycle Requirements,V1.1.4,"Verify documentation and justification of all the application's trust boundaries, components, and significant data flows.",,✓,✓,1059, 6 | V1,"Architecture, Design and Threat Modeling Requirements",V1.1,Secure Software Development Lifecycle Requirements,V1.1.5,Verify definition and security analysis of the application's high-level architecture and all connected remote services. ([C1](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,1059, 7 | V1,"Architecture, Design and Threat Modeling Requirements",V1.1,Secure Software Development Lifecycle Requirements,V1.1.6,"Verify implementation of centralized, simple (economy of design), vetted, secure, and reusable security controls to avoid duplicate, missing, ineffective, or insecure controls. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,637, 8 | V1,"Architecture, Design and Threat Modeling Requirements",V1.1,Secure Software Development Lifecycle Requirements,V1.1.7,"Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers.",,✓,✓,637, 9 | V1,"Architecture, Design and Threat Modeling Requirements",V1.2,Authentication Architectural Requirements,V1.2.1,"Verify the use of unique or special low-privilege operating system accounts for all application components, services, and servers. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,250, 10 | V1,"Architecture, Design and Threat Modeling Requirements",V1.2,Authentication Architectural Requirements,V1.2.2,"Verify that communications between application components, including APIs, middleware and data layers, are authenticated. Components should have the least necessary privileges needed. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,306, 11 | V1,"Architecture, Design and Threat Modeling Requirements",V1.2,Authentication Architectural Requirements,V1.2.3,"Verify that the application uses a single vetted authentication mechanism that is known to be secure, can be extended to include strong authentication, and has sufficient logging and monitoring to detect account abuse or breaches.",,✓,✓,306, 12 | V1,"Architecture, Design and Threat Modeling Requirements",V1.2,Authentication Architectural Requirements,V1.2.4,"Verify that all authentication pathways and identity management APIs implement consistent authentication security control strength, such that there are no weaker alternatives per the risk of the application.",,✓,✓,306, 13 | V1,"Architecture, Design and Threat Modeling Requirements",V1.4,Access Control Architectural Requirements,V1.4.1,"Verify that trusted enforcement points such as at access control gateways, servers, and serverless functions enforce access controls. Never enforce access controls on the client.",,✓,✓,602, 14 | V1,"Architecture, Design and Threat Modeling Requirements",V1.4,Access Control Architectural Requirements,V1.4.2,Verify that the chosen access control solution is flexible enough to meet the application's needs. ,,✓,✓,284, 15 | V1,"Architecture, Design and Threat Modeling Requirements",V1.4,Access Control Architectural Requirements,V1.4.3,"Verify enforcement of the principle of least privilege in functions, data files, URLs, controllers, services, and other resources. This implies protection against spoofing and elevation of privilege.",,✓,✓,272, 16 | V1,"Architecture, Design and Threat Modeling Requirements",V1.4,Access Control Architectural Requirements,V1.4.4,Verify the application uses a single and well-vetted access control mechanism for accessing protected data and resources. All requests must pass through this single mechanism to avoid copy and paste or insecure alternative paths. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,284, 17 | V1,"Architecture, Design and Threat Modeling Requirements",V1.4,Access Control Architectural Requirements,V1.4.5,Verify that attribute or feature-based access control is used whereby the code checks the user's authorization for a feature/data item rather than just their role. Permissions should still be allocated using roles. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,275, 18 | V1,"Architecture, Design and Threat Modeling Requirements",V1.5,Input and Output Architectural Requirements,V1.5.1,"Verify that input and output requirements clearly define how to handle and process data based on type, content, and applicable laws, regulations, and other policy compliance. ",,✓,✓,1029, 19 | V1,"Architecture, Design and Threat Modeling Requirements",V1.5,Input and Output Architectural Requirements,V1.5.2,"Verify that serialization is not used when communicating with untrusted clients. If this is not possible, ensure that adequate integrity controls (and possibly encryption if sensitive data is sent) are enforced to prevent deserialization attacks including object injection.",,✓,✓,502, 20 | V1,"Architecture, Design and Threat Modeling Requirements",V1.5,Input and Output Architectural Requirements,V1.5.3,Verify that input validation is enforced on a trusted service layer. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,602, 21 | V1,"Architecture, Design and Threat Modeling Requirements",V1.5,Input and Output Architectural Requirements,V1.5.4,Verify that output encoding occurs close to or by the interpreter for which it is intended. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,116, 22 | V1,"Architecture, Design and Threat Modeling Requirements",V1.6,Cryptographic Architectural Requirements,V1.6.1,Verify that there is an explicit policy for management of cryptographic keys and that a cryptographic key lifecycle follows a key management standard such as NIST SP 800-57.,,✓,✓,320, 23 | V1,"Architecture, Design and Threat Modeling Requirements",V1.6,Cryptographic Architectural Requirements,V1.6.2,Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives.,,✓,✓,320, 24 | V1,"Architecture, Design and Threat Modeling Requirements",V1.6,Cryptographic Architectural Requirements,V1.6.3,Verify that all keys and passwords are replaceable and are part of a well-defined process to re-encrypt sensitive data.,,✓,✓,320, 25 | V1,"Architecture, Design and Threat Modeling Requirements",V1.6,Cryptographic Architectural Requirements,V1.6.4,"Verify that the architecture treats client-side secrets--such as symmetric keys, passwords, or API tokens--as insecure and never uses them to protect or access sensitive data.",,✓,✓,320, 26 | V1,"Architecture, Design and Threat Modeling Requirements",V1.7,"Errors, Logging and Auditing Architectural Requirements",V1.7.1,Verify that a common logging format and approach is used across the system. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,1009, 27 | V1,"Architecture, Design and Threat Modeling Requirements",V1.7,"Errors, Logging and Auditing Architectural Requirements",V1.7.2,"Verify that logs are securely transmitted to a preferably remote system for analysis, detection, alerting, and escalation. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,, 28 | V1,"Architecture, Design and Threat Modeling Requirements",V1.8,Data Protection and Privacy Architectural Requirements,V1.8.1,Verify that all sensitive data is identified and classified into protection levels.,,✓,✓,, 29 | V1,"Architecture, Design and Threat Modeling Requirements",V1.8,Data Protection and Privacy Architectural Requirements,V1.8.2,"Verify that all protection levels have an associated set of protection requirements, such as encryption requirements, integrity requirements, retention, privacy and other confidentiality requirements, and that these are applied in the architecture.",,✓,✓,, 30 | V1,"Architecture, Design and Threat Modeling Requirements",V1.9,Communications Architectural Requirements,V1.9.1,"Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,319, 31 | V1,"Architecture, Design and Threat Modeling Requirements",V1.9,Communications Architectural Requirements,V1.9.2,"Verify that application components verify the authenticity of each side in a communication link to prevent person-in-the-middle attacks. For example, application components should validate TLS certificates and chains.",,✓,✓,295, 32 | V1,"Architecture, Design and Threat Modeling Requirements",V1.10,Malicious Software Architectural Requirements,V1.10.1,"Verify that a source code control system is in use, with procedures to ensure that check-ins are accompanied by issues or change tickets. The source code control system should have access control and identifiable users to allow traceability of any changes.",,✓,✓,284, 33 | V1,"Architecture, Design and Threat Modeling Requirements",V1.11,Business Logic Architectural Requirements,V1.11.1,Verify the definition and documentation of all application components in terms of the business or security functions they provide.,,✓,✓,1059, 34 | V1,"Architecture, Design and Threat Modeling Requirements",V1.11,Business Logic Architectural Requirements,V1.11.2,"Verify that all high-value business logic flows, including authentication, session management and access control, do not share unsynchronized state.",,✓,✓,362, 35 | V1,"Architecture, Design and Threat Modeling Requirements",V1.11,Business Logic Architectural Requirements,V1.11.3,"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.",,,✓,367, 36 | V1,"Architecture, Design and Threat Modeling Requirements",V1.12,Secure File Upload Architectural Requirements,V1.12.1,Verify that user-uploaded files are stored outside of the web root.,,✓,✓,552, 37 | V1,"Architecture, Design and Threat Modeling Requirements",V1.12,Secure File Upload Architectural Requirements,V1.12.2,"Verify that user-uploaded files - if required to be displayed or downloaded from the application - are served by either octet stream downloads, or from an unrelated domain, such as a cloud file storage bucket. Implement a suitable Content Security Policy (CSP) to reduce the risk from XSS vectors or other attacks from the uploaded file.",,✓,✓,646, 38 | V1,"Architecture, Design and Threat Modeling Requirements",V1.14,Configuration Architectural Requirements,V1.14.1,"Verify the segregation of components of differing trust levels through well-defined security controls, firewall rules, API gateways, reverse proxies, cloud-based security groups, or similar mechanisms.",,✓,✓,923, 39 | V1,"Architecture, Design and Threat Modeling Requirements",V1.14,Configuration Architectural Requirements,V1.14.2,"Verify that binary signatures, trusted connections, and verified endpoints are used to deploy binaries to remote devices.",,✓,✓,494, 40 | V1,"Architecture, Design and Threat Modeling Requirements",V1.14,Configuration Architectural Requirements,V1.14.3,Verify that the build pipeline warns of out-of-date or insecure components and takes appropriate actions.,,✓,✓,1104, 41 | V1,"Architecture, Design and Threat Modeling Requirements",V1.14,Configuration Architectural Requirements,V1.14.4,"Verify that the build pipeline contains a build step to automatically build and verify the secure deployment of the application, particularly if the application infrastructure is software defined, such as cloud environment build scripts.",,✓,✓,, 42 | V1,"Architecture, Design and Threat Modeling Requirements",V1.14,Configuration Architectural Requirements,V1.14.5,"Verify that application deployments adequately sandbox, containerize and/or isolate at the network level to delay and deter attackers from attacking other applications, especially when they are performing sensitive or dangerous actions such as deserialization. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,265, 43 | V1,"Architecture, Design and Threat Modeling Requirements",V1.14,Configuration Architectural Requirements,V1.14.6,"Verify the application does not use unsupported, insecure, or deprecated client-side technologies such as NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets.",,✓,✓,477, 44 | V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.1,Verify that user set passwords are at least 12 characters in length (after multiple spaces are combined). ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,521,5.1.1.2 45 | V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.2,Verify that passwords 64 characters or longer are permitted but may be no longer than 128 characters. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,521,5.1.1.2 46 | V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.3,"Verify that password truncation is not performed. However, consecutive multiple spaces may be replaced by a single space. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,521,5.1.1.2 47 | V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.4,"Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords.",✓,✓,✓,521,5.1.1.2 48 | V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.5,Verify users can change their password.,✓,✓,✓,620,5.1.1.2 49 | V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.6,Verify that password change functionality requires the user's current and new password.,✓,✓,✓,620,5.1.1.2 50 | V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.7,"Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords either locally (such as the top 1,000 or 10,000 most common passwords which match the system's password policy) or using an external API. If using an API a zero knowledge proof or other mechanism should be used to ensure that the plain text password is not sent or used in verifying the breach status of the password. If the password is breached, the application must require the user to set a new non-breached password. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,521,5.1.1.2 51 | V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.8,Verify that a password strength meter is provided to help users set a stronger password.,✓,✓,✓,521,5.1.1.2 52 | V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.9,Verify that there are no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,521,5.1.1.2 53 | V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.10,Verify that there are no periodic credential rotation or password history requirements.,✓,✓,✓,263,5.1.1.2 54 | V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.11,"Verify that ""paste"" functionality, browser password helpers, and external password managers are permitted.",✓,✓,✓,521,5.1.1.2 55 | V2,Authentication Verification Requirements,V2.1,Password Security Requirements,V2.1.12,"Verify that the user can choose to either temporarily view the entire masked password, or temporarily view the last typed character of the password on platforms that do not have this as built-in functionality.",✓,✓,✓,521,5.1.1.2 56 | V2,Authentication Verification Requirements,V2.2,General Authenticator Requirements,V2.2.1,"Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unlock the account, or similar. Verify that no more than 100 failed attempts per hour is possible on a single account.",✓,✓,✓,307,5.2.2 / 5.1.1.2 / 5.1.4.2 / 5.1.5.2 57 | V2,Authentication Verification Requirements,V2.2,General Authenticator Requirements,V2.2.2,"Verify that the use of weak authenticators (such as SMS and email) is limited to secondary verification and transaction approval and not as a replacement for more secure authentication methods. Verify that stronger methods are offered before weak methods, users are aware of the risks, or that proper measures are in place to limit the risks of account compromise.",✓,✓,✓,304,5.2.10 58 | V2,Authentication Verification Requirements,V2.2,General Authenticator Requirements,V2.2.3,"Verify that secure notifications are sent to users after updates to authentication details, such as credential resets, email or address changes, logging in from unknown or risky locations. The use of push notifications - rather than SMS or email - is preferred, but in the absence of push notifications, SMS or email is acceptable as long as no sensitive information is disclosed in the notification.",✓,✓,✓,620, 59 | V2,Authentication Verification Requirements,V2.2,General Authenticator Requirements,V2.2.4,"Verify impersonation resistance against phishing, such as the use of multi-factor authentication, cryptographic devices with intent (such as connected keys with a push to authenticate), or at higher AAL levels, client-side certificates.",,,✓,308,5.2.5 60 | V2,Authentication Verification Requirements,V2.2,General Authenticator Requirements,V2.2.5,"Verify that where a Credential Service Provider (CSP) and the application verifying authentication are separated, mutually authenticated TLS is in place between the two endpoints.",,,✓,319,5.2.6 61 | V2,Authentication Verification Requirements,V2.2,General Authenticator Requirements,V2.2.6,"Verify replay resistance through the mandated use of One-time Passwords (OTP) devices, cryptographic authenticators, or lookup codes.",,,✓,308,5.2.8 62 | V2,Authentication Verification Requirements,V2.2,General Authenticator Requirements,V2.2.7,Verify intent to authenticate by requiring the entry of an OTP token or user-initiated action such as a button press on a FIDO hardware key.,,,✓,308,5.2.9 63 | V2,Authentication Verification Requirements,V2.3,Authenticator Lifecycle Requirements,V2.3.1,"Verify system generated initial passwords or activation codes SHOULD be securely randomly generated, SHOULD be at least 6 characters long, and MAY contain letters and numbers, and expire after a short period of time. These initial secrets must not be permitted to become the long term password.",✓,✓,✓,330,5.1.1.2 / A.3 64 | V2,Authentication Verification Requirements,V2.3,Authenticator Lifecycle Requirements,V2.3.2,"Verify that enrollment and use of subscriber-provided authentication devices are supported, such as a U2F or FIDO tokens.",,✓,✓,308,6.1.3 65 | V2,Authentication Verification Requirements,V2.3,Authenticator Lifecycle Requirements,V2.3.3,Verify that renewal instructions are sent with sufficient time to renew time bound authenticators.,,✓,✓,287,6.1.4 66 | V2,Authentication Verification Requirements,V2.4,Credential Storage Requirements,V2.4.1,"Verify that passwords are stored in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using an approved one-way key derivation or password hashing function. Key derivation and password hashing functions take a password, a salt, and a cost factor as inputs when generating a password hash. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,916,5.1.1.2 67 | V2,Authentication Verification Requirements,V2.4,Credential Storage Requirements,V2.4.2,"Verify that the salt is at least 32 bits in length and be chosen arbitrarily to minimize salt value collisions among stored hashes. For each credential, a unique salt value and the resulting hash SHALL be stored. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,916,5.1.1.2 68 | V2,Authentication Verification Requirements,V2.4,Credential Storage Requirements,V2.4.3,"Verify that if PBKDF2 is used, the iteration count SHOULD be as large as verification server performance will allow, typically at least 100,000 iterations. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,916,5.1.1.2 69 | V2,Authentication Verification Requirements,V2.4,Credential Storage Requirements,V2.4.4,"Verify that if bcrypt is used, the work factor SHOULD be as large as verification server performance will allow, typically at least 13. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,916,5.1.1.2 70 | V2,Authentication Verification Requirements,V2.4,Credential Storage Requirements,V2.4.5,"Verify that an additional iteration of a key derivation function is performed, using a salt value that is secret and known only to the verifier. Generate the salt value using an approved random bit generator [SP 800-90Ar1] and provide at least the minimum security strength specified in the latest revision of SP 800-131A. The secret salt value SHALL be stored separately from the hashed passwords (e.g., in a specialized device like a hardware security module).",,✓,✓,916,5.1.1.2 71 | V2,Authentication Verification Requirements,V2.5,Credential Recovery Requirements,V2.5.1,Verify that a system generated initial activation or recovery secret is not sent in clear text to the user. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,640,5.1.1.2 72 | V2,Authentication Verification Requirements,V2.5,Credential Recovery Requirements,V2.5.2,"Verify password hints or knowledge-based authentication (so-called ""secret questions"") are not present.",✓,✓,✓,640,5.1.1.2 73 | V2,Authentication Verification Requirements,V2.5,Credential Recovery Requirements,V2.5.3,Verify password credential recovery does not reveal the current password in any way. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,640,5.1.1.2 74 | V2,Authentication Verification Requirements,V2.5,Credential Recovery Requirements,V2.5.4,"Verify shared or default accounts are not present (e.g. ""root"", ""admin"", or ""sa"").",✓,✓,✓,16,5.1.1.2 / A.3 75 | V2,Authentication Verification Requirements,V2.5,Credential Recovery Requirements,V2.5.5,"Verify that if an authentication factor is changed or replaced, that the user is notified of this event.",✓,✓,✓,304,6.1.2.3 76 | V2,Authentication Verification Requirements,V2.5,Credential Recovery Requirements,V2.5.6,"Verify forgotten password, and other recovery paths use a secure recovery mechanism, such as time-based OTP (TOTP) or other soft token, mobile push, or another offline recovery mechanism. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,640,5.1.1.2 77 | V2,Authentication Verification Requirements,V2.5,Credential Recovery Requirements,V2.5.7,"Verify that if OTP or multi-factor authentication factors are lost, that evidence of identity proofing is performed at the same level as during enrollment.",,✓,✓,308,6.1.2.3 78 | V2,Authentication Verification Requirements,V2.6,Look-up Secret Verifier Requirements,V2.6.1,Verify that lookup secrets can be used only once.,,✓,✓,308,5.1.2.2 79 | V2,Authentication Verification Requirements,V2.6,Look-up Secret Verifier Requirements,V2.6.2,"Verify that lookup secrets have sufficient randomness (112 bits of entropy), or if less than 112 bits of entropy, salted with a unique and random 32-bit salt and hashed with an approved one-way hash.",,✓,✓,330,5.1.2.2 80 | V2,Authentication Verification Requirements,V2.6,Look-up Secret Verifier Requirements,V2.6.3,"Verify that lookup secrets are resistant to offline attacks, such as predictable values.",,✓,✓,310,5.1.2.2 81 | V2,Authentication Verification Requirements,V2.7,Out of Band Verifier Requirements,V2.7.1,"Verify that clear text out of band (NIST ""restricted"") authenticators, such as SMS or PSTN, are not offered by default, and stronger alternatives such as push notifications are offered first.",✓,✓,✓,287,5.1.3.2 82 | V2,Authentication Verification Requirements,V2.7,Out of Band Verifier Requirements,V2.7.2,"Verify that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes.",✓,✓,✓,287,5.1.3.2 83 | V2,Authentication Verification Requirements,V2.7,Out of Band Verifier Requirements,V2.7.3,"Verify that the out of band verifier authentication requests, codes, or tokens are only usable once, and only for the original authentication request.",✓,✓,✓,287,5.1.3.2 84 | V2,Authentication Verification Requirements,V2.7,Out of Band Verifier Requirements,V2.7.4,Verify that the out of band authenticator and verifier communicates over a secure independent channel.,✓,✓,✓,523,5.1.3.2 85 | V2,Authentication Verification Requirements,V2.7,Out of Band Verifier Requirements,V2.7.5,Verify that the out of band verifier retains only a hashed version of the authentication code.,,✓,✓,256,5.1.3.2 86 | V2,Authentication Verification Requirements,V2.7,Out of Band Verifier Requirements,V2.7.6,"Verify that the initial authentication code is generated by a secure random number generator, containing at least 20 bits of entropy (typically a six digital random number is sufficient).",,✓,✓,310,5.1.3.2 87 | V2,Authentication Verification Requirements,V2.8,Single or Multi-factor One Time Verifier Requirements,V2.8.1,Verify that time-based OTPs have a defined lifetime before expiring.,✓,✓,✓,613,5.1.4.2 / 5.1.5.2 88 | V2,Authentication Verification Requirements,V2.8,Single or Multi-factor One Time Verifier Requirements,V2.8.2,"Verify that symmetric keys used to verify submitted OTPs are highly protected, such as by using a hardware security module or secure operating system based key storage.",,✓,✓,320,5.1.4.2 / 5.1.5.2 89 | V2,Authentication Verification Requirements,V2.8,Single or Multi-factor One Time Verifier Requirements,V2.8.3,"Verify that approved cryptographic algorithms are used in the generation, seeding, and verification of OTPs.",,✓,✓,326,5.1.4.2 / 5.1.5.2 90 | V2,Authentication Verification Requirements,V2.8,Single or Multi-factor One Time Verifier Requirements,V2.8.4,Verify that time-based OTP can be used only once within the validity period.,,✓,✓,287,5.1.4.2 / 5.1.5.2 91 | V2,Authentication Verification Requirements,V2.8,Single or Multi-factor One Time Verifier Requirements,V2.8.5,"Verify that if a time-based multi-factor OTP token is re-used during the validity period, it is logged and rejected with secure notifications being sent to the holder of the device.",,✓,✓,287,5.1.5.2 92 | V2,Authentication Verification Requirements,V2.8,Single or Multi-factor One Time Verifier Requirements,V2.8.6,"Verify physical single-factor OTP generator can be revoked in case of theft or other loss. Ensure that revocation is immediately effective across logged in sessions, regardless of location.",,✓,✓,613,5.2.1 93 | V2,Authentication Verification Requirements,V2.8,Single or Multi-factor One Time Verifier Requirements,V2.8.7,Verify that biometric authenticators are limited to use only as secondary factors in conjunction with either something you have and something you know.,,o,✓,308,5.2.3 94 | V2,Authentication Verification Requirements,V2.9,Cryptographic Software and Devices Verifier Requirements,V2.9.1,"Verify that cryptographic keys used in verification are stored securely and protected against disclosure, such as using a Trusted Platform Module (TPM) or Hardware Security Module (HSM), or an OS service that can use this secure storage.",,✓,✓,320,5.1.7.2 95 | V2,Authentication Verification Requirements,V2.9,Cryptographic Software and Devices Verifier Requirements,V2.9.2,"Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device.",,✓,✓,330,5.1.7.2 96 | V2,Authentication Verification Requirements,V2.9,Cryptographic Software and Devices Verifier Requirements,V2.9.3,"Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.",,✓,✓,327,5.1.7.2 97 | V2,Authentication Verification Requirements,V2.10,Service Authentication Requirements,V2.10.1,"Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys or shared accounts with privileged access.",,OS assisted,HSM,287,5.1.1.1 98 | V2,Authentication Verification Requirements,V2.10,Service Authentication Requirements,V2.10.2,"Verify that if passwords are required for service authentication, the service account used is not a default credential. (e.g. root/root or admin/admin are default in some services during installation).",,OS assisted,HSM,255,5.1.1.1 99 | V2,Authentication Verification Requirements,V2.10,Service Authentication Requirements,V2.10.3,"Verify that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access.",,OS assisted,HSM,522,5.1.1.1 100 | V2,Authentication Verification Requirements,V2.10,Service Authentication Requirements,V2.10.4,"Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage SHOULD resist offline attacks. The use of a secure software key store (L1), hardware TPM, or an HSM (L3) is recommended for password storage.",,OS assisted,HSM,798, 101 | V3,Session Management Verification Requirements,V3.1,Fundamental Session Management Requirements,V3.1.1,Verify the application never reveals session tokens in URL parameters. ,✓,✓,✓,598, 102 | V3,Session Management Verification Requirements,V3.2,Session Binding Requirements,V3.2.1,Verify the application generates a new session token on user authentication. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,384,7.1 103 | V3,Session Management Verification Requirements,V3.2,Session Binding Requirements,V3.2.2,Verify that session tokens possess at least 64 bits of entropy. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,331,7.1 104 | V3,Session Management Verification Requirements,V3.2,Session Binding Requirements,V3.2.3,Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage.,✓,✓,✓,539,7.1 105 | V3,Session Management Verification Requirements,V3.2,Session Binding Requirements,V3.2.4,Verify that session token are generated using approved cryptographic algorithms. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,331,7.1 106 | V3,Session Management Verification Requirements,V3.3,Session Logout and Timeout Requirements,V3.3.1,"Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,613,7.1 107 | V3,Session Management Verification Requirements,V3.3,Session Logout and Timeout Requirements,V3.3.2,"If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",30 days,"12 hours or 30 minutes of inactivity, 2FA optional","12 hours or 15 minutes of inactivity, with 2FA",613,7.2 108 | V3,Session Management Verification Requirements,V3.3,Session Logout and Timeout Requirements,V3.3.3,"Verify that the application gives the option to terminate all other active sessions after a successful password change (including change via password reset/recovery), and that this is effective across the application, federated login (if present), and any relying parties.",,✓,✓,613, 109 | V3,Session Management Verification Requirements,V3.3,Session Logout and Timeout Requirements,V3.3.4,Verify that users are able to view and (having re-entered login credentials) log out of any or all currently active sessions and devices.,,✓,✓,613,7.1 110 | V3,Session Management Verification Requirements,V3.4,Cookie-based Session Management,V3.4.1,Verify that cookie-based session tokens have the 'Secure' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,614,7.1.1 111 | V3,Session Management Verification Requirements,V3.4,Cookie-based Session Management,V3.4.2,Verify that cookie-based session tokens have the 'HttpOnly' attribute set. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,1004,7.1.1 112 | V3,Session Management Verification Requirements,V3.4,Cookie-based Session Management,V3.4.3,Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,16,7.1.1 113 | V3,Session Management Verification Requirements,V3.4,Cookie-based Session Management,V3.4.4,"Verify that cookie-based session tokens use ""__Host-"" prefix (see references) to provide session cookie confidentiality.",✓,✓,✓,16,7.1.1 114 | V3,Session Management Verification Requirements,V3.4,Cookie-based Session Management,V3.4.5,"Verify that if the application is published under a domain name with other applications that set or use session cookies that might override or disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible. ([C6](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,16,7.1.1 115 | V3,Session Management Verification Requirements,V3.5,Token-based Session Management,V3.5.1,Verify the application allows users to revoke OAuth tokens that form trust relationships with linked applications. ,,✓,✓,290,7.1.2 116 | V3,Session Management Verification Requirements,V3.5,Token-based Session Management,V3.5.2,"Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations.",,✓,✓,798, 117 | V3,Session Management Verification Requirements,V3.5,Token-based Session Management,V3.5.3,"Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks.",,✓,✓,345, 118 | V3,Session Management Verification Requirements,V3.6,Re-authentication from a Federation or Assertion,V3.6.1,Verify that relying parties specify the maximum authentication time to Credential Service Providers (CSPs) and that CSPs re-authenticate the subscriber if they haven't used a session within that period.,,,✓,613,7.2.1 119 | V3,Session Management Verification Requirements,V3.6,Re-authentication from a Federation or Assertion,V3.6.2,"Verify that Credential Service Providers (CSPs) inform Relying Parties (RPs) of the last authentication event, to allow RPs to determine if they need to re-authenticate the user.",,,✓,613,7.2.1 120 | V3,Session Management Verification Requirements,V3.7,Defenses Against Session Management Exploits,V3.7.1,"Verify the application ensures a full, valid login session or requires re-authentication or secondary verification before allowing any sensitive transactions or account modifications.",✓,✓,✓,306, 121 | V4,Access Control Verification Requirements,V4.1,General Access Control Design,V4.1.1,"Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.",✓,✓,✓,602, 122 | V4,Access Control Verification Requirements,V4.1,General Access Control Design,V4.1.2,Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.,✓,✓,✓,639, 123 | V4,Access Control Verification Requirements,V4.1,General Access Control Design,V4.1.3,"Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,285, 124 | V4,Access Control Verification Requirements,V4.1,General Access Control Design,V4.1.4,Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not receive access to new features until access is explicitly assigned. ([C7](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,276, 125 | V4,Access Control Verification Requirements,V4.1,General Access Control Design,V4.1.5,Verify that access controls fail securely including when an exception occurs. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,285, 126 | V4,Access Control Verification Requirements,V4.2,Operation Level Access Control,V4.2.1,"Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records.",✓,✓,✓,639, 127 | V4,Access Control Verification Requirements,V4.2,Operation Level Access Control,V4.2.2,"Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality.",✓,✓,✓,352, 128 | V4,Access Control Verification Requirements,V4.3,Other Access Control Considerations,V4.3.1,Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.,✓,✓,✓,419, 129 | V4,Access Control Verification Requirements,V4.3,Other Access Control Considerations,V4.3.2,"Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders.",✓,✓,✓,548, 130 | V4,Access Control Verification Requirements,V4.3,Other Access Control Considerations,V4.3.3,"Verify the application has additional authorization (such as step up or adaptive authentication) for lower value systems, and / or segregation of duties for high value applications to enforce anti-fraud controls as per the risk of application and past fraud.",,✓,✓,732, 131 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.1,Input Validation Requirements,V5.1.1,"Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, or environment variables).",✓,✓,✓,235, 132 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.1,Input Validation Requirements,V5.1.2,"Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,915, 133 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.1,Input Validation Requirements,V5.1.3,"Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (allow lists). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,20, 134 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.1,Input Validation Requirements,V5.1.4,"Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers or telephone, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match). ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,20, 135 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.1,Input Validation Requirements,V5.1.5,"Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content.",✓,✓,✓,601, 136 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.2,Sanitization and Sandboxing Requirements,V5.2.1,Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,116, 137 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.2,Sanitization and Sandboxing Requirements,V5.2.2,Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.,✓,✓,✓,138, 138 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.2,Sanitization and Sandboxing Requirements,V5.2.3,Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.,✓,✓,✓,147, 139 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.2,Sanitization and Sandboxing Requirements,V5.2.4,"Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed.",✓,✓,✓,95, 140 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.2,Sanitization and Sandboxing Requirements,V5.2.5,Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed.,✓,✓,✓,94, 141 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.2,Sanitization and Sandboxing Requirements,V5.2.6,"Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and uses allow lists of protocols, domains, paths and ports.",✓,✓,✓,918, 142 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.2,Sanitization and Sandboxing Requirements,V5.2.7,"Verify that the application sanitizes, disables, or sandboxes user-supplied Scalable Vector Graphics (SVG) scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject.",✓,✓,✓,159, 143 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.2,Sanitization and Sandboxing Requirements,V5.2.8,"Verify that the application sanitizes, disables, or sandboxes user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar.",✓,✓,✓,94, 144 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.1,"Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara). ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,116, 145 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.2,"Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,176, 146 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.3,"Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,79, 147 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.4,"Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks. ([C3](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,89, 148 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.5,"Verify that where parameterized or safer mechanisms are not present, context-specific output encoding is used to protect against injection attacks, such as the use of SQL escaping to protect against SQL injection. ([C3, C4](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,89, 149 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.6,"Verify that the application protects against JavaScript or JSON injection attacks, including for eval attacks, remote JavaScript includes, Content Security Policy (CSP) bypasses, DOM XSS, and JavaScript expression evaluation. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,830, 150 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.7,"Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,90, 151 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.8,Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,78, 152 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.9,Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.,✓,✓,✓,829, 153 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.3,Output Encoding and Injection Prevention Requirements,V5.3.10,Verify that the application protects against XPath injection or XML injection attacks. ([C4](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,643, 154 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.4,"Memory, String, and Unmanaged Code Requirements",V5.4.1,"Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows.",,✓,✓,120, 155 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.4,"Memory, String, and Unmanaged Code Requirements",V5.4.2,"Verify that format strings do not take potentially hostile input, and are constant.",,✓,✓,134, 156 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.4,"Memory, String, and Unmanaged Code Requirements",V5.4.3,"Verify that sign, range, and input validation techniques are used to prevent integer overflows.",,✓,✓,190, 157 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.5,Deserialization Prevention Requirements,V5.5.1,Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering. ([C5](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,502, 158 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.5,Deserialization Prevention Requirements,V5.5.2,Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks. ,✓,✓,✓,611, 159 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.5,Deserialization Prevention Requirements,V5.5.3,"Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML and YAML parsers). ",✓,✓,✓,502, 160 | V5,"Validation, Sanitization and Encoding Verification Requirements",V5.5,Deserialization Prevention Requirements,V5.5.4,"Verify that when parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to parse the JSON document. Do not use eval() to parse JSON.",✓,✓,✓,95, 161 | V6,Stored Cryptography Verification Requirements,V6.1,Data Classification,V6.1.1,"Verify that regulated private data is stored encrypted while at rest, such as Personally Identifiable Information (PII), sensitive personal information, or data assessed likely to be subject to EU's GDPR.",,✓,✓,311, 162 | V6,Stored Cryptography Verification Requirements,V6.1,Data Classification,V6.1.2,"Verify that regulated health data is stored encrypted while at rest, such as medical records, medical device details, or de-anonymized research records.",,✓,✓,311, 163 | V6,Stored Cryptography Verification Requirements,V6.1,Data Classification,V6.1.3,"Verify that regulated financial data is stored encrypted while at rest, such as financial accounts, defaults or credit history, tax records, pay history, beneficiaries, or de-anonymized market or research records.",,✓,✓,311, 164 | V6,Stored Cryptography Verification Requirements,V6.2,Algorithms,V6.2.1,"Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.",✓,✓,✓,310, 165 | V6,Stored Cryptography Verification Requirements,V6.2,Algorithms,V6.2.2,"Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,327, 166 | V6,Stored Cryptography Verification Requirements,V6.2,Algorithms,V6.2.3,"Verify that encryption initialization vector, cipher configuration, and block modes are configured securely using the latest advice.",,✓,✓,326, 167 | V6,Stored Cryptography Verification Requirements,V6.2,Algorithms,V6.2.4,"Verify that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes, can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,326, 168 | V6,Stored Cryptography Verification Requirements,V6.2,Algorithms,V6.2.5,"Verify that known insecure block modes (i.e. ECB, etc.), padding modes (i.e. PKCS#1 v1.5, etc.), ciphers with small block sizes (i.e. Triple-DES, Blowfish, etc.), and weak hashing algorithms (i.e. MD5, SHA1, etc.) are not used unless required for backwards compatibility.",,✓,✓,326, 169 | V6,Stored Cryptography Verification Requirements,V6.2,Algorithms,V6.2.6,"Verify that nonces, initialization vectors, and other single use numbers must not be used more than once with a given encryption key. The method of generation must be appropriate for the algorithm being used.",,✓,✓,326, 170 | V6,Stored Cryptography Verification Requirements,V6.2,Algorithms,V6.2.7,"Verify that encrypted data is authenticated via signatures, authenticated cipher modes, or HMAC to ensure that ciphertext is not altered by an unauthorized party.",,,✓,326, 171 | V6,Stored Cryptography Verification Requirements,V6.2,Algorithms,V6.2.8,"Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information.",,,✓,385, 172 | V6,Stored Cryptography Verification Requirements,V6.3,Random Values,V6.3.1,"Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module's approved cryptographically secure random number generator when these random values are intended to be not guessable by an attacker.",,✓,✓,338, 173 | V6,Stored Cryptography Verification Requirements,V6.3,Random Values,V6.3.2,"Verify that random GUIDs are created using the GUID v4 algorithm, and a Cryptographically-secure Pseudo-random Number Generator (CSPRNG). GUIDs created using other pseudo-random number generators may be predictable.",,✓,✓,338, 174 | V6,Stored Cryptography Verification Requirements,V6.3,Random Values,V6.3.3,"Verify that random numbers are created with proper entropy even when the application is under heavy load, or that the application degrades gracefully in such circumstances.",,,✓,338, 175 | V6,Stored Cryptography Verification Requirements,V6.4,Secret Management,V6.4.1,"Verify that a secrets management solution such as a key vault is used to securely create, store, control access to and destroy secrets. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,798, 176 | V6,Stored Cryptography Verification Requirements,V6.4,Secret Management,V6.4.2,Verify that key material is not exposed to the application but instead uses an isolated security module like a vault for cryptographic operations. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,320, 177 | V7,Error Handling and Logging Verification Requirements,V7.1,Log Content Requirements,V7.1.1,"Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form. ([C9, C10](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,532, 178 | V7,Error Handling and Logging Verification Requirements,V7.1,Log Content Requirements,V7.1.2,Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)),✓,✓,✓,532, 179 | V7,Error Handling and Logging Verification Requirements,V7.1,Log Content Requirements,V7.1.3,"Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures. ([C5, C7](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,778, 180 | V7,Error Handling and Logging Verification Requirements,V7.1,Log Content Requirements,V7.1.4,Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,778, 181 | V7,Error Handling and Logging Verification Requirements,V7.2,Log Processing Requirements,V7.2.1,"Verify that all authentication decisions are logged, without storing sensitive session tokens or passwords. This should include requests with relevant metadata needed for security investigations. ",,✓,✓,778, 182 | V7,Error Handling and Logging Verification Requirements,V7.2,Log Processing Requirements,V7.2.2,Verify that all access control decisions can be logged and all failed decisions are logged. This should include requests with relevant metadata needed for security investigations.,,✓,✓,285, 183 | V7,Error Handling and Logging Verification Requirements,V7.3,Log Protection Requirements,V7.3.1,Verify that the application appropriately encodes user-supplied data to prevent log injection. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,117, 184 | V7,Error Handling and Logging Verification Requirements,V7.3,Log Protection Requirements,V7.3.2,Verify that all events are protected from injection when viewed in log viewing software. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,117, 185 | V7,Error Handling and Logging Verification Requirements,V7.3,Log Protection Requirements,V7.3.3,Verify that security logs are protected from unauthorized access and modification. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,200, 186 | V7,Error Handling and Logging Verification Requirements,V7.3,Log Protection Requirements,V7.3.4,Verify that time sources are synchronized to the correct time and time zone. Strongly consider logging only in UTC if systems are global to assist with post-incident forensic analysis. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,, 187 | V7,Error Handling and Logging Verification Requirements,V7.4,Error Handling,V7.4.1,"Verify that a generic message is shown when an unexpected or security sensitive error occurs, potentially with a unique ID which support personnel can use to investigate. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,210, 188 | V7,Error Handling and Logging Verification Requirements,V7.4,Error Handling,V7.4.2,Verify that exception handling (or a functional equivalent) is used across the codebase to account for expected and unexpected error conditions. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,544, 189 | V7,Error Handling and Logging Verification Requirements,V7.4,Error Handling,V7.4.3,"Verify that a ""last resort"" error handler is defined which will catch all unhandled exceptions. ([C10](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,431, 190 | V8,Data Protection Verification Requirements,V8.1,General Data Protection,V8.1.1,Verify the application protects sensitive data from being cached in server components such as load balancers and application caches.,,✓,✓,524, 191 | V8,Data Protection Verification Requirements,V8.1,General Data Protection,V8.1.2,Verify that all cached or temporary copies of sensitive data stored on the server are protected from unauthorized access or purged/invalidated after the authorized user accesses the sensitive data.,,✓,✓,524, 192 | V8,Data Protection Verification Requirements,V8.1,General Data Protection,V8.1.3,"Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values.",,✓,✓,233, 193 | V8,Data Protection Verification Requirements,V8.1,General Data Protection,V8.1.4,"Verify the application can detect and alert on abnormal numbers of requests, such as by IP, user, total per hour or day, or whatever makes sense for the application.",,✓,✓,770, 194 | V8,Data Protection Verification Requirements,V8.1,General Data Protection,V8.1.5,Verify that regular backups of important data are performed and that test restoration of data is performed.,,,✓,19, 195 | V8,Data Protection Verification Requirements,V8.1,General Data Protection,V8.1.6,Verify that backups are stored securely to prevent data from being stolen or corrupted.,,,✓,19, 196 | V8,Data Protection Verification Requirements,V8.2,Client-side Data Protection,V8.2.1,Verify the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers.,✓,✓,✓,525, 197 | V8,Data Protection Verification Requirements,V8.2,Client-side Data Protection,V8.2.2,"Verify that data stored in browser storage (such as HTML5 local storage, session storage, IndexedDB, or cookies) does not contain sensitive data or PII.",✓,✓,✓,922, 198 | V8,Data Protection Verification Requirements,V8.2,Client-side Data Protection,V8.2.3,"Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated.",✓,✓,✓,922, 199 | V8,Data Protection Verification Requirements,V8.3,Sensitive Private Data,V8.3.1,"Verify that sensitive data is sent to the server in the HTTP message body or headers, and that query string parameters from any HTTP verb do not contain sensitive data.",✓,✓,✓,319, 200 | V8,Data Protection Verification Requirements,V8.3,Sensitive Private Data,V8.3.2,Verify that users have a method to remove or export their data on demand.,✓,✓,✓,212, 201 | V8,Data Protection Verification Requirements,V8.3,Sensitive Private Data,V8.3.3,Verify that users are provided clear language regarding collection and use of supplied personal information and that users have provided opt-in consent for the use of that data before it is used in any way.,✓,✓,✓,285, 202 | V8,Data Protection Verification Requirements,V8.3,Sensitive Private Data,V8.3.4,"Verify that all sensitive data created and processed by the application has been identified, and ensure that a policy is in place on how to deal with sensitive data. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,200, 203 | V8,Data Protection Verification Requirements,V8.3,Sensitive Private Data,V8.3.5,"Verify accessing sensitive data is audited (without logging the sensitive data itself), if the data is collected under relevant data protection directives or where logging of access is required.",,✓,✓,532, 204 | V8,Data Protection Verification Requirements,V8.3,Sensitive Private Data,V8.3.6,"Verify that sensitive information contained in memory is overwritten as soon as it is no longer required to mitigate memory dumping attacks, using zeroes or random data.",,✓,✓,226, 205 | V8,Data Protection Verification Requirements,V8.3,Sensitive Private Data,V8.3.7,"Verify that sensitive or private information that is required to be encrypted, is encrypted using approved algorithms that provide both confidentiality and integrity. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,327, 206 | V8,Data Protection Verification Requirements,V8.3,Sensitive Private Data,V8.3.8,"Verify that sensitive personal information is subject to data retention classification, such that old or out of date data is deleted automatically, on a schedule, or as the situation requires.",,✓,✓,285, 207 | V9,Communications Verification Requirements,V9.1,Client Communications Security Requirements,V9.1.1,"Verify that secured TLS is used for all client connectivity, and does not fall back to insecure or unencrypted protocols. ([C8](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,319, 208 | V9,Communications Verification Requirements,V9.1,Client Communications Security Requirements,V9.1.2,"Verify using online or up to date TLS testing tools that only strong algorithms, ciphers, and protocols are enabled, with the strongest algorithms and ciphers set as preferred.",✓,✓,✓,326, 209 | V9,Communications Verification Requirements,V9.1,Client Communications Security Requirements,V9.1.3,"Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled, such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the preferred cipher suite.",✓,✓,✓,326, 210 | V9,Communications Verification Requirements,V9.2,Server Communications Security Requirements,V9.2.1,"Verify that connections to and from the server use trusted TLS certificates. Where internally generated or self-signed certificates are used, the server must be configured to only trust specific internal CAs and specific self-signed certificates. All others should be rejected.",,✓,✓,295, 211 | V9,Communications Verification Requirements,V9.2,Server Communications Security Requirements,V9.2.2,"Verify that encrypted communications such as TLS is used for all inbound and outbound connections, including for management ports, monitoring, authentication, API, or web service calls, database, cloud, serverless, mainframe, external, and partner connections. The server must not fall back to insecure or unencrypted protocols.",,✓,✓,319, 212 | V9,Communications Verification Requirements,V9.2,Server Communications Security Requirements,V9.2.3,Verify that all encrypted connections to external systems that involve sensitive information or functions are authenticated.,,✓,✓,287, 213 | V9,Communications Verification Requirements,V9.2,Server Communications Security Requirements,V9.2.4,"Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured.",,✓,✓,299, 214 | V9,Communications Verification Requirements,V9.2,Server Communications Security Requirements,V9.2.5,Verify that backend TLS connection failures are logged.,,,✓,544, 215 | V10,Malicious Code Verification Requirements,V10.1,Code Integrity Controls,V10.1.1,"Verify that a code analysis tool is in use that can detect potentially malicious code, such as time functions, unsafe file operations and network connections.",,,✓,749, 216 | V10,Malicious Code Verification Requirements,V10.2,Malicious Code Search,V10.2.1,"Verify that the application source code and third party libraries do not contain unauthorized phone home or data collection capabilities. Where such functionality exists, obtain the user's permission for it to operate before collecting any data.",,✓,✓,359, 217 | V10,Malicious Code Verification Requirements,V10.2,Malicious Code Search,V10.2.2,"Verify that the application does not ask for unnecessary or excessive permissions to privacy related features or sensors, such as contacts, cameras, microphones, or location.",,✓,✓,272, 218 | V10,Malicious Code Verification Requirements,V10.2,Malicious Code Search,V10.2.3,"Verify that the application source code and third party libraries do not contain back doors, such as hard-coded or additional undocumented accounts or keys, code obfuscation, undocumented binary blobs, rootkits, or anti-debugging, insecure debugging features, or otherwise out of date, insecure, or hidden functionality that could be used maliciously if discovered.",,,✓,507, 219 | V10,Malicious Code Verification Requirements,V10.2,Malicious Code Search,V10.2.4,Verify that the application source code and third party libraries do not contain time bombs by searching for date and time related functions.,,,✓,511, 220 | V10,Malicious Code Verification Requirements,V10.2,Malicious Code Search,V10.2.5,"Verify that the application source code and third party libraries do not contain malicious code, such as salami attacks, logic bypasses, or logic bombs.",,,✓,511, 221 | V10,Malicious Code Verification Requirements,V10.2,Malicious Code Search,V10.2.6,Verify that the application source code and third party libraries do not contain Easter eggs or any other potentially unwanted functionality.,,,✓,507, 222 | V10,Malicious Code Verification Requirements,V10.3,Deployed Application Integrity Controls,V10.3.1,"Verify that if the application has a client or server auto-update feature, updates should be obtained over secure channels and digitally signed. The update code must validate the digital signature of the update before installing or executing the update.",✓,✓,✓,16, 223 | V10,Malicious Code Verification Requirements,V10.3,Deployed Application Integrity Controls,V10.3.2,"Verify that the application employs integrity protections, such as code signing or subresource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet.",✓,✓,✓,353, 224 | V10,Malicious Code Verification Requirements,V10.3,Deployed Application Integrity Controls,V10.3.3,"Verify that the application has protection from subdomain takeovers if the application relies upon DNS entries or DNS subdomains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (*autogen-bucket-id*.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change.",✓,✓,✓,350, 225 | V11,Business Logic Verification Requirements,V11.1,Business Logic Security Requirements,V11.1.1,Verify the application will only process business logic flows for the same user in sequential step order and without skipping steps.,✓,✓,✓,841, 226 | V11,Business Logic Verification Requirements,V11.1,Business Logic Security Requirements,V11.1.2,"Verify the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly.",✓,✓,✓,799, 227 | V11,Business Logic Verification Requirements,V11.1,Business Logic Security Requirements,V11.1.3,Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis.,✓,✓,✓,770, 228 | V11,Business Logic Verification Requirements,V11.1,Business Logic Security Requirements,V11.1.4,"Verify the application has sufficient anti-automation controls to detect and protect against data exfiltration, excessive business logic requests, excessive file uploads or denial of service attacks.",✓,✓,✓,770, 229 | V11,Business Logic Verification Requirements,V11.1,Business Logic Security Requirements,V11.1.5,"Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modeling or similar methodologies.",✓,✓,✓,841, 230 | V11,Business Logic Verification Requirements,V11.1,Business Logic Security Requirements,V11.1.6,"Verify the application does not suffer from ""Time Of Check to Time Of Use"" (TOCTOU) issues or other race conditions for sensitive operations.",,✓,✓,367, 231 | V11,Business Logic Verification Requirements,V11.1,Business Logic Security Requirements,V11.1.7,"Verify the application monitors for unusual events or activity from a business logic perspective. For example, attempts to perform actions out of order or actions which a normal user would never attempt. ([C9](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,754, 232 | V11,Business Logic Verification Requirements,V11.1,Business Logic Security Requirements,V11.1.8,Verify the application has configurable alerting when automated attacks or unusual activity is detected.,,✓,✓,390, 233 | V12,File and Resources Verification Requirements,V12.1,File Upload Requirements,V12.1.1,Verify that the application will not accept large files that could fill up storage or cause a denial of service.,✓,✓,✓,400, 234 | V12,File and Resources Verification Requirements,V12.1,File Upload Requirements,V12.1.2,"Verify that compressed files are checked for ""zip bombs"" - small input files that will decompress into huge files thus exhausting file storage limits.",,✓,✓,409, 235 | V12,File and Resources Verification Requirements,V12.1,File Upload Requirements,V12.1.3,"Verify that a file size quota and maximum number of files per user is enforced to ensure that a single user cannot fill up the storage with too many files, or excessively large files.",,✓,✓,770, 236 | V12,File and Resources Verification Requirements,V12.2,File Integrity Requirements,V12.2.1,Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content.,,✓,✓,434, 237 | V12,File and Resources Verification Requirements,V12.3,File Execution Requirements,V12.3.1,Verify that user-submitted filename metadata is not used directly by system or framework filesystems and that a URL API is used to protect against path traversal.,✓,✓,✓,22, 238 | V12,File and Resources Verification Requirements,V12.3,File Execution Requirements,V12.3.2,"Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI).",✓,✓,✓,73, 239 | V12,File and Resources Verification Requirements,V12.3,File Execution Requirements,V12.3.3,Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure or execution of remote files via Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks. ,✓,✓,✓,98, 240 | V12,File and Resources Verification Requirements,V12.3,File Execution Requirements,V12.3.4,"Verify that the application protects against Reflective File Download (RFD) by validating or ignoring user-submitted filenames in a JSON, JSONP, or URL parameter, the response Content-Type header should be set to text/plain, and the Content-Disposition header should have a fixed filename.",✓,✓,✓,641, 241 | V12,File and Resources Verification Requirements,V12.3,File Execution Requirements,V12.3.5,"Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection.",✓,✓,✓,78, 242 | V12,File and Resources Verification Requirements,V12.3,File Execution Requirements,V12.3.6,"Verify that the application does not include and execute functionality from untrusted sources, such as unverified content distribution networks, JavaScript libraries, node npm libraries, or server-side DLLs.",,✓,✓,829, 243 | V12,File and Resources Verification Requirements,V12.4,File Storage Requirements,V12.4.1,"Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions, preferably with strong validation.",✓,✓,✓,922, 244 | V12,File and Resources Verification Requirements,V12.4,File Storage Requirements,V12.4.2,Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload of known malicious content.,✓,✓,✓,509, 245 | V12,File and Resources Verification Requirements,V12.5,File Download Requirements,V12.5.1,"Verify that the web tier is configured to serve only files with specific file extensions to prevent unintentional information and source code leakage. For example, backup files (e.g. .bak), temporary working files (e.g. .swp), compressed files (.zip, .tar.gz, etc) and other extensions commonly used by editors should be blocked unless required.",✓,✓,✓,552, 246 | V12,File and Resources Verification Requirements,V12.5,File Download Requirements,V12.5.2,Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.,✓,✓,✓,434, 247 | V12,File and Resources Verification Requirements,V12.6,SSRF Protection Requirements,V12.6.1,Verify that the web or application server is configured with an allow list of resources or systems to which the server can send requests or load data/files from.,✓,✓,✓,918, 248 | V13,API and Web Service Verification Requirements,V13.1,Generic Web Service Security Verification Requirements,V13.1.1,Verify that all application components use the same encodings and parsers to avoid parsing attacks that exploit different URI or file parsing behavior that could be used in SSRF and RFI attacks.,✓,✓,✓,116, 249 | V13,API and Web Service Verification Requirements,V13.1,Generic Web Service Security Verification Requirements,V13.1.2,Verify that access to administration and management functions is limited to authorized administrators.,✓,✓,✓,419, 250 | V13,API and Web Service Verification Requirements,V13.1,Generic Web Service Security Verification Requirements,V13.1.3,"Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.",✓,✓,✓,598, 251 | V13,API and Web Service Verification Requirements,V13.1,Generic Web Service Security Verification Requirements,V13.1.4,"Verify that authorization decisions are made at both the URI, enforced by programmatic or declarative security at the controller or router, and at the resource level, enforced by model-based permissions.",,✓,✓,285, 252 | V13,API and Web Service Verification Requirements,V13.1,Generic Web Service Security Verification Requirements,V13.1.5,Verify that requests containing unexpected or missing content types are rejected with appropriate headers (HTTP response status 406 Unacceptable or 415 Unsupported Media Type).,,✓,✓,434, 253 | V13,API and Web Service Verification Requirements,V13.2,RESTful Web Service Verification Requirements,V13.2.1,"Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources.",✓,✓,✓,650, 254 | V13,API and Web Service Verification Requirements,V13.2,RESTful Web Service Verification Requirements,V13.2.2,Verify that JSON schema validation is in place and verified before accepting input.,✓,✓,✓,20, 255 | V13,API and Web Service Verification Requirements,V13.2,RESTful Web Service Verification Requirements,V13.2.3,"Verify that RESTful web services that utilize cookies are protected from Cross-Site Request Forgery via the use of at least one or more of the following: double submit cookie pattern, CSRF nonces, or Origin request header checks.",✓,✓,✓,352, 256 | V13,API and Web Service Verification Requirements,V13.2,RESTful Web Service Verification Requirements,V13.2.4,"Verify that REST services have anti-automation controls to protect against excessive calls, especially if the API is unauthenticated.",,✓,✓,770, 257 | V13,API and Web Service Verification Requirements,V13.2,RESTful Web Service Verification Requirements,V13.2.5,"Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json.",,✓,✓,436, 258 | V13,API and Web Service Verification Requirements,V13.2,RESTful Web Service Verification Requirements,V13.2.6,Verify that the message headers and payload are trustworthy and not modified in transit. Requiring strong encryption for transport (TLS only) may be sufficient in many cases as it provides both confidentiality and integrity protection. Per-message digital signatures can provide additional assurance on top of the transport protections for high-security applications but bring with them additional complexity and risks to weigh against the benefits.,,✓,✓,345, 259 | V13,API and Web Service Verification Requirements,V13.3,SOAP Web Service Verification Requirements,V13.3.1,"Verify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place.",✓,✓,✓,20, 260 | V13,API and Web Service Verification Requirements,V13.3,SOAP Web Service Verification Requirements,V13.3.2,Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service.,,✓,✓,345, 261 | V13,API and Web Service Verification Requirements,V13.4,GraphQL and other Web Service Data Layer Security Requirements,V13.4.1,"Verify that a query allow list or a combination of depth limiting and amount limiting is used to prevent GraphQL or data layer expression Denial of Service (DoS) as a result of expensive, nested queries. For more advanced scenarios, query cost analysis should be used.",,✓,✓,770, 262 | V13,API and Web Service Verification Requirements,V13.4,GraphQL and other Web Service Data Layer Security Requirements,V13.4.2,Verify that GraphQL or other data layer authorization logic should be implemented at the business logic layer instead of the GraphQL layer.,,✓,✓,285, 263 | V14,Configuration Verification Requirements,V14.1,Build,V14.1.1,"Verify that the application build and deployment processes are performed in a secure and repeatable way, such as CI / CD automation, automated configuration management, and automated deployment scripts.",,✓,✓,, 264 | V14,Configuration Verification Requirements,V14.1,Build,V14.1.2,"Verify that compiler flags are configured to enable all available buffer overflow protections and warnings, including stack randomization, data execution prevention, and to break the build if an unsafe pointer, memory, format string, integer, or string operations are found.",,✓,✓,120, 265 | V14,Configuration Verification Requirements,V14.1,Build,V14.1.3,Verify that server configuration is hardened as per the recommendations of the application server and frameworks in use.,,✓,✓,16, 266 | V14,Configuration Verification Requirements,V14.1,Build,V14.1.4,"Verify that the application, configuration, and all dependencies can be re-deployed using automated deployment scripts, built from a documented and tested runbook in a reasonable time, or restored from backups in a timely fashion.",,✓,✓,, 267 | V14,Configuration Verification Requirements,V14.1,Build,V14.1.5,Verify that authorized administrators can verify the integrity of all security-relevant configurations to detect tampering.,,,✓,, 268 | V14,Configuration Verification Requirements,V14.2,Dependency,V14.2.1,"Verify that all components are up to date, preferably using a dependency checker during build or compile time. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering))",✓,✓,✓,1026, 269 | V14,Configuration Verification Requirements,V14.2,Dependency,V14.2.2,"Verify that all unneeded features, documentation, samples, configurations are removed, such as sample applications, platform documentation, and default or example users.",✓,✓,✓,1002, 270 | V14,Configuration Verification Requirements,V14.2,Dependency,V14.2.3,"Verify that if application assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset.",✓,✓,✓,829, 271 | V14,Configuration Verification Requirements,V14.2,Dependency,V14.2.4,"Verify that third party components come from pre-defined, trusted and continually maintained repositories. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering))",,✓,✓,829, 272 | V14,Configuration Verification Requirements,V14.2,Dependency,V14.2.5,Verify that an inventory catalog is maintained of all third party libraries in use. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,, 273 | V14,Configuration Verification Requirements,V14.2,Dependency,V14.2.6,Verify that the attack surface is reduced by sandboxing or encapsulating third party libraries to expose only the required behaviour into the application. ([C2](https://owasp.org/www-project-proactive-controls/#div-numbering)),,✓,✓,265, 274 | V14,Configuration Verification Requirements,V14.3,Unintended Security Disclosure Requirements,V14.3.1,"Verify that web or application server and framework error messages are configured to deliver user actionable, customized responses to eliminate any unintended security disclosures.",✓,✓,✓,209, 275 | V14,Configuration Verification Requirements,V14.3,Unintended Security Disclosure Requirements,V14.3.2,"Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures.",✓,✓,✓,497, 276 | V14,Configuration Verification Requirements,V14.3,Unintended Security Disclosure Requirements,V14.3.3,Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.,✓,✓,✓,200, 277 | V14,Configuration Verification Requirements,V14.4,HTTP Security Headers Requirements,V14.4.1,"Verify that every HTTP response contains a Content-Type header. text/*, */*+xml and application/xml content types should also specify a safe character set (e.g., UTF-8, ISO-8859-1).",✓,✓,✓,173, 278 | V14,Configuration Verification Requirements,V14.4,HTTP Security Headers Requirements,V14.4.2,"Verify that all API responses contain a Content-Disposition: attachment; filename=""api.json"" header (or other appropriate filename for the content type).",✓,✓,✓,116, 279 | V14,Configuration Verification Requirements,V14.4,HTTP Security Headers Requirements,V14.4.3,"Verify that a Content Security Policy (CSP) response header is in place that helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities.",✓,✓,✓,1021, 280 | V14,Configuration Verification Requirements,V14.4,HTTP Security Headers Requirements,V14.4.4,Verify that all responses contain a X-Content-Type-Options: nosniff header.,✓,✓,✓,116, 281 | V14,Configuration Verification Requirements,V14.4,HTTP Security Headers Requirements,V14.4.5,"Verify that a Strict-Transport-Security header is included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains.",✓,✓,✓,523, 282 | V14,Configuration Verification Requirements,V14.4,HTTP Security Headers Requirements,V14.4.6,"Verify that a suitable ""Referrer-Policy"" header is included, such as ""no-referrer"" or ""same-origin"".",✓,✓,✓,116, 283 | V14,Configuration Verification Requirements,V14.4,HTTP Security Headers Requirements,V14.4.7,Verify that the content of a web application cannot be embedded in a third-party site by default and that embedding of the exact resources is only allowed where necessary by using suitable Content-Security-Policy: frame-ancestors and X-Frame-Options response headers.,✓,✓,✓,346, 284 | V14,Configuration Verification Requirements,V14.5,Validate HTTP Request Header Requirements,V14.5.1,"Verify that the application server only accepts the HTTP methods in use by the application/API, including pre-flight OPTIONS, and logs/alerts on any requests that are not valid for the application context.",✓,✓,✓,749, 285 | V14,Configuration Verification Requirements,V14.5,Validate HTTP Request Header Requirements,V14.5.2,"Verify that the supplied Origin header is not used for authentication or access control decisions, as the Origin header can easily be changed by an attacker.",✓,✓,✓,346, 286 | V14,Configuration Verification Requirements,V14.5,Validate HTTP Request Header Requirements,V14.5.3,"Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header uses a strict allow list of trusted domains and subdomains to match against and does not support the ""null"" origin.",✓,✓,✓,346, 287 | V14,Configuration Verification Requirements,V14.5,Validate HTTP Request Header Requirements,V14.5.4,"Verify that HTTP headers added by a trusted proxy or SSO devices, such as a bearer token, are authenticated by the application.",,✓,✓,306, 288 | 289 | --------------------------------------------------------------------------------