├── .github └── workflows │ ├── ci.yml │ └── deploy.yml ├── .gitignore ├── .markdownlint.yaml ├── .spellcheck.yaml ├── .wordlist.txt ├── LICENSE ├── README.md ├── docs ├── CNAME ├── archive │ ├── 2014 │ │ └── index.md │ ├── 2016 │ │ ├── in-the-news.md │ │ └── index.md │ ├── 2018 │ │ ├── 0x01-about-owasp.md │ │ ├── 0x02-about-project.md │ │ ├── 0x03-about-structure.md │ │ ├── 0x04-introduction.md │ │ ├── c1-security-requirements.md │ │ ├── c10-errors-exceptions.md │ │ ├── c2-leverage-security-frameworks-libraries.md │ │ ├── c3-secure-database.md │ │ ├── c4-encode-escape-data.md │ │ ├── c5-validate-inputs.md │ │ ├── c6-digital-identity.md │ │ ├── c7-enforce-access-controls.md │ │ ├── c8-protect-data-everywhere.md │ │ ├── c9-security-logging.md │ │ ├── final-word.md │ │ ├── in-the-news.md │ │ └── translations.md │ └── 2024 │ │ ├── final-word.md │ │ ├── index.md │ │ ├── introduction │ │ ├── about-owasp.md │ │ ├── contributing.md │ │ ├── in-the-news.md │ │ └── related-owasp-projects.md │ │ └── the-top-10 │ │ ├── c1-accesscontrol.md │ │ ├── c10-stop-server-side-request-forgery.md │ │ ├── c2-crypto.md │ │ ├── c3-validate-input-and-handle-exceptions.md │ │ ├── c4-secure-architecture.md │ │ ├── c5-secure-by-default.md │ │ ├── c6-use-secure-dependencies.md │ │ ├── c7-secure-digital-identities.md │ │ ├── c8-leverage-browser-security-features.md │ │ ├── c9-security-logging-and-monitoring.md │ │ └── index.md ├── final-word.md ├── index.md ├── introduction │ ├── about-owasp.md │ ├── contributing.md │ ├── in-the-news.md │ └── related-owasp-projects.md └── the-top-10 │ ├── c1-accesscontrol.md │ ├── c10-stop-server-side-request-forgery.md │ ├── c2-crypto.md │ ├── c3-validate-input-and-handle-exceptions.md │ ├── c4-secure-architecture.md │ ├── c5-secure-by-default.md │ ├── c6-use-secure-dependencies.md │ ├── c7-secure-digital-identities.md │ ├── c8-leverage-browser-security-features.md │ ├── c9-security-logging-and-monitoring.md │ └── index.md ├── leaders.md ├── mkdocs.yml ├── overrides ├── 404.html └── google6fbf6cc04efaa5b5.html ├── v2 ├── OWASPTop10ProactiveControls2016-Chinese.pdf ├── OWASPTop10ProactiveControls2016-Japanese.pdf ├── OWASPTop10ProactiveControls2016-SimplifiedChinese.pdf ├── OWASP_Proactive_Controls_2-Hebrew.pdf ├── OWASP_Top_10_Proactive_Controls_-_V2.0.docx ├── OWASP_Top_10_Proactive_Controls_V2.pdf └── OWASP_Top_Ten_Proactive_Controls_v2.pptx └── v3 ├── .DS_Store ├── OWASP-OPC-IEEEE-OTop10-OTMobTop10-ssdf.pdf ├── OWASP_TOP_10_Proactive_Controls_2018_V3_ES-AR.pdf ├── OWASP_TOP_10_Proactive_Controls_2018_V3_PL.pdf ├── OWASP_TOP_10_Proactive_Controls_2018_V3_PT-BR.pdf ├── OWASP_Top_10_Proactive_Controls_V3-AR.pdf ├── OWASP_Top_10_Proactive_Controls_V3-IT.pdf ├── OWASP_Top_10_Proactive_Controls_V3.docx ├── OWASP_Top_10_Proactive_Controls_V3.pdf ├── OWASP_Top_10_Proactive_Controls_V3_Chinese.pdf ├── OWASP_Top_Ten_Proactive_Controls_v3.pptx ├── Owasp-top-10-proactive-controls-2018-russian.pdf ├── generate-doc.sh ├── images ├── controls-logo.png └── proactive-header.jpg └── templates ├── 2-cols.docx ├── template.docx └── ~$mplate.docx /.github/workflows/ci.yml: -------------------------------------------------------------------------------- 1 | name: CI pipeline 2 | on: 3 | push: 4 | branches: 5 | - main 6 | - master 7 | workflow_dispatch: 8 | 9 | # for security reasons the github actions are pinned to specific release versions 10 | jobs: 11 | link_checker: 12 | name: Link checker 13 | runs-on: ubuntu-24.04 14 | steps: 15 | - name: Checkout markdown 16 | uses: actions/checkout@v4.1.1 17 | 18 | - name: Link Checker 19 | uses: lycheeverse/lychee-action@v1.10.0 20 | with: 21 | args: --no-progress --max-retries 5 --exclude-path './docs/archive/' './docs/**/*.md' 22 | fail: true 23 | env: 24 | GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}} 25 | 26 | md_linter: 27 | name: Lint markdown 28 | runs-on: ubuntu-24.04 29 | steps: 30 | - name: Checkout markdown 31 | uses: actions/checkout@v4.1.1 32 | 33 | - name: Lint markdown 34 | uses: DavidAnson/markdownlint-cli2-action@v16.0.0 35 | with: 36 | config: '.markdownlint.yaml' 37 | globs: './docs/**/*.md' 38 | 39 | spell_checker: 40 | name: Check spelling 41 | runs-on: ubuntu-24.04 42 | steps: 43 | - name: Checkout markdown 44 | uses: actions/checkout@v4.1.1 45 | 46 | - name: spell_checker 47 | uses: rojopolis/spellcheck-github-actions@0.41.0 -------------------------------------------------------------------------------- /.github/workflows/deploy.yml: -------------------------------------------------------------------------------- 1 | name: Build Github Pages 2 | on: 3 | push: 4 | branches: 5 | - main 6 | - master 7 | permissions: 8 | contents: write 9 | jobs: 10 | deploy: 11 | runs-on: ubuntu-latest 12 | steps: 13 | - uses: actions/checkout@v4 14 | with: 15 | fetch-depth: 0 16 | - uses: actions/setup-python@v5 17 | with: 18 | python-version: 3.x 19 | - uses: actions/cache@v2 20 | with: 21 | key: ${{ github.ref }} 22 | path: .cache 23 | - name: Install Dependencies 24 | run: pip install mkdocs-material mkdocs-redirects 25 | - run: mkdocs gh-deploy --force --clean 26 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | __pycache__ 2 | env 3 | .vscode 4 | _site/ 5 | .DS_Store 6 | venv/ 7 | -------------------------------------------------------------------------------- /.markdownlint.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | no-trailing-punctuation: false 3 | no-inline-html: false 4 | first-line-heading: false 5 | link-fragments: false 6 | 7 | # MD013 - Line length 8 | MD013: 9 | code_block_line_length: 125 10 | code_blocks: true 11 | heading_line_length: 100 12 | #heading_line_length: 80 13 | headings: true 14 | # line_length: 125 15 | line_length: 2048 16 | stern: true 17 | strict: false 18 | tables: true -------------------------------------------------------------------------------- /.spellcheck.yaml: -------------------------------------------------------------------------------- 1 | matrix: 2 | - name: Markdown 3 | aspell: 4 | lang: en 5 | dictionary: 6 | wordlists: 7 | - .wordlist.txt 8 | output: wordlist.dic 9 | encoding: utf-8 10 | pipeline: 11 | - pyspelling.filters.markdown: 12 | markdown_extensions: 13 | - pymdownx.superfences: 14 | - pyspelling.filters.html: 15 | comments: false 16 | ignores: 17 | - code 18 | - pre 19 | sources: 20 | - 'docs/**/*.md' 21 | default_encoding: utf-8 -------------------------------------------------------------------------------- /.wordlist.txt: -------------------------------------------------------------------------------- 1 | 2 | AAL 3 | ABAC 4 | Abdessamad 5 | Adriaan 6 | AES 7 | allowlist 8 | allowlisting 9 | Allowlisting 10 | Andreas 11 | AntiXssEncoder 12 | AntiXSSEncoder 13 | APIs 14 | AppSec 15 | Aref 16 | ASVS 17 | authenticator 18 | autobinding 19 | backend 20 | Baillon 21 | bcrypt 22 | biometrics 23 | Biometrics 24 | Braiterman 25 | BSIMM 26 | caniuse 27 | Caniuse 28 | canonicalization 29 | Canonicalization 30 | Capellan 31 | Cassio 32 | cd 33 | cheatsheets 34 | cheatsheetseries 35 | Checkov 36 | Chih 37 | Chorzevski 38 | CIS 39 | CLI 40 | clickjacking 41 | Clickjacking 42 | Cloudmapper 43 | Coiro 44 | ColdFusion 45 | conf 46 | config 47 | CORS 48 | Coursera 49 | crypto 50 | cryptographic 51 | cryptographically 52 | CSP 53 | CSRF 54 | CSRF 55 | CVE 56 | CWE 57 | Cx 58 | Cybuck 59 | Cyrille 60 | DAC 61 | danielmiessler 62 | Datz 63 | de 64 | decrypt 65 | denylist 66 | denylisting 67 | Denylisting 68 | Der 69 | deserialization 70 | deserialize 71 | deserializes 72 | DevOps 73 | DevOpsSec 74 | DevSecOps 75 | DevSlop 76 | DNS 77 | docx 78 | DOM 79 | DOMPurify 80 | Dracea 81 | DSS 82 | DTOs 83 | Elnaggar 84 | Escaper 85 | Estrin 86 | EU's 87 | Eyal 88 | Fenstrom 89 | Frédéric 90 | Fujimoto 91 | Gaz 92 | GDPR 93 | github 94 | GitRob 95 | Goldschmidt 96 | goto 97 | Grandval 98 | Graziani 99 | Grossman 100 | HackerCombat 101 | Happe 102 | Hashicorp 103 | Hashicorp's 104 | Heyes 105 | Hidenori 106 | Hiroaki 107 | Hiroshi 108 | Hsiang 109 | HSTS 110 | Hsu 111 | html 112 | httpOnly 113 | https 114 | HTTPS 115 | IaC 116 | ideation 117 | IDOR 118 | iframes 119 | intransparency 120 | io 121 | ISC 122 | Ishaq 123 | Ivashchenko 124 | Jasmin 125 | JavaScript 126 | JEA 127 | JEP 128 | JIT 129 | Joubert 130 | JS 131 | JSON 132 | JSR 133 | JWS 134 | JWT 135 | JWTs 136 | keychain 137 | keystore 138 | KeyWhiz 139 | KICS 140 | KMS 141 | Koichiro 142 | Kubernetes 143 | Kubescape 144 | Kuramochi 145 | Kyverno 146 | LDAP 147 | Libsodium 148 | linkedin 149 | localhost 150 | Mair 151 | Manico 152 | Massimiliano 153 | MASVS 154 | Microservices 155 | Miessler 156 | misconfiguration 157 | Misconfiguration 158 | misconfigure 159 | mkdocs 160 | Mohammed 161 | nabla 162 | Nagai 163 | NCSC 164 | NIST 165 | nonces 166 | NoSQL 167 | NVD 168 | OAuth 169 | OKADA 170 | oneconsult's 171 | OPC 172 | OpenSAMM 173 | OpenSSF 174 | OQL 175 | ORM 176 | Osama 177 | OTP 178 | owasp 179 | OWASP 180 | Pagel 181 | parametrization 182 | parametrized 183 | PassKeys 184 | PCI 185 | pdf 186 | PHPNW 187 | PII 188 | plaintext 189 | pptx 190 | precautious 191 | programmatically 192 | py 193 | RBAC 194 | RCE 195 | reactively 196 | realtime 197 | ReDoS 198 | Referer 199 | Riotaro 200 | Ristic 201 | RNG 202 | runtime 203 | Saft 204 | SameSite 205 | SAMM 206 | sandbopxing 207 | sandboxing 208 | Sanitization 209 | SAST 210 | SBOM 211 | SBOMs 212 | SCA 213 | scalability 214 | SecLists 215 | securitypatterns 216 | Shaheed 217 | ShareAlike 218 | Snyk 219 | Soares 220 | SQLi 221 | Sqlmap 222 | src 223 | SSL 224 | SSLLabs 225 | sslyze 226 | SSLyze 227 | SSO 228 | SSRF 229 | SSRFmap 230 | SSTI 231 | Taras 232 | TechBeacon 233 | Teil 234 | Temmar 235 | templating 236 | Terraform 237 | Terrascan 238 | testssl 239 | Tfsec 240 | ThreeHoolagins 241 | ThunderSon 242 | Timo 243 | Tink 244 | TLS 245 | TLSv 246 | Transformative 247 | Trivy 248 | TruffleHog 249 | UCDavies 250 | UI 251 | unencrypted 252 | untrusted 253 | Validator 254 | Vanhilst 255 | venv 256 | verifier 257 | Vries 258 | Watanabe 259 | WebAuthn 260 | WebCams 261 | webhooks 262 | WrongSecrets 263 | www 264 | XEE 265 | XFO 266 | XSS 267 | Zend 268 | Zend 269 | Zudilin 270 | reimplement 271 | StrideGPT 272 | Jaskirat 273 | Kron 274 | Lukas 275 | Weichselbaum 276 | cowsecurity 277 | joonakokkola 278 | untracked -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # OWASP Top 10 Proactive Controls 2 | 3 | The OWASP Top Ten Proactive Controls is a list of security techniques that should be included in every software development project. They are ordered by order of importance, with control number 1 being the most important. This document was written by developers for developers to assist those new to secure development. 4 | 5 | The web page can be found at: 6 | https://owasp.org/www-project-proactive-controls/ 7 | -------------------------------------------------------------------------------- /docs/CNAME: -------------------------------------------------------------------------------- 1 | top10proactive.owasp.org -------------------------------------------------------------------------------- /docs/archive/2014/index.md: -------------------------------------------------------------------------------- 1 | # OWASP Top 10 Proactive Controls v1/2014 2 | 3 | - OWASP-2014-C1: Parameterize Queries 4 | - OWASP-2014-C2: Encode Data 5 | - OWASP-2014-C3: Validate All Inputs 6 | - OWASP-2014-C4: Implement Appropriate Access Controls 7 | - OWASP-2014-C5: Establish Identity and Authentication Controls 8 | - OWASP-2014-C6: Protect Data and Privacy 9 | - OWASP-2014-C7: Implement Logging, Error Handling and Intrusion Detection 10 | - OWASP-2014-C8: Leverage Security Features of Frameworks and Security Libraries 11 | - OWASP-2014-C9: Include Security-Specific Requirements 12 | - OWASP-2014-C10: Design and Architect Security In 13 | -------------------------------------------------------------------------------- /docs/archive/2016/in-the-news.md: -------------------------------------------------------------------------------- 1 | # OWASP Top 10 Proactive Controls 2016 in the News 2 | 3 | ## 2017 4 | 5 | - \[11 Aug 2017\] Presented at [Northeast PHP Conference](https://northeastphp2017.sched.com/event/B6uo/owasp-top-10-proactive-controls-2016) 6 | - \[25 July 2017\] Podcast about at [OWASP Top 10 Proactive Controls](https://www.appsecpodcast.org/2017/07/25/the-owasp-top-10-proactive-controls/) 7 | - \[12 May 2017\] Presented at [AppSec EU'17 - Belfast](https://appseceurope2017.sched.com/event/A652/the-path-of-secure-software) 8 | - \[14 Feb 2017\] Featured in [Managing Cloud Infrastructure to Prevent Security Gaps](http://wwpi.com/2017/02/14/managing-cloud-infrastructure-to-prevent-security-gaps/) 9 | - \[Feb 2017 \] Featured in "[Application Security Program: Protect Against Data Breaches](http://assets.unisys.com/Documents/Global/POVPapers/POV_170062_ApplicationSecurityProgramProtectAgainstDataBreaches.pdf)" 10 | 11 | ## 2016 12 | 13 | The OWASP Top 10 Proactive Controls 2016 (v2) were released on Jan 14, 2016. 14 | 15 | - \[1 Oct 2016\] Presented at [PHPNW16](http://conference.phpnw.org.uk/phpnw16/speakers/katy-anton/) 16 | - \[5 July 2016\] Featured in [Incorporating Security Best Practices into Agile Teams](https://www.thoughtworks.com/insights/blog/incorporating-security-best-practices-agile-teams) 17 | - \[June 2016 \] Featured in [A Transformative Approach to Secure Systems Delivery](http://www.booz-allen.co.in/content/dam/boozallen/documents/Viewpoints/2016/06/transformative-approach-to-secure-systems-delivery.pdf) 18 | - \[2 June 2016\] Featured in [DevOpsSec - Securing Software through Continuous Delivery](http://www.oreilly.com/webops-perf/free/devopssec.csp) 19 | -------------------------------------------------------------------------------- /docs/archive/2016/index.md: -------------------------------------------------------------------------------- 1 | # OWASP Top 10 Proactive Controls v2 (2016) 2 | 3 | You can download an English version of the OWASP Top 10 Proactive Controls: [pdf](https://github.com/OWASP/www-project-proactive-controls/blob/master/v2/OWASP_Top_10_Proactive_Controls_V2.pdf), [docx](https://github.com/OWASP/www-project-proactive-controls/blob/master/v2/OWASP_Top_10_Proactive_Controls_-_V2.0.docx), [pptx](https://github.com/OWASP/www-project-proactive-controls/blob/master/v2/OWASP_Top_Ten_Proactive_Controls_v2.pptx). 4 | 5 | ## OWASP Top 10 Proactive Controls 2016: 6 | 7 | - OWASP-2016-C1: Verify for Security Early and Often 8 | - OWASP-2016-C2: Parameterize Queries 9 | - OWASP-2016-C3: Encode Data 10 | - OWASP-2016-C4: Validate All Inputs 11 | - OWASP-2016-C5: Implement Identity and Authentication Controls 12 | - OWASP-2016-C6: Implement Appropriate Access Controls 13 | - OWASP-2016-C7: Protect Data 14 | - OWASP-2016-C8: Implement Logging and Intrusion Detection 15 | - OWASP-2016-C9: Leverage Security Frameworks and Libraries 16 | - OWASP-2016-C10: Error and Exception Handling 17 | 18 | ## Available Translations 19 | 20 | In alphabetical order: 21 | 22 | - Chinese: [pdf](https://github.com/OWASP/www-project-proactive-controls/blob/master/v2/OWASPTop10ProactiveControls2016-Chinese.pdf) 23 | - Hebrew: [pdf](https://github.com/OWASP/www-project-proactive-controls/blob/master/v2/OWASP_Proactive_Controls_2-Hebrew.pdf) 24 | - Japanese: [pdf](https://github.com/OWASP/www-project-proactive-controls/blob/master/v2/OWASPTop10ProactiveControls2016-Japanese.pdf) 25 | - Simplified Chinese: [pdf](https://github.com/OWASP/www-project-proactive-controls/blob/master/v2/OWASPTop10ProactiveControls2016-SimplifiedChinese.pdf) 26 | -------------------------------------------------------------------------------- /docs/archive/2018/0x01-about-owasp.md: -------------------------------------------------------------------------------- 1 | # About OWASP 2 | 3 | !!! warning "New Version Available!" 4 | 5 | You are looking at the legacy 2018 version of the OWASP Top 10 Proactive Controls. The current version is the [OWASP Top 10 Proactive Controls 2024](./../2024/introduction/about-owasp.md)! 6 | 7 | The *Open Web Application Security Project* (OWASP) is a 501c3 non for profit educational charity dedicated to enabling organizations to design, develop, acquire, operate, and maintain secure software. All OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security. We can be found at [www.owasp.org](https://www.owasp.org). 8 | 9 | OWASP is a new kind of organization. Our freedom from commercial pressures allows us to provide unbiased, practical, cost effective information about application security. 10 | 11 | OWASP is not affiliated with any technology company. Similar to many open source software projects, OWASP produces many types of materials in a collaborative and open way. The OWASP Foundation is a not-for-profit entity that ensures the project's long-term success. 12 | -------------------------------------------------------------------------------- /docs/archive/2018/0x02-about-project.md: -------------------------------------------------------------------------------- 1 | # About this Project 2 | 3 | !!! warning "New Version Available!" 4 | 5 | You are looking at the legacy 2018 version of the OWASP Top 10 Proactive Controls. The current version is the [OWASP Top 10 Proactive Controls 2024](./../2024/index.md)! 6 | 7 | Insecure software is undermining our financial, healthcare, defense, energy, and other critical infrastructure worldwide. As our digital, global infrastructure gets increasingly complex and interconnected, the difficulty of achieving application security increases exponentially. We can no longer afford to tolerate relatively simple security problems. 8 | 9 | ## Aim & Objective 10 | 11 | The goal of the **OWASP Top 10 Proactive Controls project** (OPC) is to raise awareness about application security by describing the most important areas of concern that software developers must be aware of. We encourage you to use the OWASP Proactive Controls to get your developers started with application security. Developers can learn from the mistakes of other organizations. We hope that the OWASP Proactive Controls is useful to your efforts in building secure software. 12 | 13 | ## Call to Action 14 | 15 | Please don’t hesitate to contact the OWASP Proactive Control project with your questions, comments, and ideas, either publicly to our email list or privately to [Jim Manico](mailto:jim@owasp.org). 16 | 17 | ## Copyright and Licence 18 | 19 | This document is released under the Creative Commons Attribution ShareAlike 3.0 license. For any reuse or distribution, you must make it clear to others the license terms of this work. 20 | 21 | ## Project Leaders 22 | 23 | * Katy Anton 24 | * Jim Bird 25 | * Jim Manico 26 | 27 | ## Contributors 28 | 29 | * Chris Romeo   | Dan Anderson   | David Cybuck 30 | * Dave Ferguson | Josh Grossman | Osama Elnaggar 31 | * Colin Watson   | Rick Mitchell   | And many more… 32 | -------------------------------------------------------------------------------- /docs/archive/2018/0x03-about-structure.md: -------------------------------------------------------------------------------- 1 | # Document Structure 2 | 3 | !!! warning "New Version Available!" 4 | 5 | You are looking at the legacy 2018 version of the OWASP Top 10 Proactive Controls. The current version is the [OWASP Top 10 Proactive Controls 2024](./../2024/index.md)! 6 | 7 | This document is structured as a list of security controls. Each control is described as follows: 8 | 9 | ## Cx: Control Name 10 | 11 | ### Description 12 | 13 | A detailed description of the control including some best practices to consider. 14 | 15 | ### Implementation 16 | 17 | Implementation best practices and examples to illustrate how to implement each control. 18 | 19 | ### Vulnerabilities Prevented 20 | 21 | List of prevented vulnerabilities or risks addressed (OWASP TOP 10 Risk, CWE, etc.) 22 | 23 | ### References 24 | 25 | List of references for further study (OWASP Cheat sheet, Security Hardening Guidelines, etc.) 26 | 27 | ### Tools 28 | 29 | Set of tools/projects to easily introduce/integrate security controls into your software. 30 | -------------------------------------------------------------------------------- /docs/archive/2018/0x04-introduction.md: -------------------------------------------------------------------------------- 1 | # Introduction 2 | 3 | !!! warning "New Version Available!" 4 | 5 | You are looking at the legacy 2018 version of the OWASP Top 10 Proactive Controls. The current version is the [OWASP Top 10 Proactive Controls 2024](./../2024/the-top-10/index.md)! 6 | 7 | The OWASP Top Ten Proactive Controls 2018 is a list of security techniques that should be considered for every software development project. This document is written for developers to assist those new to secure development. 8 | 9 | One of the main goals of this document is to provide concrete practical guidance that helps developers build secure software. These techniques should be applied proactively at the early stages of software development to ensure maximum effectiveness. 10 | 11 | ## The Top 10 Proactive Controls 12 | 13 | The list is ordered by importance with list item number 1 being the most important: 14 | 15 | * OWASP-2018-C1: Define Security Requirements 16 | * OWASP-2018-C2: Leverage Security Frameworks and Libraries 17 | * OWASP-2018-C3: Secure Database Access 18 | * OWASP-2018-C4: Encode and Escape Data 19 | * OWASP-2018-C5: Validate All Inputs 20 | * OWASP-2018-C6: Implement Digital Identity 21 | * OWASP-2018-C7: Enforce Access Controls 22 | * OWASP-2018-C8: Protect Data Everywhere 23 | * OWASP-2018-C9: Implement Security Logging and Monitoring 24 | * OWASP-2018-C10: Handle All Errors and Exceptions 25 | 26 | ## How this List Was Created 27 | 28 | This list was originally created by the current project leads with contributions from several volunteers. The document was then shared globally so even anonymous suggestions could be considered. Hundreds of changes were accepted from this open community process. 29 | 30 | ## Target Audience 31 | 32 | This document is primarily written for developers. However, development managers, product owners, Q/A professionals, program managers, and anyone involved in building software can also benefit from this document. 33 | 34 | ## How to Use this Document 35 | 36 | This document is intended to provide initial awareness around building secure software. This document will also provide a good foundation of topics to help drive introductory software security developer training. These controls should be used consistently and thoroughly throughout all applications. However, this document should be seen as a starting point rather than a comprehensive set of techniques and practices. A full secure development process should include comprehensive requirements from a standard such as the OWASP ASVS in addition to including a range of software development activities described in maturity models such as [OWASP SAMM](https://www.owasp.org/index.php/OWASP_SAMM_Project) and [BSIMM](https://www.bsimm.com/). 37 | 38 | ## Link to the OWASP Top 10 Project 39 | 40 | The OWASP Top 10 Proactive Controls is similar to the [OWASP Top 10](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) but is focused on defensive techniques and controls as opposed to risks. Each technique or control in this document will map to one or more items in the *risk based* OWASP Top 10. This mapping information is included at the end of each control description. 41 | -------------------------------------------------------------------------------- /docs/archive/2018/c1-security-requirements.md: -------------------------------------------------------------------------------- 1 | # C1: Define Security Requirements 2 | 3 | !!! warning "New Version of the Control Available!" 4 | 5 | You are looking at the legacy 2018 version of the OWASP Top 10 Proactive Controls. You can find information about the same control within the [OWASP Top 10 Proactive Controls 2024](./../2024/index.md) within [C4: Address Security from the Start](./../2024/the-top-10/c4-secure-architecture.md)! 6 | 7 | ## Description 8 | 9 | A security requirement is a statement of needed security functionality that ensures one of many different security properties of software is being satisfied. Security requirements are derived from industry standards, applicable laws, and a history of past vulnerabilities. Security requirements define new features or additions to existing features to solve a specific security problem or eliminate a potential vulnerability. 10 | 11 | Security requirements provide a foundation of vetted security functionality for an application. Instead of creating a custom approach to security for every application, standard security requirements allow developers to reuse the definition of security controls and best practices. Those same vetted security requirements provide solutions for security issues that have occurred in the past. Requirements exist to prevent the repeat of past security failures. 12 | 13 | ### The OWASP ASVS 14 | 15 | [The OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) is a catalog of available security requirements and verification criteria. OWASP ASVS can be a source of detailed security requirements for development teams. 16 | 17 | Security requirements are categorized into different buckets based on a shared higher order security function. For example, the ASVS contains categories such as authentication, access control, error handling / logging, and web services. Each category contains a collection of requirements that represent the best practices for that category drafted as verifiable statements. 18 | 19 | ### Augmenting Requirements with User Stories and Misuse Cases 20 | 21 | The ASVS requirements are basic verifiable statements which can be expanded upon with user stories and misuse cases. The advantage of a user story or misuse case is that it ties the application to exactly what the user or attacker does to the system, versus describing what the system offers to the user. 22 | 23 | Here is an example of expanding on an ASVS 3.0.1 requirement. From the "Authentication Verification Requirements" section of ASVS 3.0.1, requirement 2.19 focuses on default passwords. 24 | 25 | 2.19 Verify there are no default passwords in use for the application framework 26 | or any components used by the application (such as "admin/password"). 27 | 28 | This requirement contains both an action to verify that no default passwords exist, and also carries with it the guidance that no default passwords should be used within the application. 29 | 30 | A user story focuses on the perspective of the user, administrator, or attacker of the system, and describes functionality based on what a user wants the system to do for them. A user story takes the form of "As a user, I can do x, y, and z". 31 | 32 | As a user, I can enter my username and password to gain access to the application. 33 | As a user, I can enter a long password that has a maximum of 1023 characters. 34 | 35 | When the story is focused on the attacker and their actions, it is referred to as a misuse case. 36 | 37 | As an attacker, I can enter in a default username and password to gain access. 38 | 39 | This story contains the same message as the traditional requirement from ASVS, with additional user or attacker details to help make the requirement more testable. 40 | 41 | ## Implementation 42 | 43 | Successful use of security requirements involves four steps. The process includes discovering / selecting, documenting, implementing, and then confirming correct implementation of new security features and functionality within an application. 44 | 45 | ### Discovery and Selection 46 | 47 | The process begins with discovery and selection of security requirements. In this phase, the developer is understanding security requirements from a standard source such as ASVS and choosing which requirements to include for a given release of an application. The point of discovery and selection is to choose a manageable number of security requirements for this release or sprint, and then continue to iterate for each sprint, adding more security functionality over time. 48 | 49 | ### Investigation and Documentation 50 | 51 | During investigation and documentation, the developer reviews the existing application against the new set of security requirements to determine whether the application currently meets the requirement or if some development is required. This investigation culminates in the documentation of the results of the review. 52 | 53 | ### Implementation Phase 54 | 55 | After the need is determined for development, the developer must now modify the application in some way to add the new functionality or eliminate an insecure option. In this phase the developer first determines the design required to address the requirement, and then completes the code changes to meet the requirement. 56 | 57 | ### Test 58 | 59 | Test cases should be created to confirm the existence of the new functionality or disprove the existence of a previously insecure option. 60 | 61 | ## Vulnerabilities Prevented 62 | 63 | Security requirements define the security functionality of an application. Better security built in from the beginning of an applications life cycle results in the prevention of many types of vulnerabilities. 64 | 65 | ## References 66 | 67 | * [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) 68 | * [OWASP Mobile Application Security Verification Standard (MASVS)](https://owasp.org/www-project-mobile-security-testing-guide/) 69 | * [OWASP Top Ten](https://owasp.org/www-project-top-ten/) 70 | -------------------------------------------------------------------------------- /docs/archive/2018/c10-errors-exceptions.md: -------------------------------------------------------------------------------- 1 | # C10: Handle all Errors and Exceptions 2 | 3 | !!! warning "New Version of the Control Available!" 4 | 5 | You are looking at the legacy 2018 version of the OWASP Top 10 Proactive Controls. You can find information about the same control within the [OWASP Top 10 Proactive Controls 2024](./../2024/index.md) within [C3: Validate all Input & Handle Exceptions](./../2024/the-top-10/c3-validate-input-and-handle-exceptions.md)! 6 | 7 | ## Description 8 | 9 | Exception handling is a programming concept that allows an application to respond to different error states (like network down, or database connection failed, etc) in various ways. Handling exceptions and errors correctly is critical to making your code reliable and secure. 10 | 11 | Error and exception handling occurs in all areas of an application including critical business logic as well as security features and framework code. 12 | 13 | Error handling is also important from an intrusion detection perspective. Certain attacks against your application may trigger errors which can help detect attacks in progress. 14 | 15 | ## Error Handling Mistakes 16 | 17 | Researchers at the University of Toronto have found that even small mistakes in error handling or forgetting to handle errors can lead to [catastrophic failures in distributed systems](https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf). 18 | 19 | Mistakes in error handling can lead to different kinds of security vulnerabilities. 20 | 21 | * **Information leakage**: Leaking sensitive information in error messages can unintentionally help attackers. For example, an error that returns a stack trace or other internal error details can provide an attacker with information about your environment. Even small differences in handling different error conditions (e.g., returning "invalid user" or "invalid password" on authentication errors) can provide valuable clues to attackers. As described above, be sure to log error details for forensics and debugging purposes, but don’t expose this information, especially to an external client. 22 | * **TLS bypass**: The [Apple goto "fail bug"](https://www.dwheeler.com/essays/apple-goto-fail.html) was a control-flow error in error handling code that lead to a complete compromise of TLS connections on apple systems. 23 | * **DOS**: A lack of basic error handling can lead to system shutdown. This is usually a fairly easy vulnerability for attackers to exploit. Other error handling problems could lead to increased usage of CPU or disk in ways that could degrade the system. 24 | 25 | ## Positive Advice 26 | 27 | * Manage exceptions in a [centralized manner](https://www.owasp.org/index.php/Error_Handling#Centralised_exception_handling_.28Struts_Example.29) to avoid duplicated try/catch blocks in the code. Ensure that all unexpected behavior is correctly handled inside the application. 28 | * Ensure that error messages displayed to users do not leak critical data, but are still verbose enough to enable the proper user response. 29 | * Ensure that exceptions are logged in a way that gives enough information for support, QA, forensics or incident response teams to understand the problem. 30 | * Carefully test and verify error handling code. 31 | 32 | ## References 33 | 34 | * [OWASP Code Review Guide: Error Handling](https://www.owasp.org/index.php/Error_Handling) 35 | * [OWASP Testing Guide: Testing for Error Handling](https://www.owasp.org/index.php/Testing_for_Error_Handling) 36 | * [OWASP Improper Error Handling](https://www.owasp.org/index.php/Improper_Error_Handling) 37 | * [CWE 209: Information Exposure Through an Error Message](https://cwe.mitre.org/data/definitions/209.html) 38 | * [CWE 391: Unchecked Error Condition](https://cwe.mitre.org/data/definitions/391.html) 39 | 40 | ## Tools 41 | 42 | * [Error Prone](http://errorprone.info/) - A static analysis tool from Google to catch common mistakes in error handling for Java developers 43 | * One of the most famous automated tools for finding errors at runtime is [Netflix's Chaos Monkey](https://github.com/Netflix/SimianArmy), which intentionally disables system instances to ensure that the overall service will recover correctly. 44 | -------------------------------------------------------------------------------- /docs/archive/2018/c2-leverage-security-frameworks-libraries.md: -------------------------------------------------------------------------------- 1 | # C2: Leverage Security Frameworks and Libraries 2 | 3 | !!! warning "New Version of the Control Available!" 4 | 5 | You are looking at the legacy 2018 version of the OWASP Top 10 Proactive Controls. You can find information about the same control within the [OWASP Top 10 Proactive Controls 2024](./../2024/index.md) within [C6: Keep your Components Secure](./../2024/the-top-10/c6-use-secure-dependencies.md)! 6 | 7 | ## Description 8 | 9 | Secure coding libraries and software frameworks with embedded security help software developers guard against security-related design and implementation flaws. A developer writing an application from scratch might not have sufficient knowledge, time, or budget to properly implement or maintain security features. Leveraging security frameworks helps accomplish security goals more efficiently and accurately. 10 | 11 | ## Implementation Best Practices 12 | 13 | When incorporating third party libraries or frameworks into your software, it is important to consider the following best practices: 14 | 15 | 1. Use libraries and frameworks from trusted sources that are actively maintained and widely used by many applications. 16 | 2. Create and maintain an inventory catalog of all the third party libraries. 17 | 3. Proactively keep libraries and components up to date. Use a tool like [OWASP Dependency Check](https://owasp.org/www-project-dependency-check/) and [Retire.JS](https://retirejs.github.io/retire.js/) to identify project dependencies and check if there are any known, publicly disclosed vulnerabilities for all third party code. 18 | 4. Reduce the attack surface by encapsulating the library and expose only the required behaviour into your software. 19 | 20 | ## Vulnerabilities Prevented 21 | 22 | Secure frameworks and libraries can help to prevent a wide range of web application vulnerabilities. It is critical to keep these frameworks and libraries up to date as described in the [using components with known vulnerabilities [Top Ten 2017 risks](https://owasp.org/www-project-top-ten/). 23 | 24 | ## Tools 25 | 26 | * [OWASP Dependency Check](https://owasp.org/www-project-dependency-check/) - identifies project dependencies and checks for publicly disclosed vulnerabilities 27 | * [Retire.JS](http://retirejs.github.io/retire.js/) scanner for JavaScript libraries 28 | -------------------------------------------------------------------------------- /docs/archive/2018/c3-secure-database.md: -------------------------------------------------------------------------------- 1 | # C3: Secure Database Access 2 | 3 | !!! warning "New Version of the Control Available!" 4 | 5 | You are looking at the legacy 2018 version of the OWASP Top 10 Proactive Controls. You can find information about the same control within the [OWASP Top 10 Proactive Controls 2024](./../2024/index.md) within [C3: Validate all Input & Handle Exceptions](./../2024/the-top-10/c3-validate-input-and-handle-exceptions.md)! 6 | 7 | ## Description 8 | 9 | This section describes secure access to all data stores, including both relational databases and NoSQL databases. Some areas to consider: 10 | 11 | 1. Secure queries 12 | 2. Secure configuration 13 | 3. Secure authentication 14 | 4. Secure communication 15 | 16 | ### Secure Queries 17 | 18 | SQL Injection occurs when untrusted user input is dynamically added to a SQL query in an insecure manner, often via basic string concatenation. SQL Injection is one of the most dangerous application security risks. SQL Injection is easy to exploit and could lead to the entire database being stolen, wiped, or modified. The application can even be used to run dangerous commands against the operating system hosting your database, thereby giving an attacker a foothold on your network. 19 | 20 | In order to mitigate SQL injection, untrusted input should be prevented from being interpreted as part of a SQL command. The best way to do this is with the programming technique known as 'Query Parametrization'. This defense should be applied to SQL, OQL, as well as stored procedure construction. 21 | 22 | A good list of query parametrization examples in ASP, ColdFusion, C#, Delphi, .NET, Go, Java, Perl, PHP, PL/SQL, PostgreSQL, Python, R, Ruby and Scheme can be found at [https://bobby-tables.com](https://bobby-tables.com/) and the [OWASP Cheat Sheet on Query Parametrization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html). 23 | 24 | #### Caution on Query Parametrization 25 | 26 | Certain locations in a database query can not be used with parametrization. These locations are different for each database vendor. Be certain to do very careful exact-match validation or manual escaping when confronting database query parameters that cannot be bound to a parametrized query. Also, while the use of parametrized queries largely has a positive impact on performance, certain parametrized queries in specific database implementations will affect performance negatively. Be sure to test queries for performance; especially complex queries with extensive like clause or text searching capabilities. 27 | 28 | ### Secure Configuration 29 | 30 | Unfortunately, database management systems do not always ship in a "secure by default" configuration. Care must be taken to ensure that the security controls available from the Database Management System (DBMS) and hosting platform are enabled and properly configured. There are standards, guides, and benchmarks available for most common DBMS. 31 | 32 | A quick guidance on providing a secure configuration can be found in the [Database Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html#database-configuration-and-hardening). 33 | 34 | ### Secure Authentication 35 | 36 | All access to the database should be properly authenticated. Authentication to the DBMS should be accomplished in a secure manner. Authentication should take place only over a secure channel. Credentials must be properly secured and available for use. 37 | 38 | A quick guidance on providing a secure authentication process can be found in the [Database Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html#authentication). 39 | 40 | ### Secure Communication 41 | 42 | Most DBMS support a variety of communications methods (services, APIs, etc) - secure (authenticated, encrypted) and insecure (unauthenticated or unencrypted). It is a good practice to only use the secure communications options per the *Protect Data Everywhere* control. 43 | 44 | A quick guidance on providing a secure communication mean can be found in the [Database Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html#connecting-to-the-database). 45 | 46 | ## Vulnerabilities Prevented 47 | 48 | * [OWASP Top 10 2021-A3: Injection](https://owasp.org/Top10/A03_2021-Injection/) 49 | * [OWASP Mobile Top 10 2014-M1 Weak Server Side Controls](https://www.owasp.org/index.php/Mobile_Top_10_2014-M1) 50 | 51 | ## References 52 | 53 | * [OWASP Cheat Sheet: Query Parametrization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) 54 | * [OWASP Cheat Sheet: Database Security](https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html) 55 | * [Bobby Tables: A guide to preventing SQL injection](http://bobby-tables.com/) 56 | * [CIS Database Hardening Standards](https://www.cisecurity.org/cis-benchmarks/) 57 | -------------------------------------------------------------------------------- /docs/archive/2018/c4-encode-escape-data.md: -------------------------------------------------------------------------------- 1 | # C4: Encode and Escape Data 2 | 3 | !!! warning "New Version of the Control Available!" 4 | 5 | You are looking at the legacy 2018 version of the OWASP Top 10 Proactive Controls. You can find information about the same control within the [OWASP Top 10 Proactive Controls 2024](./../2024/index.md) within [C3: Validate all Input & Handle Exceptions](./../2024/the-top-10/c3-validate-input-and-handle-exceptions.md)! 6 | 7 | ## Description 8 | 9 | **Encoding** and escaping are defensive techniques meant to stop injection attacks. Encoding (commonly called "Output Encoding") involves translating special characters into some different but equivalent form that is no longer dangerous in the target interpreter, for example translating the ``<`` character into the ``<`` string when writing to an HTML page. **Escaping** involves adding a special character before the character/string to avoid it being misinterpreted, for example, adding a ``\`` character before a ``"`` (double quote) character so that it is interpreted as text and not as closing a string. 10 | 11 | Output encoding is best applied **just before** the content is passed to the target interpreter. If this defense is performed too early in the processing of a request then the encoding or escaping may interfere with the use of the content in other parts of the program. For example if you HTML escape content before storing that data in the database and the UI automatically escapes that data a second time then the content will not display properly due to being double escaped. 12 | 13 | ### Contextual Output Encoding 14 | 15 | Contextual output encoding is a crucial security programming technique needed to stop XSS. This defense is performed on output, when you're building a user interface, at the last moment before untrusted data is dynamically added to HTML. The type of encoding will depend on the location (or context) in the document where data is being displayed or stored. The different types of encoding that would be used for building secure user interfaces includes HTML Entity Encoding, HTML Attribute Encoding, JavaScript Encoding, and URL Encoding. 16 | 17 | #### Java Encoding Examples 18 | 19 | For examples of the OWASP Java Encoder providing contextual output encoding see: [OWASP Java Encoder Project Examples](https://www.owasp.org/index.php/OWASP_Java_Encoder_Project#tab=Use_the_Java_Encoder_Project). 20 | 21 | #### .NET Encoding Examples 22 | 23 | Starting with .NET 4.5 , the Anti-Cross Site Scripting library is part of the framework, but not enabled by default. You can specify to use AntiXssEncoder from this library as the default encoder for your entire application using the `web.conf` settings. When applied is important to contextual encode your output - that means to use the right function from the AntiXSSEncoder library for the appropriate location of data in document. 24 | 25 | #### PHP Encoding Examples 26 | 27 | #### Zend Framework 2 28 | 29 | In Zend Framework 2, ``Zend\Escaper`` can be used for encoding the output. For contextual encoding examples see [Context-specific escaping with Zend-Escaper](https://framework.zend.com/blog/2017-05-16-zend-escaper.html). 30 | 31 | ### Other Types of Encoding and Injection Defense 32 | 33 | Encoding/Escaping can be used to neutralize content against other forms of injection. For example, it's possible to neutralize certain special meta-characters when adding input to an operating system command. This is called "OS command escaping", "shell escaping", or similar. This defense can be used to stop "Command Injection" vulnerabilities. 34 | 35 | There are other forms of escaping that can be used to stop injection such as XML attribute escaping stopping various forms of XML and XML path injection, as well as LDAP distinguished name escaping that can be used to stop various forms of LDAP injection. 36 | 37 | ### Character Encoding and Canonicalization 38 | 39 | Unicode Encoding is a method for storing characters with multiple bytes. Wherever input data is allowed, data can be entered using [Unicode](https://www.owasp.org/index.php/Unicode_Encoding) to disguise malicious code and permit a variety of attacks. [RFC 2279](https://tools.ietf.org/html/rfc2279) references many ways that text can be encoded. 40 | 41 | Canonicalization is a method in which systems convert data into a simple or standard form. Web applications commonly use character canonicalization to ensure all content is of the same character type when stored or displayed. 42 | 43 | To be secure against canonicalization related attacks means an application should be safe when malformed Unicode and other malformed character representations are entered. 44 | 45 | ## Vulnerabilities Prevented 46 | 47 | * [OWASP Top 10 2017 - A1: Injection](https://www.owasp.org/index.php/Top_10-2017_A1-Injection) 48 | * [OWASP Top 10 2017 - A7: Cross Site Scripting (XSS)](https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)) 49 | * [OWASP Mobile_Top_10_2014-M7 Client Side Injection](https://www.owasp.org/index.php/Mobile_Top_10_2014-M7) 50 | 51 | ## References 52 | 53 | * [XSS](https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)) - General information 54 | * [OWASP Cheat Sheet: XSS Prevention](https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet) - Stopping XSS in your web application 55 | * [OWASP Cheat Sheet: DOM based XSS Prevention](https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet) 56 | * [OWASP Cheat Sheet: Injection Prevention](https://www.owasp.org/index.php/Injection_Prevention_Cheat_Sheet) 57 | 58 | ## Tools 59 | 60 | * [OWASP Java Encoder Project](https://www.owasp.org/index.php/OWASP_Java_Encoder_Project) 61 | * [AntiXssEncoder](https://docs.microsoft.com/en-us/dotnet/api/system.web.security.antixss.antixssencoder?redirectedfrom=MSDN&view=netframework-4.7.2) 62 | * [Zend\Escaper](https://framework.zend.com/blog/2017-05-16-zend-escaper.html) - examples of contextual encoding 63 | -------------------------------------------------------------------------------- /docs/archive/2018/c5-validate-inputs.md: -------------------------------------------------------------------------------- 1 | # C5: Validate All Inputs 2 | 3 | !!! warning "New Version of the Control Available!" 4 | 5 | You are looking at the legacy 2018 version of the OWASP Top 10 Proactive Controls. You can find information about the same control within the [OWASP Top 10 Proactive Controls 2024](./../2024/index.md) within [C3: Validate all Input & Handle Exceptions](./../2024/the-top-10/c3-validate-input-and-handle-exceptions.md)! 6 | 7 | ## Description 8 | 9 | Input validation is a programming technique that ensures only properly formatted data may enter a software system component. 10 | 11 | ### Syntax and Semantic Validity 12 | 13 | An application should check that data is both *syntactically* and *semantically* valid (in that order) before using it in any way (including displaying it back to the user). 14 | 15 | **Syntax validity** means that the data is in the form that is expected. For example, an application may allow a user to select a four-digit "account ID" to perform some kind of operation. The application should assume the user is entering a SQL injection payload, and should check that the data entered by the user is exactly four digits in length, and consists only of numbers (in addition to utilizing proper query parametrization). 16 | 17 | **Semantic validity** includes only accepting input that is within an acceptable range for the given application functionality and context. For example, a start date must be before an end date when choosing date ranges. 18 | 19 | ### Allowlisting vs Denylisting 20 | 21 | There are two general approaches to performing input syntax validation, commonly known as allow and deny lists: 22 | 23 | * **Denylisting** or **denylist validation*** attempts to check that given data does not contain "known bad" content. For example, a web application may block input that contains the exact text ``