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.
"},{"location":"#aim-objective","title":"Aim & Objective","text":"The goal of the OWASP Top 10 Proactive Controls project 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.
"},{"location":"#target-audience","title":"Target Audience","text":"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.
"},{"location":"#how-to-use-this-document","title":"How to Use this Document","text":"This document\u2019s main purpose is to provide a solid foundation of topics to help drive introductory software security developer training. To be effective, these controls should be used consistently and thoroughly throughout all applications.
However, this document is a starting point rather than a comprehensive set of techniques and practices.
A fully 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 and BSIMM.
"},{"location":"#project-leaders","title":"Project Leaders","text":"This document is released under the Creative Commons Attribution-ShareAlike 4.0 International license. For any reuse or distribution, you must make it clear to others the license terms of this work.
"},{"location":"final-word/","title":"Final word","text":"This document should be seen as a starting point rather than a comprehensive set of techniques and practices. We want to again emphasize that this document is intended to provide initial awareness around building secure software.
Good next steps to help build an application security program include:
This document would not have been possible without our contributors for which we are grateful.
From the shared 2024 document and according to github:
Introduction of the OWASP Top 10 Proactive Controls v4 and switch to new wiki system.
gbhackers. post OWASP Top 10 Proactive Security Controls For Software Developers to Build Secure SoftwareThe OWASP Top 10 Proactive Controls 2018 (v3) were released.
The OWASP Top 10 Proactive Controls 2016 (v2) were released on Jan 14, 2016.
Starting with version v4 in 2024, we don't accept inclusion of translations into the OWASP Top 10 Proactive Controls directly and are only providing the English version.
We do encourage translators to create translated versions and host them themselves and will link to those external sites/documents if notified about them.
"},{"location":"about-top-10/old-versions-and-translations/#owasp-top-10-proactive-controls-2018-v3","title":"OWASP Top 10 Proactive Controls 2018 (v3)","text":"You can find the OWASP Top 10 Proactive Controls 2018 on GitHub:
We also provide a Mapping to the OWASP Top 10 and IEEE Top 10.
"},{"location":"about-top-10/old-versions-and-translations/#owasp-top-10-proactive-controls-2016-v2","title":"OWASP Top 10 Proactive Controls 2016 (v2)","text":"You can find the OWASP Top 10 Proactive Controls 2016 (v2) on GitHub:
They might be somewhere..
"},{"location":"archive/2014/","title":"OWASP Top 10 Proactive Controls v1/2014","text":"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.
OWASP is a new kind of organization. Our freedom from commercial pressures allows us to provide unbiased, practical, cost effective information about application security.
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.
"},{"location":"archive/2018/0x02-about-project/","title":"About this Project","text":"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.
"},{"location":"archive/2018/0x02-about-project/#aim-objective","title":"Aim & Objective","text":"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.
"},{"location":"archive/2018/0x02-about-project/#call-to-action","title":"Call to Action","text":"Please don\u2019t 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.
"},{"location":"archive/2018/0x02-about-project/#copyright-and-licence","title":"Copyright and Licence","text":"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.
"},{"location":"archive/2018/0x02-about-project/#project-leaders","title":"Project Leaders","text":"This document is structured as a list of security controls. Each control is described as follows:
"},{"location":"archive/2018/0x03-about-structure/#cx-control-name","title":"Cx: Control Name","text":""},{"location":"archive/2018/0x03-about-structure/#description","title":"Description","text":"A detailed description of the control including some best practices to consider.
"},{"location":"archive/2018/0x03-about-structure/#implementation","title":"Implementation","text":"Implementation best practices and examples to illustrate how to implement each control.
"},{"location":"archive/2018/0x03-about-structure/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"List of prevented vulnerabilities or risks addressed (OWASP TOP 10 Risk, CWE, etc.)
"},{"location":"archive/2018/0x03-about-structure/#references","title":"References","text":"List of references for further study (OWASP Cheat sheet, Security Hardening Guidelines, etc.)
"},{"location":"archive/2018/0x03-about-structure/#tools","title":"Tools","text":"Set of tools/projects to easily introduce/integrate security controls into your software.
"},{"location":"archive/2018/0x04-introduction/","title":"Introduction","text":"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.
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.
"},{"location":"archive/2018/0x04-introduction/#the-top-10-proactive-controls","title":"The Top 10 Proactive Controls","text":"The list is ordered by importance with list item number 1 being the most important:
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.
"},{"location":"archive/2018/0x04-introduction/#target-audience","title":"Target Audience","text":"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.
"},{"location":"archive/2018/0x04-introduction/#how-to-use-this-document","title":"How to Use this Document","text":"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 and BSIMM.
"},{"location":"archive/2018/0x04-introduction/#link-to-the-owasp-top-10-project","title":"Link to the OWASP Top 10 Project","text":"The OWASP Top 10 Proactive Controls is similar to the OWASP Top 10 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.
"},{"location":"archive/2018/c1-security-requirements/","title":"C1: Define Security Requirements","text":""},{"location":"archive/2018/c1-security-requirements/#description","title":"Description","text":"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.
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.
"},{"location":"archive/2018/c1-security-requirements/#the-owasp-asvs","title":"The OWASP ASVS","text":"The OWASP Application Security Verification Standard (ASVS) is a catalog of available security requirements and verification criteria. OWASP ASVS can be a source of detailed security requirements for development teams.
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.
"},{"location":"archive/2018/c1-security-requirements/#augmenting-requirements-with-user-stories-and-misuse-cases","title":"Augmenting Requirements with User Stories and Misuse Cases","text":"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.
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.
2.19 Verify there are no default passwords in use for the application framework \n or any components used by the application (such as \"admin/password\").\nThis 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.
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\".
As a user, I can enter my username and password to gain access to the application.\nAs a user, I can enter a long password that has a maximum of 1023 characters.\nWhen the story is focused on the attacker and their actions, it is referred to as a misuse case.
As an attacker, I can enter in a default username and password to gain access.\nThis story contains the same message as the traditional requirement from ASVS, with additional user or attacker details to help make the\u00a0requirement more testable.
"},{"location":"archive/2018/c1-security-requirements/#implementation","title":"Implementation","text":"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.
"},{"location":"archive/2018/c1-security-requirements/#discovery-and-selection","title":"Discovery and Selection","text":"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.
"},{"location":"archive/2018/c1-security-requirements/#investigation-and-documentation","title":"Investigation and Documentation","text":"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.
"},{"location":"archive/2018/c1-security-requirements/#implementation-phase","title":"Implementation Phase","text":"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.
"},{"location":"archive/2018/c1-security-requirements/#test","title":"Test","text":"Test cases should be created to confirm the existence of the new functionality or disprove the existence of a previously insecure option.
"},{"location":"archive/2018/c1-security-requirements/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"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.
"},{"location":"archive/2018/c1-security-requirements/#references","title":"References","text":"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.
Error and exception handling occurs in all areas of an application including critical business logic as well as security features and framework code.
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.
"},{"location":"archive/2018/c10-errors-exceptions/#error-handling-mistakes","title":"Error Handling Mistakes","text":"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.
Mistakes in error handling can lead to different kinds of security vulnerabilities.
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.
"},{"location":"archive/2018/c2-leverage-security-frameworks-libraries/#implementation-best-practices","title":"Implementation Best Practices","text":"When incorporating third party libraries or frameworks into your software, it is important to consider the following best practices:
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.
"},{"location":"archive/2018/c2-leverage-security-frameworks-libraries/#tools","title":"Tools","text":"This section describes secure access to all data stores, including both relational databases and NoSQL databases. Some areas to consider:
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.
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.
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 and the OWASP Cheat Sheet on Query Parametrization.
"},{"location":"archive/2018/c3-secure-database/#caution-on-query-parametrization","title":"Caution on Query Parametrization","text":"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.
"},{"location":"archive/2018/c3-secure-database/#secure-configuration","title":"Secure Configuration","text":"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.
A quick guidance on providing a secure configuration can be found in the Database Cheat Sheet.
"},{"location":"archive/2018/c3-secure-database/#secure-authentication","title":"Secure Authentication","text":"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.
A quick guidance on providing a secure authentication process can be found in the Database Cheat Sheet.
"},{"location":"archive/2018/c3-secure-database/#secure-communication","title":"Secure Communication","text":"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.
A quick guidance on providing a secure communication mean can be found in the Database Cheat Sheet.
"},{"location":"archive/2018/c3-secure-database/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"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.
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.
"},{"location":"archive/2018/c4-encode-escape-data/#contextual-output-encoding","title":"Contextual Output Encoding","text":"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.
"},{"location":"archive/2018/c4-encode-escape-data/#java-encoding-examples","title":"Java Encoding Examples","text":"For examples of the OWASP Java Encoder providing contextual output encoding see: OWASP Java Encoder Project Examples.
"},{"location":"archive/2018/c4-encode-escape-data/#net-encoding-examples","title":".NET Encoding Examples","text":"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.
In Zend Framework 2, Zend\\Escaper can be used for encoding the output. For contextual encoding examples see Context-specific escaping with Zend-Escaper.
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.
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.
"},{"location":"archive/2018/c4-encode-escape-data/#character-encoding-and-canonicalization","title":"Character Encoding and Canonicalization","text":"Unicode Encoding is a method for storing characters with multiple bytes. Wherever input data is allowed, data can be entered using Unicode to disguise malicious code and permit a variety of attacks. RFC 2279 references many ways that text can be encoded.
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.
To be secure against canonicalization related attacks means an application should be safe when malformed Unicode and other malformed character representations are entered.
"},{"location":"archive/2018/c4-encode-escape-data/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"Input validation is a programming technique that ensures only properly formatted data may enter a software system component.
"},{"location":"archive/2018/c5-validate-inputs/#syntax-and-semantic-validity","title":"Syntax and Semantic Validity","text":"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).
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).
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.
"},{"location":"archive/2018/c5-validate-inputs/#allowlisting-vs-denylisting","title":"Allowlisting vs Denylisting","text":"There are two general approaches to performing input syntax validation, commonly known as allow and deny lists:
<SCRIPT> in order to help prevent XSS. However, this defense could be evaded with a lower case script tag or a script tag of mixed case.Important When building secure software, allowlisting is the recommended minimal approach. Denylisting is prone to error and can be bypassed with various evasion techniques and can be dangerous when depended on by itself. Even though denylisting can often be evaded, it can often be useful to help detect obvious attacks. So while allowlisting helps limit the attack surface by ensuring data is of the right syntactic and semantic validity, denylisting helps detect and potentially stop obvious attacks.
"},{"location":"archive/2018/c5-validate-inputs/#client-side-and-server-side-validation","title":"Client side and Server side Validation","text":"Input validation must always be done on the server-side for security. While client side validation can be useful for both functional and some security purposes, it can often be easily bypassed. This makes server-side validation even more fundamental to security. For example, JavaScript validation may alert the user that a particular field must consist of numbers but the server side application must validate that the submitted data only consists of numbers in the appropriate numerical range for that feature.
"},{"location":"archive/2018/c5-validate-inputs/#regular-expressions","title":"Regular Expressions","text":"Regular expressions offer a way to check whether data matches a specific pattern. Let\u2019s start with a basic example.
The following regular expression is used to define a allowlist rule to validate usernames.
^[a-z0-9_]{3,16}$\nThis regular expression allows only lowercase letters, numbers and the underscore character. The username is also restricted to a length of 3 and 16 characters.
"},{"location":"archive/2018/c5-validate-inputs/#caution-potential-for-denial-of-service","title":"Caution: Potential for Denial of Service","text":"Care should be exercised when creating regular expressions. Poorly designed expressions may result in potential denial of service conditions (aka ReDoS ). Various tools can test to verify that regular expressions are not vulnerable to ReDoS.
"},{"location":"archive/2018/c5-validate-inputs/#caution-complexity","title":"Caution: Complexity","text":"Regular expressions are just one way to accomplish validation. Regular expressions can be difficult to maintain or understand for some developers. Other validation alternatives involve writing validation methods programmatically which can be easier to maintain for some developers.
"},{"location":"archive/2018/c5-validate-inputs/#limits-of-input-validation","title":"Limits of Input Validation","text":"Input validation does not always make data \"safe\" since certain forms of complex input may be \"valid\" but still dangerous. For example, a valid email address may contain a SQL injection attack or a valid URL may contain a Cross Site Scripting attack. Additional defenses besides input validation should always be applied to data such as query parametrization or escaping.
"},{"location":"archive/2018/c5-validate-inputs/#challenges-of-validating-serialized-data","title":"Challenges of Validating Serialized Data","text":"Some forms of input are so complex that validation can only minimally protect the application. For example, it's dangerous to deserialize untrusted data or data that can be manipulated by an attacker. The only safe architectural pattern is to not accept serialized objects from untrusted sources or to only deserialize in limited capacity for only simple data types. You should avoid processing serialized data formats and use easier to defend formats such as JSON when possible.
If that is not possible then consider a series of validation defenses when processing serialized data.
Some frameworks support automatic binding of HTTP requests parameters to server-side objects used by the application. This auto-binding feature can allow an attacker to update server-side objects that were not meant to be modified. The attacker can possibly modify their access control level or circumvent the intended business logic of the application with this feature.
This attack has a number of names including: mass assignment, autobinding and object injection.
As a simple example, if the user object has a field named privilege which specifies the user's privilege level in the application, a malicious user can look for pages where user data is modified and add privilege=admin to the HTTP parameters sent. If auto-binding is enabled in an insecure fashion, the server-side object representing the user will be modified accordingly.
Two approaches can be used to handle this:
More examples are available in the OWASP Mass Assignment Cheat Sheet.
"},{"location":"archive/2018/c5-validate-inputs/#validating-and-sanitizing-html","title":"Validating and Sanitizing HTML","text":"Consider an application that needs to accept HTML from users (via a WYSIWYG editor that represents content as HTML or features that directly accept HTML in input). In this situation validation or escaping will not help.
Therefore, you need a library that can parse and clean HTML formatted text. Please see the XSS Prevention Cheat Sheet on HTML Sanitization for more information on HTML Sanitization.
"},{"location":"archive/2018/c5-validate-inputs/#validation-functionality-in-libraries-and-frameworks","title":"Validation Functionality in Libraries and Frameworks","text":"All languages and most frameworks provide validation libraries or functions which should be leveraged to validate data. Validation libraries typically cover common data types, length requirements, integer ranges, \"is null\" checks and more. Many validation libraries and frameworks allow you to define your own regular expression or logic for custom validation in a way that allows the programmer to leverage that functionality throughout your application. Examples of validation functionality include PHP\u2019s filter functions or the Hibernate Validator for Java. Examples of HTML Sanitizers include Ruby on Rails sanitize method, OWASP Java HTML Sanitizer or DOMPurify.
"},{"location":"archive/2018/c5-validate-inputs/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"Digital Identity is the unique representation of a user (or other subject) as they engage in an online transaction. Authentication is the process of verifying that an individual or entity is who they claim to be. Session management is a process by which a server maintains the state of the users authentication so that the user may continue to use the system without re-authenticating. The NIST Special Publication 800-63B: Digital Identity Guidelines (Authentication and Life Cycle Management) provides solid guidance on implementing digital identity, authentication and session management controls.
Below are some recommendations for secure implementation.
"},{"location":"archive/2018/c6-digital-identity/#authentication-levels","title":"Authentication Levels","text":"NIST 800-63b describes three levels of a authentication assurance called a authentication assurance level (AAL). AAL level 1 is reserved for lower-risk applications that do not contain PII or other private data. At AAL level 1 only single-factor authentication is required, typically through the use of a password.
"},{"location":"archive/2018/c6-digital-identity/#level-1-passwords","title":"Level 1 : Passwords","text":"Passwords are really really important. We need policy, we need to store them securely, we need to sometimes allow users to reset them.
"},{"location":"archive/2018/c6-digital-identity/#password-requirements","title":"Password Requirements","text":"Passwords should comply with the following requirements at the very least:
It is common for an application to have a mechanism for a user to gain access to their account in the event they forget their password. A good design workflow for a password recovery feature will use multi-factor authentication elements. For example, it may ask a security question - something they know, and then send a generated token to a device - something they own.
Please see the Forgot Password Cheat Sheet and Choosing and Using Security Questions Cheat Sheet for further details.
"},{"location":"archive/2018/c6-digital-identity/#implement-secure-password-storage","title":"Implement Secure Password Storage","text":"In order to provide strong authentication controls, an application must securely store user credentials. Furthermore, cryptographic controls should be in place such that if a credential (e.g., a password) is compromised, the attacker does not immediately have access to this information.
"},{"location":"archive/2018/c6-digital-identity/#php-example-for-password-storage","title":"PHP Example for Password Storage","text":"Below is an example for secure password hashing in PHP using password_hash() function (available since 5.5.0) which defaults to using the bcrypt algorithm. The example uses a work factor of 15.
<?php\n $cost = 15;\n $password_hash = password_hash(\"secret_password\", PASSWORD_DEFAULT,[\"cost\" => $cost]);\n?>\nPlease see the OWASP Password Storage Cheat Sheet for further details.
"},{"location":"archive/2018/c6-digital-identity/#level-2-multi-factor-authentication","title":"Level 2 : Multi-Factor Authentication","text":"NIST 800-63b AAL level 2 is reserved for higher-risk applications that contain \"self-asserted PII or other personal information made available online.\" At AAL level 2 multi-factor authentication is required including OTP or other forms of multi-factor implementation.
Multi-factor authentication (MFA) ensures that users are who they claim to be by requiring them to identify themselves with a combination of:
Using passwords as a sole factor provides weak security. Multi-factor solutions provide a more robust solution by requiring an attacker to acquire more than one element to authenticate with the service.
It is worth noting that biometrics, when employed as a single factor of authentication, are not considered acceptable secrets for digital authentication. They can be obtained online or by taking a picture of someone with a camera phone (e.g., facial images) with or without their knowledge, lifted from objects someone touches (e.g., latent fingerprints), or captured with high resolution images (e.g., iris patterns). Biometrics must be used only as part of multi-factor authentication with a physical authenticator (something you own). For example, accessing a multi-factor one-time password (OTP) device that will generate a one-time password that the user manually enters for the verifier.
"},{"location":"archive/2018/c6-digital-identity/#level-3-cryptographic-based-authentication","title":"Level 3 : Cryptographic Based Authentication","text":"NIST 800-63b Authentication Assurance Level 3 (AAL3) is required when the impact of compromised systems could lead to personal harm, significant financial loss, harm the public interest or involve civil or criminal violations. AAL3 requires authentication that is \"based on proof of possession of a key through a cryptographic protocol.\" This type of authentication is used to achieve the strongest level of authentication assurance. This is typically done though hardware cryptographic modules.
"},{"location":"archive/2018/c6-digital-identity/#session-management","title":"Session Management","text":"Once the initial successful user authentication has taken place, an application may choose to track and maintain this authentication state for a limited amount of time. This will allow the user to continue using the application without having to keep re-authentication with each request. Tracking of this user state is called Session Management.
"},{"location":"archive/2018/c6-digital-identity/#session-generation-and-expiration","title":"Session Generation and Expiration","text":"User state is tracked in a session. This session is typically stored on the server for traditional web based session management. A session identifier is then given to the user so the user can identify which server-side session contains the correct user data. The client only needs to maintain this session identifier, which also keeps sensitive server-side session data off of the client.
Here are a few controls to consider when building or implementing session management solutions:
Please see the Session Management Cheat Sheet further details. ASVS Section 3 covers additional session management requirements.
"},{"location":"archive/2018/c6-digital-identity/#browser-cookies","title":"Browser Cookies","text":"Browser cookies are a common method for web application to store session identifiers for web applications implementing standard session management techniques. Here are some defenses to consider when using browser cookies.
Server-side sessions can be limiting for some forms of authentication. \"Stateless services\" allow for client side management of session data for performance purposes so they server has less of a burden to store and verify user session. These \"stateless\" applications generate a short-lived access token which can be used to authenticate a client request without sending the user's credentials after the initial authentication.
"},{"location":"archive/2018/c6-digital-identity/#jwt-json-web-tokens","title":"JWT (JSON Web Tokens)","text":"JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. A JWT token is created during authentication and is verified by the server (or servers) before any processing.
However, JWTs are often not saved by the server after initial creation. JWTs are typically created and then handed to a client without being saved by the server in any way. The integrity of the token is maintained through the use of digital signatures so a server can later verify that the JWT is still valid and was not tampered with since its creation.
This approach is both stateless and portable in the way that client and server technologies can be different yet still interact.
Caution: Digital identity, authentication and session management are very big topics. We're scratching the surface of the topic of Digital Identity here. Ensure that your most capable engineering talent is responsible for maintaining the complexity involved with most Identity solutions.
"},{"location":"archive/2018/c6-digital-identity/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"Access Control (or Authorization) is the process of granting or denying specific requests from a user, program, or process. Access control also involves the act of granting and revoking those privileges.
It should be noted that authorization (verifying access to specific features or resources) is not equivalent to authentication (verifying identity).
Access Control functionality often spans many areas of software depending on the complexity of the access control system. For example, managing access control metadata or building caching for scalability purposes are often additional components in an access control system that need to be built or managed. There are several different types of access control design that should be considered.
The following \"positive\" access control design requirements should be considered at the initial stages of application development.
"},{"location":"archive/2018/c7-enforce-access-controls/#1-design-access-control-thoroughly-up-front","title":"1) Design Access Control Thoroughly Up Front","text":"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 design that must be thoroughly designed up front, especially when addressing requirements like multi-tenancy and horizontal (data dependent) access control.
Access Control design may start simple but can often grow into a complex and feature-heavy security control. When evaluating access control capability of software frameworks, ensure that your access control functionality will allow for customization for your specific access control feature need.
"},{"location":"archive/2018/c7-enforce-access-controls/#2-force-all-requests-to-go-through-access-control-checks","title":"2) Force All Requests to Go Through Access Control Checks","text":"Ensure that all request go through some kind of access control verification layer. Technologies like Java filters or other automatic request processing mechanisms are ideal programming artifacts that will help ensure that all requests go through some kind of access control check.
"},{"location":"archive/2018/c7-enforce-access-controls/#3-deny-by-default","title":"3) Deny by Default","text":"Deny by default is the principle that if a request is not specifically allowed, it is denied. There are many ways that this rule will manifest in application code. Some examples of these are:
Ensure that all users, programs, or processes are only given as least or as little necessary access as possible. Be wary of systems that do not provide granular access control configuration capabilities.
"},{"location":"archive/2018/c7-enforce-access-controls/#5-dont-hard-code-roles","title":"5) Don't Hard-Code Roles","text":"Many application frameworks default to access control that is role based. It is common to find application code that is filled with checks of this nature.
if (user.hasRole(\"ADMIN\")) || (user.hasRole(\"MANAGER\")) {\n deleteAccount();\n }\nBe careful about this type of role-based programming in code. It has the following limitations or dangers.
Instead, please consider the following access control programming methodology:
if (user.hasAccess(\"DELETE_ACCOUNT\")) {\n deleteAccount();\n }\nAttribute or feature-based access control checks of this nature are the starting point to building well-designed and feature-rich access control systems. This type of programming also allows for greater access control customization capability over time.
"},{"location":"archive/2018/c7-enforce-access-controls/#6-log-all-access-control-events","title":"6) Log All Access Control Events","text":"All access control failures should be logged as these may be indicative of a malicious user probing the application for vulnerabilities.
"},{"location":"archive/2018/c7-enforce-access-controls/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"Sensitive data such as passwords, credit card numbers, health records, personal information and business secrets require extra protection, particularly if that data falls under privacy laws (EU's General Data Protection Regulation GDPR), financial data protection rules such as PCI Data Security Standard (PCI DSS) or other regulations.
Attackers can steal data from web and web-service applications in a number of ways. For example, if sensitive information in sent over the internet without communications security, then an attacker on a shared wireless connection could see and steal another user's data. Also, an attacker could use SQL Injection to steal passwords and other credentials from an applications database and expose that information to the public.
"},{"location":"archive/2018/c8-protect-data-everywhere/#data-classification","title":"Data Classification","text":"It's critical to classify data in your system and determine which level of sensitivity each piece of data belongs to. Each data category can then be mapped to protection rules necessary for each level of sensitivity. For example, public marketing information that is not sensitive may be categorized as public data which is okay to place on the public website. Credit card numbers may be classified as private user data which may need to be encrypted while stored or in transit.
"},{"location":"archive/2018/c8-protect-data-everywhere/#encrypting-data-in-transit","title":"Encrypting Data in Transit","text":"When transmitting sensitive data over any network, end-to-end communications security (or encryption-in-transit) of some kind should be considered. TLS is by far the most common and widely supported cryptographic protocol for communications security. It is used by many types of applications (web, web service, mobile) to communicate over a network in a secure fashion. TLS must be properly configured in a variety of ways in order to properly defend secure communications.
The primary benefit of transport layer security is the protection of web application data from unauthorized disclosure and modification when it is transmitted between clients (web browsers) and the web application server, and between the web application server and back end and other non-browser based enterprise components.
"},{"location":"archive/2018/c8-protect-data-everywhere/#encrypting-data-at-rest","title":"Encrypting Data at Rest","text":"The first rule of sensitive data management is to avoid storing sensitive data when at all possible. If you must store sensitive data then make sure it's cryptographically protected in some way to avoid unauthorized disclosure and modification.
Cryptography (or crypto) is one of the more advanced topics of information security, and one whose understanding requires the most schooling and experience. It is difficult to get right because there are many approaches to encryption, each with advantages and disadvantages that need to be thoroughly understood by web solution architects and developers. In addition, serious cryptography research is typically based in advanced mathematics and number theory, providing a serious barrier to entry.
Instead of building cryptographic capability from scratch, it is strongly recommended that peer reviewed and open solutions be used, such as the Google Tink project, Libsodium, and secure storage capability built into many software frameworks and cloud services.
"},{"location":"archive/2018/c8-protect-data-everywhere/#mobile-application-secure-local-storage","title":"Mobile Application: Secure Local Storage","text":"Mobile applications are at particular risk of data leakage because mobile devices are regularly lost or stolen yet contain sensitive data.
As a general rule, only the minimum data required should be stored on the mobile device. But if you must store sensitive data on a mobile device, then sensitive data should be stored within each mobile operating systems specific data storage directory. On Android this will be the Android keystore and on iOS this will be the iOS keychain.
"},{"location":"archive/2018/c8-protect-data-everywhere/#secret-life-cycle","title":"Secret Life Cycle","text":"Secret keys can be used in a number of sensitive functions. For example, they can be used to sign JWTs, encrypt credit cards, sign hash, provide various forms of authentication and more. In managing keys, a number of precautious should be adhered including but not limited to the following:
When an immutable datatype such as string is used to store secrets, secrets can remain plaintext in the memory for a long time. Even if you try to nullify the string value, it still remains in the memory. string is an immutable type and cannot be changed. When you modify a string (try to overwrite it), a new copy of it is created. This means another copy of the unprotected secret will remain in the memory. Furthermore, there is no guarantee when garbage collector is going to clean up the secret. This increases exposure of plaintext secrets in the memory.
If secrets remain unprotected in the memory, they can get disclosed on the disk or external log aggregators through a number of scenarios: server crash logs, caching, serialisation or memory paging.
A safe way to handle secret is by using Read Once pattern. Read once is a defensive design pattern where a value can be only accessed once. After the first read, value is cleared from memory, and subsequent access is not possible. For an example implementation see this post.
"},{"location":"archive/2018/c8-protect-data-everywhere/#application-secrets-management","title":"Application Secrets Management","text":"Applications contain numerous \"secrets\" that are needed for security operations. These include certificates, SQL connection passwords, third party service account credentials, passwords, SSH keys, encryption keys and more. The unauthorized disclosure or modification of these secrets could lead to complete system compromise. In managing application secrets, consider the following.
Logging is a concept that most developers already use for debugging and diagnostic purposes. Security logging is an equally basic concept: to log security information during the runtime operation of an application. Monitoring is the live review of application and security logs using various forms of automation. The same tools and patterns can be used for operations, debugging and security purposes.
"},{"location":"archive/2018/c9-security-logging/#benefits-of-security-logging","title":"Benefits of Security Logging","text":"Security logging can be used for:
The following is a list of security logging implementation best practices.
Use logging to identify activity that indicates that a user is behaving maliciously. Potentially malicious activity to log includes:
When your application encounters such activity, your application should at the very least log the activity and mark it as a high severity issue. Ideally, your application should also respond to a possible identified attack, by for example invalidating the user\u2019s session and locking the user's account. The response mechanisms allows the software to react in realtime to possible identified attacks.
"},{"location":"archive/2018/c9-security-logging/#secure-logging-design","title":"Secure Logging Design","text":"Logging solutions must be built and managed in a secure way. Secure Logging design may include the following:
This document should be seen as a starting point rather than a comprehensive set of techniques and practices. We want to again emphasize that this document is intended to provide initial awareness around building secure software.
Good next steps to help build an application security program include:
If you have any questions for the project leadership team, please contact with your questions, comments, and ideas at our GitHub project repository.
"},{"location":"introduction/about-owasp/","title":"About OWASP","text":"The Open Worldwide Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications and APIs that can be trusted.
All OWASP tools, documents, videos, presentations, and chapters are free and open to anyone interested in improving application security.
We advocate approaching application security as a people, process, and technology problem, because the most effective approaches to application security require improvements in these areas.
OWASP is a new kind of organization. Our freedom from commercial pressures allows us to provide unbiased, practical, and cost-effective information about application security.
OWASP is not affiliated with any technology company, although we support the informed use of commercial security technology. OWASP produces many types of materials in a collaborative, transparent, and open way.
The OWASP Foundation is the non-profit entity that ensures the project's long-term success. Almost everyone associated with OWASP is a volunteer, including the OWASP board, chapter leaders, project leaders, and project members. We support innovative security research with grants and infrastructure.
"},{"location":"introduction/contributing/","title":"How to Contribute?","text":"Please don\u2019t hesitate to contact the OWASP Proactive Control project with your questions, comments, and ideas.
You can contact maintainers directly, use our project-top10-proactive-controls OWASP slack channel, or visit our github page.
You find the source code of the current version of the OWASP Top 10 Proactive Controls in the docs/ directory within the git repository. Please focus upon contributions for the current version, not archived versions within docs/archive.
When you check our open issues on github, you can see that some issues are tagged with help wanted or good first issue. Choose these if you want to help out the project!
If you can run python, you can locally run the OWASP Proactive Control website locally. We recommend this to test your changes before pushing them to github.
To do this, we will use venv to create a local python environment to install the needed mkdocs package.
# creates and activates a new python environment in a new `venv` directory\n$ python3 -m venv venv\n$ source venv/bin/activate\n\n# install the mkdocs package\n$ pip install mkdocs-material\n\n# switch into your checked-out OWASP Proactive Controls directory\n$ cd owasp-proactive-controls\n\n# run the local webserver\n$ mkdocs server\n\n# now you can point your browser to http://localhost:8000 and check\n# how your changes will look like\nOWASP is a volunteer-driven organization. Those volunteers contributed many useful documents, and this section points to some related OWASP documents and projects:
"},{"location":"introduction/related-owasp-projects/#owasp-top-10","title":"OWASP Top 10","text":"The best-known OWASP document is the OWASP Top 10. They detail the most common web application vulnerabilities and are also the base for this document. In contrast, this document is focused on defensive techniques and controls as opposed to risks. Each 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.
"},{"location":"introduction/related-owasp-projects/#owasp-asvs","title":"OWASP ASVS","text":"The OWASP Application Security Verification Standard (ASVS) is a catalog of available security requirements and verification criteria. OWASP ASVS can be a source of detailed security requirements for development teams. 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.
"},{"location":"introduction/related-owasp-projects/#owasp-samm","title":"OWASP SAMM","text":"Software Assurance Maturity Model (SAMM) is an open framework to help organizations implement a strategy for maturing the software security tailored to the specific risks of the organization. . SAMM supports the complete software life cycle and can be used to identify what
"},{"location":"introduction/related-owasp-projects/#threat-modeling-in-general","title":"Threat Modeling in General","text":"Threat Modeling is an important part of secure application development, which can help identify potential security threats, derive security requirements, and tailor security controls to prevent potential threats. Successful use of security requirements involves four steps: discovery, documentation, implementation, and verification of the correct implementation of the functionality within an application. Threat modelling is one way to derive security requirements. Other sources are: industry standards, applicable laws, history of past vulnerabilities. Modeling tools, like OWASP Threat Dragon can be used to create threat model diagrams as part of a secure development life cycle.
"},{"location":"introduction/related-owasp-projects/#domain-specific-documents","title":"Domain-Specific Documents","text":"It is important to notice that this document primarily focuses on web applications, but other Top 10s could apply to your application, too. Examples of those are:
Access Control (or Authorization) is allowing or denying specific requests from a user, program, or process. With each access control decision, a given subject requests access to a given object. Access control is the process that considers the defined policy and determines if a given subject is allowed to access a given object. Access control also involves the act of granting and revoking those privileges. Access Control often applies on multiple levels, e.g., given an application with a database backend, it applies both on the business logic level as well as on a database row level. In addition, applications can offer multiple ways of performing operations (e.g., through APIs or the website). All those different levels and access paths must be aligned, i.e., use the same access control checks, to protect against security vulnerabilities. Authorization (verifying access to specific features or resources) is not equivalent to authentication (verifying identity).
"},{"location":"the-top-10/c1-accesscontrol/#threats","title":"Threats","text":"Below is a minimum set of access control design requirements that should be considered at the initial stages of application development.
"},{"location":"the-top-10/c1-accesscontrol/#1-design-access-control-thoroughly-up-front","title":"1) Design Access Control Thoroughly Up Front","text":"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 design that must be thoroughly designed up front, especially when addressing requirements like multi-tenancy and horizontal (data dependent) access control.
Two core types of access control design should be considered.
Ensure that all access requests are forced to go through an access control verification layer. Technologies like Java filters or other automatic request processing mechanisms are ideal programming components that will ensure that all requests go through an access control check. This is referred to as Policy Enforcement Point in RFC 2904.
"},{"location":"the-top-10/c1-accesscontrol/#3-consolidate-the-access-control-check","title":"3) Consolidate the access control check","text":"Use a single access control procedure or routine. This prevents the scenario where you have multiple access control implementations, where most are correct, but some are flawed. By using a centralized approach, you can focus security resources on reviewing and fixing one central library or function that performs the access control check, and then reuse it throughout your code base and organization.
"},{"location":"the-top-10/c1-accesscontrol/#4-deny-by-default","title":"4) Deny by Default","text":"Ensure that by default, all the requests are denied, unless they are specifically allowed. This also includes accessing API (REST or webhooks) with missing access controls. There are many ways that this rule will manifest in the application code. Some examples are:
Application code may throw an error or exception while processing access control requests. In these cases, access control should always be denied.
When an administrator creates a new user or a user registers for a new account, that account should have minimal or no access by default until that access is configured.
When a new feature is added to an application, all users should be denied to use it until it\u2019s properly configured.
An example of implementing that principle is to create dedicated privileged roles and accounts for every organization function that requires highly privileged activities and avoid using an \u201cadmin\u201d role/account that is fully privileged daily.
To further improve the security, you can implement Just-in-Time (JIT) or Just-enough-Access (JEA): ensure that all users, programs, or processes are only given just enough access to achieve their current mission. This access should be provided just in time, when the subject makes the request, and the access should be granted for a short time. Be wary of systems that do not provide granular access control configuration capabilities.
"},{"location":"the-top-10/c1-accesscontrol/#6-do-not-hard-code-roles","title":"6) Do not Hard-code Roles","text":"Many application frameworks default to access control that is role based. It is common to find application code filled with checks of this nature.
if (user.hasRole(\"ADMIN\")) || (user.hasRole(\"MANAGER\")) {\n deleteAccount();\n}\nBe careful about this type of role-based programming in code. It has the following limitations or dangers:
Please consider the following access control enforcement points using this following programming methodology:
if (user.hasPermission(\"DELETE_ACCOUNT\")) {\n deleteAccount();\n}\nAttribute or feature-based access control checks of this nature are the starting point to building well-designed and feature-rich access control systems. This type of programming also allows for greater access control customization capability over time.
"},{"location":"the-top-10/c1-accesscontrol/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"While Injection Attacks typically target the victim server itself, Server-Side Request Forgery (SSRF) attacks try to coerce the server to perform a request on behalf of the attacker. Why is this beneficial for the attacker? The outgoing request will be performed with the identity of the victim server and thus the attacker might execute operations with elevated operations.
"},{"location":"the-top-10/c10-stop-server-side-request-forgery/#threats","title":"Threats","text":"Examples of this contain:
There multiple ways of preventing SSRF:
Sensitive data such as passwords, credit card numbers, health records, personal information and business secrets require extra protection, particularly if that data falls under privacy laws (EU's General Data Protection Regulation GDPR), financial data protection rules such as PCI Data Security Standard (PCI DSS) or other regulations.
Attackers can steal data from web and web service applications in a number of ways. For example, if sensitive information is sent over the internet without communications security, then an attacker on a shared wireless connection could capture and steal another user\u2019s data. Also, an attacker could use SQL Injection to steal passwords and other credentials from an applications database and expose that information to the public.
Privacy is assurance that the confidentiality of, and access to, certain information about an entity is protected. Users of the things developers build want their information protected from disclosure.
Protect sensitive data such as passwords, credit card numbers, health records, personal information, and business secrets.
Regulations exist to force companies to protect user\u2019s personal information. The European Union values individual privacy, such that they created the EU General Data Protection Regulation GDPR. Financial data protection rules such as PCI Data Security Standard (PCI DSS) also exist to protect cardholder privacy.
Cryptography is the art or science concerning the principles, means, and methods for rendering plain information unintelligible and restoring encrypted information to intelligible form. Individual user data requires cryptography to ensure it is properly cared for when stored.
"},{"location":"the-top-10/c2-crypto/#classify-data-types-in-your-application","title":"Classify data types in your application","text":"It\u2019s critical to classify data in your system and determine which level of sensitivity each piece of data belongs to. Each data category can then be mapped to protection rules necessary for each level of sensitivity. For example, public marketing information that is not sensitive may be categorized as public data which is okay to place on the public website. Credit card numbers may be classified as private user data which will need to be encrypted while stored, processed or in transit.
Data classification can also be mandated by legislation, e.g., GDPR when serving users within the European Union.
Classify the data sent, processed, and stored in your system and determine what level of sensitivity the data belongs to. Categorize the data to define specific protection rules for each type. The rule creation enables your team to perform data minimization and try not to store sensitive data whenever possible.
For example, public marketing information that is not sensitive may be categorized as public data, which is okay to place on the public website and does not need to be encrypted. Credit card numbers need to be encrypted while stored, processed, and in transit.
"},{"location":"the-top-10/c2-crypto/#threats","title":"Threats","text":"When it comes to cryptography, there are a few simple rules:
The first rule of sensitive data management is to avoid storing sensitive data when at all possible. If you must store sensitive data then make sure it is cryptographically protected in some way to avoid unauthorized disclosure and modification. Cryptography (or crypto) is one of the more advanced topics of information security and one whose understanding requires the most schooling and experience. It is difficult to get right because there are many approaches to encryption, each with advantages and disadvantages that need to be thoroughly understood by web solution architects and developers. In addition, serious cryptography research is typically based on advanced mathematics and number theory, providing a serious barrier to entry. Designing or building cryptographic algorithms is very error-prone (see side-channel attacks). Instead of building cryptographic capability from scratch, it is strongly recommended that peer-reviewed and open solutions be used, such as the Google Tink project, Libsodium, and secure storage capability built into many software frameworks and cloud services.
Most web applications will face the challenge of storing user\u2019s passwords to set up authentication services. Store the passwords safely to ensure an attacker cannot quickly obtain them. Do not store the passwords in plain text anywhere in the database. Always use a hashing function to store passwords. Enhance the hashing function by adding a random salt for each item to increase the randomness of hashes.
"},{"location":"the-top-10/c2-crypto/#special-case-application-secrets-management","title":"Special Case: Application Secrets management","text":"Applications contain numerous \u201csecrets\u201d that are needed for security operations. These include certificates, SQL connection passwords, third party service account credentials, passwords, SSH keys, encryption keys and more. The unauthorized disclosure or modification of these secrets could lead to complete system compromise. In managing application secrets, consider the following: Don\u2019t store secrets in code, config files or pass them through environment variables. Use tools like GitRob or TruffleHog to scan code repositories for secrets. Your code should be written in a way that even if your code would be disclosed, e.g., due to a defective configured github repository, your running applications are still secure. Keep keys and your other application-level secrets in a secrets vault like KeyWhiz or Hashicorp's Vault project , Amazon KMS, or AWS Secrets Manager to provide secure storage and access to application-level secrets at run-time. Many web-frameworks such as Ruby on Rails provide integrated ways of dealing with secrets and credentials.
"},{"location":"the-top-10/c2-crypto/#key-life-cycle","title":"Key Life Cycle","text":"Secret keys are used in applications with a number of sensitive functions. For example, secret keys can be used to sign JWTs, protect credit cards, provide various forms of authentication as well as facilitate other sensitive security features. In managing keys, a number of rules should be followed including
Sensitive data such as passwords, credit card numbers, health records, personal information and business secrets require extra protection, particularly if that data falls under privacy laws (EU's General Data Protection Regulation GDPR), financial data protection rules such as PCI Data Security Standard (PCI DSS) or other regulations. Attackers can steal data from web and web service applications in a number of ways. For example, if sensitive information is sent over the internet without communications security, then an attacker on a shared wireless connection could capture and steal another user\u2019s data. Also, an attacker could use SQL Injection to steal passwords and other credentials from an applications database and expose that information to the public.
"},{"location":"the-top-10/c2-crypto/#use-current-cryptographic-protocols","title":"Use current cryptographic protocols","text":"When developing web applications, use TLSv1.2 or TLSv1.3, preferably TLSv1.3. If possible, investigate the usage of HTTP/2 or HTTP/3 as they warrant the usage of security TLS versions/algorithms.
Web servers can instruct web browsers to uphold minimal transport-level security:
Cryptographic recommendations change over time. To allow for this, make cryptographic choices such as used algorithms or key sizes configurable. This is called Cryptographic Agility
If the application needs to support high availability, design key-rollover procedures.
"},{"location":"the-top-10/c2-crypto/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"Input validation is a programming technique that ensures only properly formatted data may enter a software system component. When the injection attack targets a client (for example JavaScript based attacks), web servers can perform quoting/encoding on the attacker-provided data before forwarding it to the client.
Injection attacks commonly occur if an application confuses data input as executable commands and are often possible where input validation is forgotten or implemented wrong. For example, imagine that a web application accepts an email address as input from a user. The email address would be the expected \u201cdata\u201d. Attackers now search for ways to confuse applications to execute this (supposed) data as commands. Different injection attacks target different areas:
An application should check that data is syntactically and semantically valid (in that order) before using it in any way (including displaying it back to the user).
Syntactic validity means that the data is in the expected form. For example, an application may allow users to select a four-digit \u201caccount ID\u201d to perform some operation. The application should assume the user is entering a SQL injection payload and check that the data entered by the user is precisely four digits in length and consists only of numbers (in addition to utilizing proper query parametrization).
Semantic validity includes only accepting input within an acceptable range for application functionality and context. For example, a start date must be before an end date when choosing date ranges.
Protection against Injection Attacks is typically based upon a defense-in-depth approach and incorporates input filtering, output escaping, and utilization of hardening mechanisms. The former two are only dependent upon implemented security measures, and the latter is mostly dependent upon client-support, e.g., when protecting against XSS, filtering XSS from input and escaping output data server-side would prevent XSS regardless of the used web browser; adding a Content-Security-Policy prevents XSS, but only if the user\u2019s browser supports it. Due to this, security must never depend upon optional hardening measures alone.
"},{"location":"the-top-10/c3-validate-input-and-handle-exceptions/#prevent-malicious-data-from-entering-the-system","title":"Prevent malicious data from entering the system","text":"Never trust provided data! Screen all data for malicious patterns or, even better, check all data against an allow list.
"},{"location":"the-top-10/c3-validate-input-and-handle-exceptions/#allowlisting-vs-denylisting","title":"Allowlisting vs Denylisting","text":"There are two general approaches to performing syntactic validation, commonly known as allow and deny lists:
Always perform Input validation on the server side for security. While client-side validation is useful for both functional and security purposes, it is easily bypassed. Therefore, client-side validation is performed for usability purposes, but the application\u2019s security must not depend upon it. For example, JavaScript validation may alert the user that a particular field must consist of numbers. Still, the server-side application must validate that the submitted data only consists of numbers in the appropriate numerical range for that feature. Another benefit of using both client AND server-side validation is that any server-side validation warnings can be logged to inform operations of a potential hacker as the client-side validation had been bypassed.
"},{"location":"the-top-10/c3-validate-input-and-handle-exceptions/#regular-expressions","title":"Regular Expressions","text":"Regular expressions offer a way to check whether data matches a specific pattern. Let\u2019s start with a basic example. The following regular expression defines an allowlist rule to validate usernames.
^\\[a-z0-9_\\]{3,16}$\nThis regular expression allows only lowercase letters, numbers, and the underscore character. The username is also restricted to a length of 3 and 16 characters.
Caution: Potential for Denial of Service
Care should be exercised when creating regular expressions. Poorly designed expressions may result in potential denial of service conditions (aka ReDoS ). Various tools can be tested to verify that regular expressions are not vulnerable to ReDoS.
Caution: Complexity
Regular expressions are just one way to accomplish validation. Regular expressions can be difficult to maintain or understand for some developers. Other validation alternatives involve writing validation methods programmatically, which can be easier to maintain for some developers.
"},{"location":"the-top-10/c3-validate-input-and-handle-exceptions/#unexpected-user-input-mass-assignment","title":"Unexpected User Input (Mass Assignment)","text":"Some frameworks support automatic binding of HTTP requests parameters to server-side objects used by the application. This auto-binding feature can allow an attacker to update server-side objects that were not meant to be modified. The attacker can possibly modify their access control level or circumvent the intended business logic of the application with this feature. This attack has a number of names including: mass assignment, autobinding and object injection. As a simple example, if the user object has a field privilege which specifies the user\u2019s privilege level in the application, a malicious user can look for pages where user data is modified and add privilege=admin to the HTTP parameters sent. If auto-binding is enabled in an insecure fashion, the server-side object representing the user will be modified accordingly.
Two approaches can be used to handle this:
More examples are available in the OWASP Mass Assignment Cheat Sheet
"},{"location":"the-top-10/c3-validate-input-and-handle-exceptions/#limits-of-input-validation","title":"Limits of Input Validation","text":"Input validation does not always make data \u201csafe\u201d since certain complex input forms may be \u201cvalid\u201d but still dangerous. For example, a valid email address may contain a SQL injection attack, or a valid URL may contain a Cross Site Scripting attack. Additional defenses besides input validation should always be applied to data, such as query parametrization or escaping.
"},{"location":"the-top-10/c3-validate-input-and-handle-exceptions/#use-mechanisms-that-uphold-the-separation-of-data-and-commands","title":"Use mechanisms that uphold the separation of data and commands","text":"Even if malicious data has passed the input checking, applications can prevent injection attacks by never executing those malicious data as commands/code. Multiple measures can achieve this goal, most of them are technology-dependent. For Example:
A special case are JavaScript based Injection attacks (XSS). The injected malicious code is commonly executed within a victim\u2019s browser. Typically, attackers try to steal the user\u2019s session information from the browser and not directly execute commands (as they do on the server-side). In addition to server-side input filtering and output escaping, multiple client-side hardening measurements can be taken (these also protect against the special case of DOM-based XSS where no server-side logic is involved and thus cannot filter malicious code):
Consider an application that needs to accept HTML from users (via a WYSIWYG editor that represents content as HTML or features that directly accept HTML in input). In this situation, validation or escaping will not help.
Therefore, you need a library to parse and clean HTML formatted text. Please see the XSS Prevention Cheat Sheet on HTML Sanitization for more information on HTML Sanitization.
"},{"location":"the-top-10/c3-validate-input-and-handle-exceptions/#special-case-validate-data-during-deserialization","title":"Special Case: Validate Data During Deserialization","text":"Some forms of input are so complex that validation can only minimally protect the application. For example, it\u2019s dangerous to deserialize untrusted data or data that can be manipulated by an attacker. The only safe architectural pattern is to not accept serialized objects from untrusted sources or to only deserialize in limited capacity for only simple data types. You should avoid processing serialized data formats and use easier to defend formats such as JSON when possible.
If that is not possible then consider a series of validation defenses when processing serialized data.
Regarding Input Validation:
Helping with Input Validation:
Testing for Injection Attacks:
Helping with Hardening:
When designing a new application, creating a secure architecture prevents vulnerabilities before they even become part of the application. This prevents costly repairs and repudiation problems.
There are design principles that lead to secure architectures:
While it might be possible to implement all requirements manually, it is highly recommended to base one's architecture upon established and well-maintained third-party components. This has multiple benefits:
phpmyadmin) is deployed. After a 0day was found in mysqladmin, the whole database was extracted. During normal use, nobody uses phpmyadmin.The mantra \"Complexity is the enemy of security\" can be seen throughout this implementation guidance.
"},{"location":"the-top-10/c4-secure-architecture/#design-for-clarity-and-transparency","title":"Design for Clarity and Transparency","text":"Architecture should focus upon simplicity: the designed software should be only as complex as the intended user's requirements warrant. Focusing upon simplicity brings multiple benefits for the created software:
Two terms often heard are \"security by design\" and \"security by default\". The former implies, that the software system should be usable in a secure manner while the latter means that the initial configuration of the software system is secure.
This implies, that an system administrator has to make an explicit choice to introduce insecure configuration into the system. In contrast, the path of least resistance should always result in a secure system.
When focusing upon end-user interactions, this aspect is important for designing user interfaces and flows. When focusing upon developer interactions, developer-facing facilities such as framework, APIs, network APIs should be designed that when using them with default values, only secure operations should occur. Think about this when designing your configuration files too
"},{"location":"the-top-10/c4-secure-architecture/#clearly-articulate-whats-trusted-to-do-what-and-ensure-those-relationships-are-enforced","title":"Clearly articulate what's trusted to do what, and ensure those relationships are enforced","text":"Clearly articulate what's trusted to do what, and ensure those relationships are enforced, e.g., trust boundaries delineate blast radius and are enforced by controls, such as firewalls or gateways.
Attenuate what's allowed by careful validation at each step. Go deeper with threat modeling mnemonics like stride or methodologies like stride per element.
"},{"location":"the-top-10/c4-secure-architecture/#identify-and-minimize-your-exposed-components-attack-surface","title":"Identify and minimize your exposed components (\"attack surface\")","text":"Identify all areas that an attacker can access, review them and try to minimize them: attackers cannot attack what's not there.
In addition, exposing only a minimal set of operations makes long-term maintenance easier.
"},{"location":"the-top-10/c4-secure-architecture/#use-well-known-architecture-patterns","title":"Use well-known Architecture Patterns","text":"Experts have shared their wisdom about best practices in an easily digestible format called secure architecture patterns. Architecture patterns are reusable and can be applied across multiple applications.
For a solution to be considered a pattern, it must have these characteristics:
An architecture pattern is a way to solve a problem using a standard solution versus creating a custom solution. A secure architecture pattern is a standard solution that has been reviewed and hardened against known security threats.
Implementation:
\u201cSecure-by-Default\u201d means products are resilient against prevalent exploitation techniques out of the box without additional charge. The benefit of having an application secure from the start is that it removes the burden away from developers on how to lock a system down, providing them with an already secure product. It reduces the effort required to deploy products in a secure manner and gives greater confidence that they will remain secure over time.
"},{"location":"the-top-10/c5-secure-by-default/#threats","title":"Threats","text":"In modern cloud applications, when developers build applications, they are also building the infrastructure for their applications, making infrastructure decisions, including security-critical configurations, while writing their code. These are deployed on infrastructure created and configured via code, Infrastructure-as-code (IaC), using configurations applied at the application level ( including web server and database), at container, Function as a Service, or infrastructure level. For example, in the case of web applications, folder permissions need to follow the principle of least privilege to limit resource access rights. When web and mobile applications are deployed in production, the debugging should be disabled.
Is it important that when developers put together their infrastructure components, they:
As part of software development, a developer needs to ensure that software is configured securely by default at the application level. For example,
It is a common practice in software development to leverage libraries and frameworks. Secure libraries and software frameworks with embedded security help software developers prevent 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 (both open source and vendor) help accomplish security goals more efficiently and accurately.
When possible, the emphasis should be on using the existing secure features of frameworks rather than importing yet another third party libraries, which requires regular updates and maintenance. It is preferable to have developers take advantage of what they're already using instead of forcing yet another library on them.
When incorporating third party libraries or frameworks into your software, it is important to consider the following two categories of best practices:
Below each of these categories are further detailed to help secure your software.
"},{"location":"the-top-10/c6-use-secure-dependencies/#best-practices-to-identify-trusted-libraries","title":"Best Practices to Identify Trusted libraries","text":"Below are listed a few criteria you can use to select the next library or framework for your software. This is not an exhaustive list, but is a good start.
Sources: Download recommended security libraries from official sources over secure links and prefer signed packages to reduce the chance of including a modified, malicious component (See A08:2021-Software and Data Integrity Failures).
Popularity: Leverage libraries and frameworks used by many applications which have around large communities. Consider data points such as the number of GitHub stars a package\u2019s source code repository has received, and number of downloads from within a package manager.
Activity: Ensure that the library/ framework is actively maintained and issues are resolved in a timely fashion.
Maturity: Use stable versions . Projects in early stages of development area higher risk to your software .
Complexity: A large, complex library with lots of dependencies, is more difficult to incorporate into your software. Also, a high number of dependencies indicates a higher number of future upgrades to ensure all those dependencies are up-to-date and secured.
Security: If the package is open source, you can use static application security testing (SAST) or Software Composition Analysis (SCA) to help identify malicious code or security weaknesses, before first including them.
New security vulnerabilities are disclosed every day and are published in public databases like the NIST National Vulnerability Database (NVD) which identifies publicly known vulnerabilities using Common Vulnerabilities and Exposures (CVE). Furthermore, exploits made available in public databases allow attackers to automate their attacks. As a result of this, it is important to ensure on a regular basis that your software is free of well-known security vulnerabilities.
Maintain an inventory catalog of all the third party components. It is recommended to automatically create SBOMs (Software-Bill-Of-Materials) from within the build pipeline. A SBOM contains all used third-party dependencies and their versions and can be automatically monitored by a variety of supply chain management tools.
Perform continuous checks. Use your SBOMs together with periodic or continuous monitoring tools such as OWASP dependency-track to automatically detect well-known publicly disclosed vulnerabilities.
Verify for security early and often - integrate SCA tools in early stages of software development, to gain visibility in the number and criticality of security vulnerabilities of the software and its dependencies from every stage of the software development life cycle.
Proactively update libraries and components. Updating software must be a recurring task that occurs throughout the life cycle of the application or product, from ideation to retirement.
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 using vulnerable and outdated components with known vulnerabilities Top 10 2021.
"},{"location":"the-top-10/c6-use-secure-dependencies/#references","title":"References","text":"Digital Identity is a unique representation of an individual, organization (or another subject) as they engage in an online transaction. Authentication is the process of verifying that an individual or entity is who they claim to be.
Session management is the process by which a server maintains the state of the user\u2019s authentication so that the user may continue to use the system without re-authenticating. Digital identity, authentication, and session management are very complex topics. We're scratching the surface of the topic of Digital Identity here. Ensure that your most capable engineering talent is responsible for maintaining the complexity involved with most Identity solutions. The NIST Special Publication 800-63B: Digital Identity Guidelines (Authentication and Life Cycle Management provide solid guidance on implementing digital identity, authentication, and session management controls. Below are some recommendations for secure implementation to ensure strong digital identity controls are implemented in applications.
"},{"location":"the-top-10/c7-implement-digital-identity/#authentication-assurance-levels","title":"Authentication Assurance Levels","text":"NIST 800-63b describes three levels of authentication assurance called Authentication Assurance Level (AAL):
NIST 800-63b AAL level 2 is reserved for higher-risk applications that contain \"self-asserted PII or other personal information made available online.\" At AAL level 2 multi-factor authentication is required including OTP or other forms of multi-factor implementation. Multi-factor authentication (MFA) ensures that users are who they claim to be by requiring them to identify themselves with a combination of:
NIST 800-63b Authentication Assurance Level 3 (AAL3) is required when the impact of compromised systems could lead to personal harm, significant financial loss, harm the public interest or involve civil or criminal violations. AAL3 requires authentication that is \"based on proof of possession of a key through a cryptographic protocol.\" This type of authentication is used to achieve the strongest level of authentication assurance. This is typically done through hardware cryptographic modules. When developing web applications, this will commonly lead to WebAuthn or PassKeys.
"},{"location":"the-top-10/c7-implement-digital-identity/#session-management-client-vs-server-side-sessions","title":"Session Management: client- vs server-side sessions","text":"HTTP on its own is a session-less protocol: no data is shared between requests. When you look at how we are using the web, this is clearly not what is user-visible as for example you log into a website and stay logged in during subsequent requests. This is possible as session-management has been implemented on top of HTTP. Once the initial successful user authentication has taken place, an application may choose to track and maintain this authentication state for a limited amount of time. This will allow the user to continue using the application without having to keep re-authentication with each request. Tracking of this user state is called Session Management. Session-Management can be roughly categorized in client- and server-side session management. In the former, all session data is stored within the client and transmitted on each request to the server. The latter stores session-specific data on the server, e.g., in a database, and only transmits an identifier to the client. The client then submits only the session-identifier on each request and the server retrieves the session-data from the server-side storage.
From a security-perspective server-side sessions have multiple benefits:
Passwords should comply with the following requirements at the very least:
It is common for an application to have a mechanism for a user to gain access to their account in the event they forget their password. A good design workflow for a password recovery feature will use multi-factor authentication elements. For example, it may ask a security question - something they know, and then send a generated token to a device - something they own. Please see the Forgot_Password_Cheat_Sheet and Choosing_and_Using_Security_Questions_Cheat_Sheet for further details.
"},{"location":"the-top-10/c7-implement-digital-identity/#implement-secure-password-storage","title":"Implement Secure Password Storage","text":"In order to provide strong authentication controls, an application must securely store user credentials. Furthermore, cryptographic controls should be in place such that if a credential (e.g., a password) is compromised, the attacker does not immediately have access to this information. Please see the OWASP Password Storage Cheat Sheet for further details.
"},{"location":"the-top-10/c7-implement-digital-identity/#server-side-session-management","title":"Server-Side Session-Management","text":"Typically server-side session management is implemented with HTTP cookies which are used to store a session-identifier. When a new session is requested, the server generates a new session-identifier and transmits it to the client (browser). On each subsequent request, the session-identifier is transmitted from the client to the server, and the server uses this session-identifier to lookup session-data within a server-side database.
"},{"location":"the-top-10/c7-implement-digital-identity/#session-generation-and-expiration","title":"Session Generation and Expiration","text":"User state is tracked in a session. This session is typically stored on the server for traditional web based session management. A session identifier is then given to the user so the user can identify which server-side session contains the correct user data. The client only needs to maintain this session identifier, which also keeps sensitive server-side session data off of the client. Here are a few controls to consider when building or implementing session management solutions:
Please see the Session Management Cheat Sheet further details. ASVS Section 3 covers additional session management requirements.
"},{"location":"the-top-10/c7-implement-digital-identity/#client-side-session-management","title":"Client-Side Session-Management","text":"Server-side sessions can be limiting for some forms of authentication. \"Stateless services\" allow for client side management of session data for performance purposes so the server has less of a burden to store user sessions. These \"stateless\" applications typically generate a short-lived access token containing all of the current user\u2019s access permissions which is then included in all subsequent requests. Cryptography must be employed so that the client cannot alter the permissions stored within the token. When a client requests a server operation, the client includes the retrieved access token and the server verifies that the token has not been tampered with and extracts the permissions from the token. These permissions are then used for subsequent permission checks.
"},{"location":"the-top-10/c7-implement-digital-identity/#jwt-json-web-tokens","title":"JWT (JSON Web Tokens)","text":"JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted as long as it is digitally signed by a trusted authority. A JWT token is created during authentication and is verified by the server (or servers) before any processing. However, JWTs are often not saved by the server after initial creation. JWTs are typically created and then handed to a client without being saved by the server in any way. The integrity of the token is maintained through the use of digital signatures so a server can later verify that the JWT is still valid and was not tampered with since its creation. This approach is both stateless and portable in the way that client and server technologies can be different yet still interact. Please note, that if you are using JWTs you have to make sure that the returned JWT is actually using one of the signing algorithms that you are using. Otherwise, an attacker could try to create a JWT signed with the NULL algorithm, use a MAC-vs-Signature confusion attack, or provide a custom JWS key for signing. When you are issuing JWTs, make double-sure that you are using a secure private key for signing the JWTs: each output JWT gives an attacker all information needed to perform an offline cracking attack, so you should rotate keys frequently too.
"},{"location":"the-top-10/c7-implement-digital-identity/#browser-cookies","title":"Browser Cookies","text":"Browser cookies are a common method for web applications to store session identifiers for web applications implementing standard session management techniques. Here are some defenses to consider when using browser cookies.
Browsers are the gateway to the web for most users. As such, it's critical to employ robust security measures to protect the user from various threats. This section outlines the techniques and policies that can be implemented to bolster browser security.
While we are currently focusing upon traditional web browsers, please note that there is a diverse world of other client programs out there, ranging from mobile apps, API clients to smart-TVs. We encourage to verify what client-side security features are supported by your client and use the respective HTTP headers to configure them.
"},{"location":"the-top-10/c8-leverage-browser-security-features/#opportunistic-security-and-browser-support","title":"Opportunistic Security and Browser-Support","text":"Instructing the web browser to enforce security measures is always opportunistic: the web application cannot verify that the browser heeds the guidance given and thus these security measures should always be seen as additional (and optional) Hardening Measures that further complicate an attacker\u2019s life.
In addition, web browsers must actually support the security guidance offered by web applications. The level of support differs between different browsers and their versions. Web sites such as https://caniuse.com can be used to check which web browser (versions) support which features. The supported security features can change over time, e.g., the X-XSS-Protection header has been removed from all major browsers; the browsers\u2019 default behavior can change over time as seen with Referrer-Policy; and even the semantics of existing headers can change over time as seen with X-Content-Type-Options.
While the changing browser feature set can be problematic, typically newer browser provide more security features. They sometimes even enable them by default. Explicitly setting those security headers can unify the different browsers\u2019 behaviors and thus reduces maintenance effort.
A fully compromised browser might not heed security guidance but if an adversary was able to take full control of a browser, they already have far more damaging attack paths than just ignoring security guidance.
"},{"location":"the-top-10/c8-leverage-browser-security-features/#threats","title":"Threats","text":"Referer HTTP headers when proper Referrer-Policy is not set, potentially exposing private data or user activities.Typically, there are two (Security Header specific) ways that web applications can use to instruct web browsers about security: HTTP headers and HTML tags.
The behavior taken if a security directive is given more than one time is security header specific. For example, a duplicate X-Frame-Options header will disable its protection while a duplicate Content-Security-Policy header will lead to a stricter policy thus tightening its security. The following is a non-exhaustive list of potential Hardening mechanisms:
"},{"location":"the-top-10/c8-leverage-browser-security-features/#configure-the-browser-to-prevent-information-disclosure","title":"Configure the Browser to prevent Information Disclosure","text":"Information disclosure occurs if the browser transmits information over unencrypted channels (HTTP instead of HTTPS) or sends our too much information in the first place (e.g., through the Referer-Header). The following mechanisms reduce the possibility of information disclosure:
JavaScript based XSS attacks have been very common for decades. To reduce the potential impact of vulnerabilities, browsers offer rich defensive mechanisms that should reduce the potential impact of XSS attacks:
Clickjacking, also known as UI-redress attacks, try to confuse users by overlaying a malicious site on top of a benign one. The user believes to interact with the benign one while in reality they are interacting with the malicious one.
Modern browsers do not only display HTML code but are used to interface with multiple system components such as WebCams, Microphones, USB Devices, etc. While many websites do not utilize those features, attackers can abuse those.
CSRF attacks abuse an existing trust relationship between the web browser and web sites.
Implementing these browser defenses can help mitigate a range of vulnerabilities, including but not limited to:
Logging is a concept that most developers already use for debugging and diagnostic purposes. Security logging is an equally basic concept: to log security information during the runtime operation of an application. Monitoring is the live review of application and security logs using various forms of automation. The same tools and patterns can be used for operations, debugging and security purposes.
"},{"location":"the-top-10/c9-security-logging-and-monitoring/#benefits-of-security-logging","title":"Benefits of Security Logging","text":"Security logging can be used for:
Use logging to identify activity that indicates that a user is behaving maliciously. Potentially malicious activity to log includes:
Logging solutions must be built and managed in a secure way. Secure Logging design may include the following:
The following is a list of security logging implementation best practices.
For years, developers have suffered through introducing the same security issues into the things they build. The most common issues, which have existed for decades, have been documented by the OWASP Top Ten. Many of the issues in the earliest version still exist in some form today. A mechanism is needed to counter these challenges, and that mechanism is proactive controls.
Proactive controls are a catalog of better practices, a set of items developers can embrace and implement in their code bases to avoid many common security issues. Proactive controls provide positive patterns to implement solutions considered secure by design.
Imagine working on a web-based software, releasing a new version, and then getting reports that it contained a security vulnerability that is now being exploited in the wild. You are now forced to act reactively: analyzing the vulnerability, fixing it, creating a new software release, and getting it to your users. All this is tedious and a bit awkward, esp. When the security vulnerability was critical.
Proactive controls prevent this by focusing on the development itself. Their idea is to prevent common vulnerabilities during an application's inception so that those tedious and embarrassing bug fixes can be avoided altogether. Common knowledge is that a proactive approach will save resources and money in the long run.
The OWASP Top 10 Proactive Controls 2024 is a list of security techniques every software architect and developer should know and heed. The main goal 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.
Please note that while complying with best proactive practices will reduce the chance of a vulnerability being in your code, there is no guarantee that code is security-bug free. And that\u2019s okay: You have to break an egg to make an omelet \u2014 the only way of not introducing any security bugs is not to code at all. We accept that while striving to prevent as many security issues as possible.
"},{"location":"the-top-10/introduction/#how-this-list-was-created","title":"How this List Was Created","text":"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.
"},{"location":"the-top-10/introduction/#security-controls","title":"Security Controls","text":"The description of each control has the same structure. The control itself has an unique name preceded by the control number: Cx: Control Name, e.g., C1: Implement Access Control.
Each control has the same sections:
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.
"},{"location":"#aim-objective","title":"Aim & Objective","text":"The goal of the OWASP Top 10 Proactive Controls project 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.
"},{"location":"#target-audience","title":"Target Audience","text":"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.
"},{"location":"#how-to-use-this-document","title":"How to Use this Document","text":"This document\u2019s main purpose is to provide a solid foundation of topics to help drive introductory software security developer training. To be effective, these controls should be used consistently and thoroughly throughout all applications.
However, this document is a starting point rather than a comprehensive set of techniques and practices.
A fully 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 and BSIMM.
"},{"location":"#project-leaders","title":"Project Leaders","text":"This document is released under the Creative Commons Attribution-ShareAlike 4.0 International license. For any reuse or distribution, you must make it clear to others the license terms of this work.
"},{"location":"final-word/","title":"Final word","text":"This document should be seen as a starting point rather than a comprehensive set of techniques and practices. We want to again emphasize that this document is intended to provide initial awareness around building secure software.
Good next steps to help build an application security program include:
This document would not have been possible without our contributors for which we are grateful.
From the shared 2024 document and according to github:
Introduction of the OWASP Top 10 Proactive Controls v4 and switch to new wiki system.
gbhackers. post OWASP Top 10 Proactive Security Controls For Software Developers to Build Secure SoftwareThe OWASP Top 10 Proactive Controls 2018 (v3) were released.
The OWASP Top 10 Proactive Controls 2016 (v2) were released on Jan 14, 2016.
Starting with version v4 in 2024, we don't accept inclusion of translations into the OWASP Top 10 Proactive Controls directly and are only providing the English version.
We do encourage translators to create translated versions and host them themselves and will link to those external sites/documents if notified about them.
"},{"location":"about-top-10/old-versions-and-translations/#owasp-top-10-proactive-controls-2018-v3","title":"OWASP Top 10 Proactive Controls 2018 (v3)","text":"You can find the OWASP Top 10 Proactive Controls 2018 on GitHub:
We also provide a Mapping to the OWASP Top 10 and IEEE Top 10.
"},{"location":"about-top-10/old-versions-and-translations/#owasp-top-10-proactive-controls-2016-v2","title":"OWASP Top 10 Proactive Controls 2016 (v2)","text":"You can find the OWASP Top 10 Proactive Controls 2016 (v2) on GitHub:
They might be somewhere..
"},{"location":"archive/2014/","title":"OWASP Top 10 Proactive Controls v1/2014","text":"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.
OWASP is a new kind of organization. Our freedom from commercial pressures allows us to provide unbiased, practical, cost effective information about application security.
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.
"},{"location":"archive/2018/0x02-about-project/","title":"About this Project","text":"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.
"},{"location":"archive/2018/0x02-about-project/#aim-objective","title":"Aim & Objective","text":"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.
"},{"location":"archive/2018/0x02-about-project/#call-to-action","title":"Call to Action","text":"Please don\u2019t 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.
"},{"location":"archive/2018/0x02-about-project/#copyright-and-licence","title":"Copyright and Licence","text":"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.
"},{"location":"archive/2018/0x02-about-project/#project-leaders","title":"Project Leaders","text":"This document is structured as a list of security controls. Each control is described as follows:
"},{"location":"archive/2018/0x03-about-structure/#cx-control-name","title":"Cx: Control Name","text":""},{"location":"archive/2018/0x03-about-structure/#description","title":"Description","text":"A detailed description of the control including some best practices to consider.
"},{"location":"archive/2018/0x03-about-structure/#implementation","title":"Implementation","text":"Implementation best practices and examples to illustrate how to implement each control.
"},{"location":"archive/2018/0x03-about-structure/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"List of prevented vulnerabilities or risks addressed (OWASP TOP 10 Risk, CWE, etc.)
"},{"location":"archive/2018/0x03-about-structure/#references","title":"References","text":"List of references for further study (OWASP Cheat sheet, Security Hardening Guidelines, etc.)
"},{"location":"archive/2018/0x03-about-structure/#tools","title":"Tools","text":"Set of tools/projects to easily introduce/integrate security controls into your software.
"},{"location":"archive/2018/0x04-introduction/","title":"Introduction","text":"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.
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.
"},{"location":"archive/2018/0x04-introduction/#the-top-10-proactive-controls","title":"The Top 10 Proactive Controls","text":"The list is ordered by importance with list item number 1 being the most important:
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.
"},{"location":"archive/2018/0x04-introduction/#target-audience","title":"Target Audience","text":"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.
"},{"location":"archive/2018/0x04-introduction/#how-to-use-this-document","title":"How to Use this Document","text":"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 and BSIMM.
"},{"location":"archive/2018/0x04-introduction/#link-to-the-owasp-top-10-project","title":"Link to the OWASP Top 10 Project","text":"The OWASP Top 10 Proactive Controls is similar to the OWASP Top 10 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.
"},{"location":"archive/2018/c1-security-requirements/","title":"C1: Define Security Requirements","text":""},{"location":"archive/2018/c1-security-requirements/#description","title":"Description","text":"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.
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.
"},{"location":"archive/2018/c1-security-requirements/#the-owasp-asvs","title":"The OWASP ASVS","text":"The OWASP Application Security Verification Standard (ASVS) is a catalog of available security requirements and verification criteria. OWASP ASVS can be a source of detailed security requirements for development teams.
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.
"},{"location":"archive/2018/c1-security-requirements/#augmenting-requirements-with-user-stories-and-misuse-cases","title":"Augmenting Requirements with User Stories and Misuse Cases","text":"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.
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.
2.19 Verify there are no default passwords in use for the application framework \n or any components used by the application (such as \"admin/password\").\nThis 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.
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\".
As a user, I can enter my username and password to gain access to the application.\nAs a user, I can enter a long password that has a maximum of 1023 characters.\nWhen the story is focused on the attacker and their actions, it is referred to as a misuse case.
As an attacker, I can enter in a default username and password to gain access.\nThis story contains the same message as the traditional requirement from ASVS, with additional user or attacker details to help make the\u00a0requirement more testable.
"},{"location":"archive/2018/c1-security-requirements/#implementation","title":"Implementation","text":"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.
"},{"location":"archive/2018/c1-security-requirements/#discovery-and-selection","title":"Discovery and Selection","text":"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.
"},{"location":"archive/2018/c1-security-requirements/#investigation-and-documentation","title":"Investigation and Documentation","text":"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.
"},{"location":"archive/2018/c1-security-requirements/#implementation-phase","title":"Implementation Phase","text":"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.
"},{"location":"archive/2018/c1-security-requirements/#test","title":"Test","text":"Test cases should be created to confirm the existence of the new functionality or disprove the existence of a previously insecure option.
"},{"location":"archive/2018/c1-security-requirements/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"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.
"},{"location":"archive/2018/c1-security-requirements/#references","title":"References","text":"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.
Error and exception handling occurs in all areas of an application including critical business logic as well as security features and framework code.
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.
"},{"location":"archive/2018/c10-errors-exceptions/#error-handling-mistakes","title":"Error Handling Mistakes","text":"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.
Mistakes in error handling can lead to different kinds of security vulnerabilities.
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.
"},{"location":"archive/2018/c2-leverage-security-frameworks-libraries/#implementation-best-practices","title":"Implementation Best Practices","text":"When incorporating third party libraries or frameworks into your software, it is important to consider the following best practices:
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.
"},{"location":"archive/2018/c2-leverage-security-frameworks-libraries/#tools","title":"Tools","text":"This section describes secure access to all data stores, including both relational databases and NoSQL databases. Some areas to consider:
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.
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.
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 and the OWASP Cheat Sheet on Query Parametrization.
"},{"location":"archive/2018/c3-secure-database/#caution-on-query-parametrization","title":"Caution on Query Parametrization","text":"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.
"},{"location":"archive/2018/c3-secure-database/#secure-configuration","title":"Secure Configuration","text":"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.
A quick guidance on providing a secure configuration can be found in the Database Cheat Sheet.
"},{"location":"archive/2018/c3-secure-database/#secure-authentication","title":"Secure Authentication","text":"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.
A quick guidance on providing a secure authentication process can be found in the Database Cheat Sheet.
"},{"location":"archive/2018/c3-secure-database/#secure-communication","title":"Secure Communication","text":"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.
A quick guidance on providing a secure communication mean can be found in the Database Cheat Sheet.
"},{"location":"archive/2018/c3-secure-database/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"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.
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.
"},{"location":"archive/2018/c4-encode-escape-data/#contextual-output-encoding","title":"Contextual Output Encoding","text":"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.
"},{"location":"archive/2018/c4-encode-escape-data/#java-encoding-examples","title":"Java Encoding Examples","text":"For examples of the OWASP Java Encoder providing contextual output encoding see: OWASP Java Encoder Project Examples.
"},{"location":"archive/2018/c4-encode-escape-data/#net-encoding-examples","title":".NET Encoding Examples","text":"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.
In Zend Framework 2, Zend\\Escaper can be used for encoding the output. For contextual encoding examples see Context-specific escaping with Zend-Escaper.
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.
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.
"},{"location":"archive/2018/c4-encode-escape-data/#character-encoding-and-canonicalization","title":"Character Encoding and Canonicalization","text":"Unicode Encoding is a method for storing characters with multiple bytes. Wherever input data is allowed, data can be entered using Unicode to disguise malicious code and permit a variety of attacks. RFC 2279 references many ways that text can be encoded.
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.
To be secure against canonicalization related attacks means an application should be safe when malformed Unicode and other malformed character representations are entered.
"},{"location":"archive/2018/c4-encode-escape-data/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"Input validation is a programming technique that ensures only properly formatted data may enter a software system component.
"},{"location":"archive/2018/c5-validate-inputs/#syntax-and-semantic-validity","title":"Syntax and Semantic Validity","text":"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).
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).
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.
"},{"location":"archive/2018/c5-validate-inputs/#allowlisting-vs-denylisting","title":"Allowlisting vs Denylisting","text":"There are two general approaches to performing input syntax validation, commonly known as allow and deny lists:
<SCRIPT> in order to help prevent XSS. However, this defense could be evaded with a lower case script tag or a script tag of mixed case.Important When building secure software, allowlisting is the recommended minimal approach. Denylisting is prone to error and can be bypassed with various evasion techniques and can be dangerous when depended on by itself. Even though denylisting can often be evaded, it can often be useful to help detect obvious attacks. So while allowlisting helps limit the attack surface by ensuring data is of the right syntactic and semantic validity, denylisting helps detect and potentially stop obvious attacks.
"},{"location":"archive/2018/c5-validate-inputs/#client-side-and-server-side-validation","title":"Client side and Server side Validation","text":"Input validation must always be done on the server-side for security. While client side validation can be useful for both functional and some security purposes, it can often be easily bypassed. This makes server-side validation even more fundamental to security. For example, JavaScript validation may alert the user that a particular field must consist of numbers but the server side application must validate that the submitted data only consists of numbers in the appropriate numerical range for that feature.
"},{"location":"archive/2018/c5-validate-inputs/#regular-expressions","title":"Regular Expressions","text":"Regular expressions offer a way to check whether data matches a specific pattern. Let\u2019s start with a basic example.
The following regular expression is used to define a allowlist rule to validate usernames.
^[a-z0-9_]{3,16}$\nThis regular expression allows only lowercase letters, numbers and the underscore character. The username is also restricted to a length of 3 and 16 characters.
"},{"location":"archive/2018/c5-validate-inputs/#caution-potential-for-denial-of-service","title":"Caution: Potential for Denial of Service","text":"Care should be exercised when creating regular expressions. Poorly designed expressions may result in potential denial of service conditions (aka ReDoS ). Various tools can test to verify that regular expressions are not vulnerable to ReDoS.
"},{"location":"archive/2018/c5-validate-inputs/#caution-complexity","title":"Caution: Complexity","text":"Regular expressions are just one way to accomplish validation. Regular expressions can be difficult to maintain or understand for some developers. Other validation alternatives involve writing validation methods programmatically which can be easier to maintain for some developers.
"},{"location":"archive/2018/c5-validate-inputs/#limits-of-input-validation","title":"Limits of Input Validation","text":"Input validation does not always make data \"safe\" since certain forms of complex input may be \"valid\" but still dangerous. For example, a valid email address may contain a SQL injection attack or a valid URL may contain a Cross Site Scripting attack. Additional defenses besides input validation should always be applied to data such as query parametrization or escaping.
"},{"location":"archive/2018/c5-validate-inputs/#challenges-of-validating-serialized-data","title":"Challenges of Validating Serialized Data","text":"Some forms of input are so complex that validation can only minimally protect the application. For example, it's dangerous to deserialize untrusted data or data that can be manipulated by an attacker. The only safe architectural pattern is to not accept serialized objects from untrusted sources or to only deserialize in limited capacity for only simple data types. You should avoid processing serialized data formats and use easier to defend formats such as JSON when possible.
If that is not possible then consider a series of validation defenses when processing serialized data.
Some frameworks support automatic binding of HTTP requests parameters to server-side objects used by the application. This auto-binding feature can allow an attacker to update server-side objects that were not meant to be modified. The attacker can possibly modify their access control level or circumvent the intended business logic of the application with this feature.
This attack has a number of names including: mass assignment, autobinding and object injection.
As a simple example, if the user object has a field named privilege which specifies the user's privilege level in the application, a malicious user can look for pages where user data is modified and add privilege=admin to the HTTP parameters sent. If auto-binding is enabled in an insecure fashion, the server-side object representing the user will be modified accordingly.
Two approaches can be used to handle this:
More examples are available in the OWASP Mass Assignment Cheat Sheet.
"},{"location":"archive/2018/c5-validate-inputs/#validating-and-sanitizing-html","title":"Validating and Sanitizing HTML","text":"Consider an application that needs to accept HTML from users (via a WYSIWYG editor that represents content as HTML or features that directly accept HTML in input). In this situation validation or escaping will not help.
Therefore, you need a library that can parse and clean HTML formatted text. Please see the XSS Prevention Cheat Sheet on HTML Sanitization for more information on HTML Sanitization.
"},{"location":"archive/2018/c5-validate-inputs/#validation-functionality-in-libraries-and-frameworks","title":"Validation Functionality in Libraries and Frameworks","text":"All languages and most frameworks provide validation libraries or functions which should be leveraged to validate data. Validation libraries typically cover common data types, length requirements, integer ranges, \"is null\" checks and more. Many validation libraries and frameworks allow you to define your own regular expression or logic for custom validation in a way that allows the programmer to leverage that functionality throughout your application. Examples of validation functionality include PHP\u2019s filter functions or the Hibernate Validator for Java. Examples of HTML Sanitizers include Ruby on Rails sanitize method, OWASP Java HTML Sanitizer or DOMPurify.
"},{"location":"archive/2018/c5-validate-inputs/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"Digital Identity is the unique representation of a user (or other subject) as they engage in an online transaction. Authentication is the process of verifying that an individual or entity is who they claim to be. Session management is a process by which a server maintains the state of the users authentication so that the user may continue to use the system without re-authenticating. The NIST Special Publication 800-63B: Digital Identity Guidelines (Authentication and Life Cycle Management) provides solid guidance on implementing digital identity, authentication and session management controls.
Below are some recommendations for secure implementation.
"},{"location":"archive/2018/c6-digital-identity/#authentication-levels","title":"Authentication Levels","text":"NIST 800-63b describes three levels of a authentication assurance called a authentication assurance level (AAL). AAL level 1 is reserved for lower-risk applications that do not contain PII or other private data. At AAL level 1 only single-factor authentication is required, typically through the use of a password.
"},{"location":"archive/2018/c6-digital-identity/#level-1-passwords","title":"Level 1 : Passwords","text":"Passwords are really really important. We need policy, we need to store them securely, we need to sometimes allow users to reset them.
"},{"location":"archive/2018/c6-digital-identity/#password-requirements","title":"Password Requirements","text":"Passwords should comply with the following requirements at the very least:
It is common for an application to have a mechanism for a user to gain access to their account in the event they forget their password. A good design workflow for a password recovery feature will use multi-factor authentication elements. For example, it may ask a security question - something they know, and then send a generated token to a device - something they own.
Please see the Forgot Password Cheat Sheet and Choosing and Using Security Questions Cheat Sheet for further details.
"},{"location":"archive/2018/c6-digital-identity/#implement-secure-password-storage","title":"Implement Secure Password Storage","text":"In order to provide strong authentication controls, an application must securely store user credentials. Furthermore, cryptographic controls should be in place such that if a credential (e.g., a password) is compromised, the attacker does not immediately have access to this information.
"},{"location":"archive/2018/c6-digital-identity/#php-example-for-password-storage","title":"PHP Example for Password Storage","text":"Below is an example for secure password hashing in PHP using password_hash() function (available since 5.5.0) which defaults to using the bcrypt algorithm. The example uses a work factor of 15.
<?php\n $cost = 15;\n $password_hash = password_hash(\"secret_password\", PASSWORD_DEFAULT,[\"cost\" => $cost]);\n?>\nPlease see the OWASP Password Storage Cheat Sheet for further details.
"},{"location":"archive/2018/c6-digital-identity/#level-2-multi-factor-authentication","title":"Level 2 : Multi-Factor Authentication","text":"NIST 800-63b AAL level 2 is reserved for higher-risk applications that contain \"self-asserted PII or other personal information made available online.\" At AAL level 2 multi-factor authentication is required including OTP or other forms of multi-factor implementation.
Multi-factor authentication (MFA) ensures that users are who they claim to be by requiring them to identify themselves with a combination of:
Using passwords as a sole factor provides weak security. Multi-factor solutions provide a more robust solution by requiring an attacker to acquire more than one element to authenticate with the service.
It is worth noting that biometrics, when employed as a single factor of authentication, are not considered acceptable secrets for digital authentication. They can be obtained online or by taking a picture of someone with a camera phone (e.g., facial images) with or without their knowledge, lifted from objects someone touches (e.g., latent fingerprints), or captured with high resolution images (e.g., iris patterns). Biometrics must be used only as part of multi-factor authentication with a physical authenticator (something you own). For example, accessing a multi-factor one-time password (OTP) device that will generate a one-time password that the user manually enters for the verifier.
"},{"location":"archive/2018/c6-digital-identity/#level-3-cryptographic-based-authentication","title":"Level 3 : Cryptographic Based Authentication","text":"NIST 800-63b Authentication Assurance Level 3 (AAL3) is required when the impact of compromised systems could lead to personal harm, significant financial loss, harm the public interest or involve civil or criminal violations. AAL3 requires authentication that is \"based on proof of possession of a key through a cryptographic protocol.\" This type of authentication is used to achieve the strongest level of authentication assurance. This is typically done though hardware cryptographic modules.
"},{"location":"archive/2018/c6-digital-identity/#session-management","title":"Session Management","text":"Once the initial successful user authentication has taken place, an application may choose to track and maintain this authentication state for a limited amount of time. This will allow the user to continue using the application without having to keep re-authentication with each request. Tracking of this user state is called Session Management.
"},{"location":"archive/2018/c6-digital-identity/#session-generation-and-expiration","title":"Session Generation and Expiration","text":"User state is tracked in a session. This session is typically stored on the server for traditional web based session management. A session identifier is then given to the user so the user can identify which server-side session contains the correct user data. The client only needs to maintain this session identifier, which also keeps sensitive server-side session data off of the client.
Here are a few controls to consider when building or implementing session management solutions:
Please see the Session Management Cheat Sheet further details. ASVS Section 3 covers additional session management requirements.
"},{"location":"archive/2018/c6-digital-identity/#browser-cookies","title":"Browser Cookies","text":"Browser cookies are a common method for web application to store session identifiers for web applications implementing standard session management techniques. Here are some defenses to consider when using browser cookies.
Server-side sessions can be limiting for some forms of authentication. \"Stateless services\" allow for client side management of session data for performance purposes so they server has less of a burden to store and verify user session. These \"stateless\" applications generate a short-lived access token which can be used to authenticate a client request without sending the user's credentials after the initial authentication.
"},{"location":"archive/2018/c6-digital-identity/#jwt-json-web-tokens","title":"JWT (JSON Web Tokens)","text":"JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. A JWT token is created during authentication and is verified by the server (or servers) before any processing.
However, JWTs are often not saved by the server after initial creation. JWTs are typically created and then handed to a client without being saved by the server in any way. The integrity of the token is maintained through the use of digital signatures so a server can later verify that the JWT is still valid and was not tampered with since its creation.
This approach is both stateless and portable in the way that client and server technologies can be different yet still interact.
Caution: Digital identity, authentication and session management are very big topics. We're scratching the surface of the topic of Digital Identity here. Ensure that your most capable engineering talent is responsible for maintaining the complexity involved with most Identity solutions.
"},{"location":"archive/2018/c6-digital-identity/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"Access Control (or Authorization) is the process of granting or denying specific requests from a user, program, or process. Access control also involves the act of granting and revoking those privileges.
It should be noted that authorization (verifying access to specific features or resources) is not equivalent to authentication (verifying identity).
Access Control functionality often spans many areas of software depending on the complexity of the access control system. For example, managing access control metadata or building caching for scalability purposes are often additional components in an access control system that need to be built or managed. There are several different types of access control design that should be considered.
The following \"positive\" access control design requirements should be considered at the initial stages of application development.
"},{"location":"archive/2018/c7-enforce-access-controls/#1-design-access-control-thoroughly-up-front","title":"1) Design Access Control Thoroughly Up Front","text":"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 design that must be thoroughly designed up front, especially when addressing requirements like multi-tenancy and horizontal (data dependent) access control.
Access Control design may start simple but can often grow into a complex and feature-heavy security control. When evaluating access control capability of software frameworks, ensure that your access control functionality will allow for customization for your specific access control feature need.
"},{"location":"archive/2018/c7-enforce-access-controls/#2-force-all-requests-to-go-through-access-control-checks","title":"2) Force All Requests to Go Through Access Control Checks","text":"Ensure that all request go through some kind of access control verification layer. Technologies like Java filters or other automatic request processing mechanisms are ideal programming artifacts that will help ensure that all requests go through some kind of access control check.
"},{"location":"archive/2018/c7-enforce-access-controls/#3-deny-by-default","title":"3) Deny by Default","text":"Deny by default is the principle that if a request is not specifically allowed, it is denied. There are many ways that this rule will manifest in application code. Some examples of these are:
Ensure that all users, programs, or processes are only given as least or as little necessary access as possible. Be wary of systems that do not provide granular access control configuration capabilities.
"},{"location":"archive/2018/c7-enforce-access-controls/#5-dont-hard-code-roles","title":"5) Don't Hard-Code Roles","text":"Many application frameworks default to access control that is role based. It is common to find application code that is filled with checks of this nature.
if (user.hasRole(\"ADMIN\")) || (user.hasRole(\"MANAGER\")) {\n deleteAccount();\n }\nBe careful about this type of role-based programming in code. It has the following limitations or dangers.
Instead, please consider the following access control programming methodology:
if (user.hasAccess(\"DELETE_ACCOUNT\")) {\n deleteAccount();\n }\nAttribute or feature-based access control checks of this nature are the starting point to building well-designed and feature-rich access control systems. This type of programming also allows for greater access control customization capability over time.
"},{"location":"archive/2018/c7-enforce-access-controls/#6-log-all-access-control-events","title":"6) Log All Access Control Events","text":"All access control failures should be logged as these may be indicative of a malicious user probing the application for vulnerabilities.
"},{"location":"archive/2018/c7-enforce-access-controls/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"Sensitive data such as passwords, credit card numbers, health records, personal information and business secrets require extra protection, particularly if that data falls under privacy laws (EU's General Data Protection Regulation GDPR), financial data protection rules such as PCI Data Security Standard (PCI DSS) or other regulations.
Attackers can steal data from web and web-service applications in a number of ways. For example, if sensitive information in sent over the internet without communications security, then an attacker on a shared wireless connection could see and steal another user's data. Also, an attacker could use SQL Injection to steal passwords and other credentials from an applications database and expose that information to the public.
"},{"location":"archive/2018/c8-protect-data-everywhere/#data-classification","title":"Data Classification","text":"It's critical to classify data in your system and determine which level of sensitivity each piece of data belongs to. Each data category can then be mapped to protection rules necessary for each level of sensitivity. For example, public marketing information that is not sensitive may be categorized as public data which is okay to place on the public website. Credit card numbers may be classified as private user data which may need to be encrypted while stored or in transit.
"},{"location":"archive/2018/c8-protect-data-everywhere/#encrypting-data-in-transit","title":"Encrypting Data in Transit","text":"When transmitting sensitive data over any network, end-to-end communications security (or encryption-in-transit) of some kind should be considered. TLS is by far the most common and widely supported cryptographic protocol for communications security. It is used by many types of applications (web, web service, mobile) to communicate over a network in a secure fashion. TLS must be properly configured in a variety of ways in order to properly defend secure communications.
The primary benefit of transport layer security is the protection of web application data from unauthorized disclosure and modification when it is transmitted between clients (web browsers) and the web application server, and between the web application server and back end and other non-browser based enterprise components.
"},{"location":"archive/2018/c8-protect-data-everywhere/#encrypting-data-at-rest","title":"Encrypting Data at Rest","text":"The first rule of sensitive data management is to avoid storing sensitive data when at all possible. If you must store sensitive data then make sure it's cryptographically protected in some way to avoid unauthorized disclosure and modification.
Cryptography (or crypto) is one of the more advanced topics of information security, and one whose understanding requires the most schooling and experience. It is difficult to get right because there are many approaches to encryption, each with advantages and disadvantages that need to be thoroughly understood by web solution architects and developers. In addition, serious cryptography research is typically based in advanced mathematics and number theory, providing a serious barrier to entry.
Instead of building cryptographic capability from scratch, it is strongly recommended that peer reviewed and open solutions be used, such as the Google Tink project, Libsodium, and secure storage capability built into many software frameworks and cloud services.
"},{"location":"archive/2018/c8-protect-data-everywhere/#mobile-application-secure-local-storage","title":"Mobile Application: Secure Local Storage","text":"Mobile applications are at particular risk of data leakage because mobile devices are regularly lost or stolen yet contain sensitive data.
As a general rule, only the minimum data required should be stored on the mobile device. But if you must store sensitive data on a mobile device, then sensitive data should be stored within each mobile operating systems specific data storage directory. On Android this will be the Android keystore and on iOS this will be the iOS keychain.
"},{"location":"archive/2018/c8-protect-data-everywhere/#secret-life-cycle","title":"Secret Life Cycle","text":"Secret keys can be used in a number of sensitive functions. For example, they can be used to sign JWTs, encrypt credit cards, sign hash, provide various forms of authentication and more. In managing keys, a number of precautious should be adhered including but not limited to the following:
When an immutable datatype such as string is used to store secrets, secrets can remain plaintext in the memory for a long time. Even if you try to nullify the string value, it still remains in the memory. string is an immutable type and cannot be changed. When you modify a string (try to overwrite it), a new copy of it is created. This means another copy of the unprotected secret will remain in the memory. Furthermore, there is no guarantee when garbage collector is going to clean up the secret. This increases exposure of plaintext secrets in the memory.
If secrets remain unprotected in the memory, they can get disclosed on the disk or external log aggregators through a number of scenarios: server crash logs, caching, serialisation or memory paging.
A safe way to handle secret is by using Read Once pattern. Read once is a defensive design pattern where a value can be only accessed once. After the first read, value is cleared from memory, and subsequent access is not possible. For an example implementation see this post.
"},{"location":"archive/2018/c8-protect-data-everywhere/#application-secrets-management","title":"Application Secrets Management","text":"Applications contain numerous \"secrets\" that are needed for security operations. These include certificates, SQL connection passwords, third party service account credentials, passwords, SSH keys, encryption keys and more. The unauthorized disclosure or modification of these secrets could lead to complete system compromise. In managing application secrets, consider the following.
Logging is a concept that most developers already use for debugging and diagnostic purposes. Security logging is an equally basic concept: to log security information during the runtime operation of an application. Monitoring is the live review of application and security logs using various forms of automation. The same tools and patterns can be used for operations, debugging and security purposes.
"},{"location":"archive/2018/c9-security-logging/#benefits-of-security-logging","title":"Benefits of Security Logging","text":"Security logging can be used for:
The following is a list of security logging implementation best practices.
Use logging to identify activity that indicates that a user is behaving maliciously. Potentially malicious activity to log includes:
When your application encounters such activity, your application should at the very least log the activity and mark it as a high severity issue. Ideally, your application should also respond to a possible identified attack, by for example invalidating the user\u2019s session and locking the user's account. The response mechanisms allows the software to react in realtime to possible identified attacks.
"},{"location":"archive/2018/c9-security-logging/#secure-logging-design","title":"Secure Logging Design","text":"Logging solutions must be built and managed in a secure way. Secure Logging design may include the following:
This document should be seen as a starting point rather than a comprehensive set of techniques and practices. We want to again emphasize that this document is intended to provide initial awareness around building secure software.
Good next steps to help build an application security program include:
If you have any questions for the project leadership team, please contact with your questions, comments, and ideas at our GitHub project repository.
"},{"location":"introduction/about-owasp/","title":"About OWASP","text":"The Open Worldwide Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications and APIs that can be trusted.
All OWASP tools, documents, videos, presentations, and chapters are free and open to anyone interested in improving application security.
We advocate approaching application security as a people, process, and technology problem, because the most effective approaches to application security require improvements in these areas.
OWASP is a new kind of organization. Our freedom from commercial pressures allows us to provide unbiased, practical, and cost-effective information about application security.
OWASP is not affiliated with any technology company, although we support the informed use of commercial security technology. OWASP produces many types of materials in a collaborative, transparent, and open way.
The OWASP Foundation is the non-profit entity that ensures the project's long-term success. Almost everyone associated with OWASP is a volunteer, including the OWASP board, chapter leaders, project leaders, and project members. We support innovative security research with grants and infrastructure.
"},{"location":"introduction/contributing/","title":"How to Contribute?","text":"Please don\u2019t hesitate to contact the OWASP Proactive Control project with your questions, comments, and ideas.
You can contact maintainers directly, use our project-top10-proactive-controls OWASP slack channel, or visit our github page.
You find the source code of the current version of the OWASP Top 10 Proactive Controls in the docs/ directory within the git repository. Please focus upon contributions for the current version, not archived versions within docs/archive.
When you check our open issues on github, you can see that some issues are tagged with help wanted or good first issue. Choose these if you want to help out the project!
If you can run python, you can locally run the OWASP Proactive Control website locally. We recommend this to test your changes before pushing them to github.
To do this, we will use venv to create a local python environment to install the needed mkdocs package.
# creates and activates a new python environment in a new `venv` directory\n$ python3 -m venv venv\n$ source venv/bin/activate\n\n# install the mkdocs package\n$ pip install mkdocs-material\n\n# switch into your checked-out OWASP Proactive Controls directory\n$ cd owasp-proactive-controls\n\n# run the local webserver\n$ mkdocs server\n\n# now you can point your browser to http://localhost:8000 and check\n# how your changes will look like\nOWASP is a volunteer-driven organization. Those volunteers contributed many useful documents, and this section points to some related OWASP documents and projects:
"},{"location":"introduction/related-owasp-projects/#owasp-top-10","title":"OWASP Top 10","text":"The best-known OWASP document is the OWASP Top 10. They detail the most common web application vulnerabilities and are also the base for this document. In contrast, this document is focused on defensive techniques and controls as opposed to risks. Each 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.
"},{"location":"introduction/related-owasp-projects/#owasp-asvs","title":"OWASP ASVS","text":"The OWASP Application Security Verification Standard (ASVS) is a catalog of available security requirements and verification criteria. OWASP ASVS can be a source of detailed security requirements for development teams. 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.
"},{"location":"introduction/related-owasp-projects/#owasp-samm","title":"OWASP SAMM","text":"Software Assurance Maturity Model (SAMM) is an open framework to help organizations implement a strategy for maturing the software security tailored to the specific risks of the organization. . SAMM supports the complete software life cycle and can be used to identify what
"},{"location":"introduction/related-owasp-projects/#threat-modeling-in-general","title":"Threat Modeling in General","text":"Threat Modeling is an important part of secure application development, which can help identify potential security threats, derive security requirements, and tailor security controls to prevent potential threats. Successful use of security requirements involves four steps: discovery, documentation, implementation, and verification of the correct implementation of the functionality within an application. Threat modelling is one way to derive security requirements. Other sources are: industry standards, applicable laws, history of past vulnerabilities. Modeling tools, like OWASP Threat Dragon can be used to create threat model diagrams as part of a secure development life cycle.
"},{"location":"introduction/related-owasp-projects/#domain-specific-documents","title":"Domain-Specific Documents","text":"It is important to notice that this document primarily focuses on web applications, but other Top 10s could apply to your application, too. Examples of those are:
Access Control (or Authorization) is allowing or denying specific requests from a user, program, or process. With each access control decision, a given subject requests access to a given object. Access control is the process that considers the defined policy and determines if a given subject is allowed to access a given object. Access control also involves the act of granting and revoking those privileges. Access Control often applies on multiple levels, e.g., given an application with a database backend, it applies both on the business logic level as well as on a database row level. In addition, applications can offer multiple ways of performing operations (e.g., through APIs or the website). All those different levels and access paths must be aligned, i.e., use the same access control checks, to protect against security vulnerabilities. Authorization (verifying access to specific features or resources) is not equivalent to authentication (verifying identity).
"},{"location":"the-top-10/c1-accesscontrol/#threats","title":"Threats","text":"Below is a minimum set of access control design requirements that should be considered at the initial stages of application development.
"},{"location":"the-top-10/c1-accesscontrol/#1-design-access-control-thoroughly-up-front","title":"1) Design Access Control Thoroughly Up Front","text":"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 design that must be thoroughly designed up front, especially when addressing requirements like multi-tenancy and horizontal (data dependent) access control.
Two core types of access control design should be considered.
Ensure that all access requests are forced to go through an access control verification layer. Technologies like Java filters or other automatic request processing mechanisms are ideal programming components that will ensure that all requests go through an access control check. This is referred to as Policy Enforcement Point in RFC 2904.
"},{"location":"the-top-10/c1-accesscontrol/#3-consolidate-the-access-control-check","title":"3) Consolidate the access control check","text":"Use a single access control procedure or routine. This prevents the scenario where you have multiple access control implementations, where most are correct, but some are flawed. By using a centralized approach, you can focus security resources on reviewing and fixing one central library or function that performs the access control check, and then reuse it throughout your code base and organization.
"},{"location":"the-top-10/c1-accesscontrol/#4-deny-by-default","title":"4) Deny by Default","text":"Ensure that by default, all the requests are denied, unless they are specifically allowed. This also includes accessing API (REST or webhooks) with missing access controls. There are many ways that this rule will manifest in the application code. Some examples are:
Application code may throw an error or exception while processing access control requests. In these cases, access control should always be denied.
When an administrator creates a new user or a user registers for a new account, that account should have minimal or no access by default until that access is configured.
When a new feature is added to an application, all users should be denied to use it until it\u2019s properly configured.
An example of implementing that principle is to create dedicated privileged roles and accounts for every organization function that requires highly privileged activities and avoid using an \u201cadmin\u201d role/account that is fully privileged daily.
To further improve the security, you can implement Just-in-Time (JIT) or Just-enough-Access (JEA): ensure that all users, programs, or processes are only given just enough access to achieve their current mission. This access should be provided just in time, when the subject makes the request, and the access should be granted for a short time. Be wary of systems that do not provide granular access control configuration capabilities.
"},{"location":"the-top-10/c1-accesscontrol/#6-do-not-hard-code-roles","title":"6) Do not Hard-code Roles","text":"Many application frameworks default to access control that is role based. It is common to find application code filled with checks of this nature.
if (user.hasRole(\"ADMIN\")) || (user.hasRole(\"MANAGER\")) {\n deleteAccount();\n}\nBe careful about this type of role-based programming in code. It has the following limitations or dangers:
Please consider the following access control enforcement points using this following programming methodology:
if (user.hasPermission(\"DELETE_ACCOUNT\")) {\n deleteAccount();\n}\nAttribute or feature-based access control checks of this nature are the starting point to building well-designed and feature-rich access control systems. This type of programming also allows for greater access control customization capability over time.
"},{"location":"the-top-10/c1-accesscontrol/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"While Injection Attacks typically target the victim server itself, Server-Side Request Forgery (SSRF) attacks try to coerce the server to perform a request on behalf of the attacker. Why is this beneficial for the attacker? The outgoing request will be performed with the identity of the victim server and thus the attacker might execute operations with elevated operations.
"},{"location":"the-top-10/c10-stop-server-side-request-forgery/#threats","title":"Threats","text":"Examples of this contain:
There multiple ways of preventing SSRF:
Sensitive data such as passwords, credit card numbers, health records, personal information and business secrets require extra protection, particularly if that data falls under privacy laws (EU's General Data Protection Regulation GDPR), financial data protection rules such as PCI Data Security Standard (PCI DSS) or other regulations.
Attackers can steal data from web and web service applications in a number of ways. For example, if sensitive information is sent over the internet without communications security, then an attacker on a shared wireless connection could capture and steal another user\u2019s data. Also, an attacker could use SQL Injection to steal passwords and other credentials from an applications database and expose that information to the public.
Privacy is assurance that the confidentiality of, and access to, certain information about an entity is protected. Users of the things developers build want their information protected from disclosure.
Protect sensitive data such as passwords, credit card numbers, health records, personal information, and business secrets.
Regulations exist to force companies to protect user\u2019s personal information. The European Union values individual privacy, such that they created the EU General Data Protection Regulation GDPR. Financial data protection rules such as PCI Data Security Standard (PCI DSS) also exist to protect cardholder privacy.
Cryptography is the art or science concerning the principles, means, and methods for rendering plain information unintelligible and restoring encrypted information to intelligible form. Individual user data requires cryptography to ensure it is properly cared for when stored.
"},{"location":"the-top-10/c2-crypto/#classify-data-types-in-your-application","title":"Classify data types in your application","text":"It\u2019s critical to classify data in your system and determine which level of sensitivity each piece of data belongs to. Each data category can then be mapped to protection rules necessary for each level of sensitivity. For example, public marketing information that is not sensitive may be categorized as public data which is okay to place on the public website. Credit card numbers may be classified as private user data which will need to be encrypted while stored, processed or in transit.
Data classification can also be mandated by legislation, e.g., GDPR when serving users within the European Union.
Classify the data sent, processed, and stored in your system and determine what level of sensitivity the data belongs to. Categorize the data to define specific protection rules for each type. The rule creation enables your team to perform data minimization and try not to store sensitive data whenever possible.
For example, public marketing information that is not sensitive may be categorized as public data, which is okay to place on the public website and does not need to be encrypted. Credit card numbers need to be encrypted while stored, processed, and in transit.
"},{"location":"the-top-10/c2-crypto/#threats","title":"Threats","text":"When it comes to cryptography, there are a few simple rules:
The first rule of sensitive data management is to avoid storing sensitive data when at all possible. If you must store sensitive data then make sure it is cryptographically protected in some way to avoid unauthorized disclosure and modification. Cryptography (or crypto) is one of the more advanced topics of information security and one whose understanding requires the most schooling and experience. It is difficult to get right because there are many approaches to encryption, each with advantages and disadvantages that need to be thoroughly understood by web solution architects and developers. In addition, serious cryptography research is typically based on advanced mathematics and number theory, providing a serious barrier to entry. Designing or building cryptographic algorithms is very error-prone (see side-channel attacks). Instead of building cryptographic capability from scratch, it is strongly recommended that peer-reviewed and open solutions be used, such as the Google Tink project, Libsodium, and secure storage capability built into many software frameworks and cloud services.
Most web applications will face the challenge of storing user\u2019s passwords to set up authentication services. Store the passwords safely to ensure an attacker cannot quickly obtain them. Do not store the passwords in plain text anywhere in the database. Always use a hashing function to store passwords. Enhance the hashing function by adding a random salt for each item to increase the randomness of hashes.
"},{"location":"the-top-10/c2-crypto/#special-case-application-secrets-management","title":"Special Case: Application Secrets management","text":"Applications contain numerous \u201csecrets\u201d that are needed for security operations. These include certificates, SQL connection passwords, third party service account credentials, passwords, SSH keys, encryption keys and more. The unauthorized disclosure or modification of these secrets could lead to complete system compromise. In managing application secrets, consider the following: Don\u2019t store secrets in code, config files or pass them through environment variables. Use tools like GitRob or TruffleHog to scan code repositories for secrets. Your code should be written in a way that even if your code would be disclosed, e.g., due to a defective configured github repository, your running applications are still secure. Keep keys and your other application-level secrets in a secrets vault like KeyWhiz or Hashicorp's Vault project , Amazon KMS, or AWS Secrets Manager to provide secure storage and access to application-level secrets at run-time. Many web-frameworks such as Ruby on Rails provide integrated ways of dealing with secrets and credentials.
"},{"location":"the-top-10/c2-crypto/#key-life-cycle","title":"Key Life Cycle","text":"Secret keys are used in applications with a number of sensitive functions. For example, secret keys can be used to sign JWTs, protect credit cards, provide various forms of authentication as well as facilitate other sensitive security features. In managing keys, a number of rules should be followed including
Sensitive data such as passwords, credit card numbers, health records, personal information and business secrets require extra protection, particularly if that data falls under privacy laws (EU's General Data Protection Regulation GDPR), financial data protection rules such as PCI Data Security Standard (PCI DSS) or other regulations. Attackers can steal data from web and web service applications in a number of ways. For example, if sensitive information is sent over the internet without communications security, then an attacker on a shared wireless connection could capture and steal another user\u2019s data. Also, an attacker could use SQL Injection to steal passwords and other credentials from an applications database and expose that information to the public.
"},{"location":"the-top-10/c2-crypto/#use-current-cryptographic-protocols","title":"Use current cryptographic protocols","text":"When developing web applications, use TLSv1.2 or TLSv1.3, preferably TLSv1.3. If possible, investigate the usage of HTTP/2 or HTTP/3 as they warrant the usage of security TLS versions/algorithms.
Web servers can instruct web browsers to uphold minimal transport-level security:
Cryptographic recommendations change over time. To allow for this, make cryptographic choices such as used algorithms or key sizes configurable. This is called Cryptographic Agility
If the application needs to support high availability, design key-rollover procedures.
"},{"location":"the-top-10/c2-crypto/#vulnerabilities-prevented","title":"Vulnerabilities Prevented","text":"Input validation is a programming technique that ensures only properly formatted data may enter a software system component. When the injection attack targets a client (for example JavaScript based attacks), web servers can perform quoting/encoding on the attacker-provided data before forwarding it to the client.
Injection attacks commonly occur if an application confuses data input as executable commands and are often possible where input validation is forgotten or implemented wrong. For example, imagine that a web application accepts an email address as input from a user. The email address would be the expected \u201cdata\u201d. Attackers now search for ways to confuse applications to execute this (supposed) data as commands. Different injection attacks target different areas:
An application should check that data is syntactically and semantically valid (in that order) before using it in any way (including displaying it back to the user).
Syntactic validity means that the data is in the expected form. For example, an application may allow users to select a four-digit \u201caccount ID\u201d to perform some operation. The application should assume the user is entering a SQL injection payload and check that the data entered by the user is precisely four digits in length and consists only of numbers (in addition to utilizing proper query parametrization).
Semantic validity includes only accepting input within an acceptable range for application functionality and context. For example, a start date must be before an end date when choosing date ranges.
Protection against Injection Attacks is typically based upon a defense-in-depth approach and incorporates input filtering, output escaping, and utilization of hardening mechanisms. The former two are only dependent upon implemented security measures, and the latter is mostly dependent upon client-support, e.g., when protecting against XSS, filtering XSS from input and escaping output data server-side would prevent XSS regardless of the used web browser; adding a Content-Security-Policy prevents XSS, but only if the user\u2019s browser supports it. Due to this, security must never depend upon optional hardening measures alone.
"},{"location":"the-top-10/c3-validate-input-and-handle-exceptions/#prevent-malicious-data-from-entering-the-system","title":"Prevent malicious data from entering the system","text":"Never trust provided data! Screen all data for malicious patterns or, even better, check all data against an allow list.
"},{"location":"the-top-10/c3-validate-input-and-handle-exceptions/#allowlisting-vs-denylisting","title":"Allowlisting vs Denylisting","text":"There are two general approaches to performing syntactic validation, commonly known as allow and deny lists:
Always perform Input validation on the server side for security. While client-side validation is useful for both functional and security purposes, it is easily bypassed. Therefore, client-side validation is performed for usability purposes, but the application\u2019s security must not depend upon it. For example, JavaScript validation may alert the user that a particular field must consist of numbers. Still, the server-side application must validate that the submitted data only consists of numbers in the appropriate numerical range for that feature. Another benefit of using both client AND server-side validation is that any server-side validation warnings can be logged to inform operations of a potential hacker as the client-side validation had been bypassed.
"},{"location":"the-top-10/c3-validate-input-and-handle-exceptions/#regular-expressions","title":"Regular Expressions","text":"Regular expressions offer a way to check whether data matches a specific pattern. Let\u2019s start with a basic example. The following regular expression defines an allowlist rule to validate usernames.
^\\[a-z0-9_\\]{3,16}$\nThis regular expression allows only lowercase letters, numbers, and the underscore character. The username is also restricted to a length of 3 and 16 characters.
Caution: Potential for Denial of Service
Care should be exercised when creating regular expressions. Poorly designed expressions may result in potential denial of service conditions (aka ReDoS ). Various tools can be tested to verify that regular expressions are not vulnerable to ReDoS.
Caution: Complexity
Regular expressions are just one way to accomplish validation. Regular expressions can be difficult to maintain or understand for some developers. Other validation alternatives involve writing validation methods programmatically, which can be easier to maintain for some developers.
"},{"location":"the-top-10/c3-validate-input-and-handle-exceptions/#unexpected-user-input-mass-assignment","title":"Unexpected User Input (Mass Assignment)","text":"Some frameworks support automatic binding of HTTP requests parameters to server-side objects used by the application. This auto-binding feature can allow an attacker to update server-side objects that were not meant to be modified. The attacker can possibly modify their access control level or circumvent the intended business logic of the application with this feature. This attack has a number of names including: mass assignment, autobinding and object injection. As a simple example, if the user object has a field privilege which specifies the user\u2019s privilege level in the application, a malicious user can look for pages where user data is modified and add privilege=admin to the HTTP parameters sent. If auto-binding is enabled in an insecure fashion, the server-side object representing the user will be modified accordingly.
Two approaches can be used to handle this:
More examples are available in the OWASP Mass Assignment Cheat Sheet
"},{"location":"the-top-10/c3-validate-input-and-handle-exceptions/#limits-of-input-validation","title":"Limits of Input Validation","text":"Input validation does not always make data \u201csafe\u201d since certain complex input forms may be \u201cvalid\u201d but still dangerous. For example, a valid email address may contain a SQL injection attack, or a valid URL may contain a Cross Site Scripting attack. Additional defenses besides input validation should always be applied to data, such as query parametrization or escaping.
"},{"location":"the-top-10/c3-validate-input-and-handle-exceptions/#use-mechanisms-that-uphold-the-separation-of-data-and-commands","title":"Use mechanisms that uphold the separation of data and commands","text":"Even if malicious data has passed the input checking, applications can prevent injection attacks by never executing those malicious data as commands/code. Multiple measures can achieve this goal, most of them are technology-dependent. For Example:
A special case are JavaScript based Injection attacks (XSS). The injected malicious code is commonly executed within a victim\u2019s browser. Typically, attackers try to steal the user\u2019s session information from the browser and not directly execute commands (as they do on the server-side). In addition to server-side input filtering and output escaping, multiple client-side hardening measurements can be taken (these also protect against the special case of DOM-based XSS where no server-side logic is involved and thus cannot filter malicious code):
Consider an application that needs to accept HTML from users (via a WYSIWYG editor that represents content as HTML or features that directly accept HTML in input). In this situation, validation or escaping will not help.
Therefore, you need a library to parse and clean HTML formatted text. Please see the XSS Prevention Cheat Sheet on HTML Sanitization for more information on HTML Sanitization.
"},{"location":"the-top-10/c3-validate-input-and-handle-exceptions/#special-case-validate-data-during-deserialization","title":"Special Case: Validate Data During Deserialization","text":"Some forms of input are so complex that validation can only minimally protect the application. For example, it\u2019s dangerous to deserialize untrusted data or data that can be manipulated by an attacker. The only safe architectural pattern is to not accept serialized objects from untrusted sources or to only deserialize in limited capacity for only simple data types. You should avoid processing serialized data formats and use easier to defend formats such as JSON when possible.
If that is not possible then consider a series of validation defenses when processing serialized data.
Regarding Input Validation:
Helping with Input Validation:
Testing for Injection Attacks:
Helping with Hardening:
When designing a new application, creating a secure architecture prevents vulnerabilities before they even become part of the application. This prevents costly repairs and repudiation problems.
There are design principles that lead to secure architectures:
While it might be possible to implement all requirements manually, it is highly recommended to base one's architecture upon established and well-maintained third-party components. This has multiple benefits:
phpmyadmin) is deployed. After a 0day was found in mysqladmin, the whole database was extracted. During normal use, nobody uses phpmyadmin.The mantra \"Complexity is the enemy of security\" can be seen throughout this implementation guidance.
"},{"location":"the-top-10/c4-secure-architecture/#design-for-clarity-and-transparency","title":"Design for Clarity and Transparency","text":"Architecture should focus upon simplicity: the designed software should be only as complex as the intended user's requirements warrant. Focusing upon simplicity brings multiple benefits for the created software:
Two terms often heard are \"security by design\" and \"security by default\". The former implies, that the software system should be usable in a secure manner while the latter means that the initial configuration of the software system is secure.
This implies, that an system administrator has to make an explicit choice to introduce insecure configuration into the system. In contrast, the path of least resistance should always result in a secure system.
When focusing upon end-user interactions, this aspect is important for designing user interfaces and flows. When focusing upon developer interactions, developer-facing facilities such as framework, APIs, network APIs should be designed that when using them with default values, only secure operations should occur. Think about this when designing your configuration files too
"},{"location":"the-top-10/c4-secure-architecture/#clearly-articulate-whats-trusted-to-do-what-and-ensure-those-relationships-are-enforced","title":"Clearly articulate what's trusted to do what, and ensure those relationships are enforced","text":"Clearly articulate what's trusted to do what, and ensure those relationships are enforced, e.g., trust boundaries delineate blast radius and are enforced by controls, such as firewalls or gateways.
Attenuate what's allowed by careful validation at each step. Go deeper with threat modeling mnemonics like stride or methodologies like stride per element.
"},{"location":"the-top-10/c4-secure-architecture/#identify-and-minimize-your-exposed-components-attack-surface","title":"Identify and minimize your exposed components (\"attack surface\")","text":"Identify all areas that an attacker can access, review them and try to minimize them: attackers cannot attack what's not there.
In addition, exposing only a minimal set of operations makes long-term maintenance easier.
"},{"location":"the-top-10/c4-secure-architecture/#use-well-known-architecture-patterns","title":"Use well-known Architecture Patterns","text":"Experts have shared their wisdom about best practices in an easily digestible format called secure architecture patterns. Architecture patterns are reusable and can be applied across multiple applications.
For a solution to be considered a pattern, it must have these characteristics:
An architecture pattern is a way to solve a problem using a standard solution versus creating a custom solution. A secure architecture pattern is a standard solution that has been reviewed and hardened against known security threats.
Implementation:
\u201cSecure-by-Default\u201d means products are resilient against prevalent exploitation techniques out of the box without additional charge. The benefit of having an application secure from the start is that it removes the burden away from developers on how to lock a system down, providing them with an already secure product. It reduces the effort required to deploy products in a secure manner and gives greater confidence that they will remain secure over time.
"},{"location":"the-top-10/c5-secure-by-default/#threats","title":"Threats","text":"In modern cloud applications, when developers build applications, they are also building the infrastructure for their applications, making infrastructure decisions, including security-critical configurations, while writing their code. These are deployed on infrastructure created and configured via code, Infrastructure-as-code (IaC), using configurations applied at the application level ( including web server and database), at container, Function as a Service, or infrastructure level. For example, in the case of web applications, folder permissions need to follow the principle of least privilege to limit resource access rights. When web and mobile applications are deployed in production, the debugging should be disabled.
Is it important that when developers put together their infrastructure components, they:
As part of software development, a developer needs to ensure that software is configured securely by default at the application level. For example,
It is a common practice in software development to leverage libraries and frameworks. Secure libraries and software frameworks with embedded security help software developers prevent 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 (both open source and vendor) help accomplish security goals more efficiently and accurately.
When possible, the emphasis should be on using the existing secure features of frameworks rather than importing yet another third party libraries, which requires regular updates and maintenance. It is preferable to have developers take advantage of what they're already using instead of forcing yet another library on them.
When incorporating third party libraries or frameworks into your software, it is important to consider the following two categories of best practices:
Below each of these categories are further detailed to help secure your software.
"},{"location":"the-top-10/c6-use-secure-dependencies/#best-practices-to-identify-trusted-libraries","title":"Best Practices to Identify Trusted libraries","text":"Below are listed a few criteria you can use to select the next library or framework for your software. This is not an exhaustive list, but is a good start.
Sources: Download recommended security libraries from official sources over secure links and prefer signed packages to reduce the chance of including a modified, malicious component (See A08:2021-Software and Data Integrity Failures).
Popularity: Leverage libraries and frameworks used by many applications which have around large communities. Consider data points such as the number of GitHub stars a package\u2019s source code repository has received, and number of downloads from within a package manager.
Activity: Ensure that the library/ framework is actively maintained and issues are resolved in a timely fashion.
Maturity: Use stable versions . Projects in early stages of development area higher risk to your software .
Complexity: A large, complex library with lots of dependencies, is more difficult to incorporate into your software. Also, a high number of dependencies indicates a higher number of future upgrades to ensure all those dependencies are up-to-date and secured.
Security: If the package is open source, you can use static application security testing (SAST) or Software Composition Analysis (SCA) to help identify malicious code or security weaknesses, before first including them.
New security vulnerabilities are disclosed every day and are published in public databases like the NIST National Vulnerability Database (NVD) which identifies publicly known vulnerabilities using Common Vulnerabilities and Exposures (CVE). Furthermore, exploits made available in public databases allow attackers to automate their attacks. As a result of this, it is important to ensure on a regular basis that your software is free of well-known security vulnerabilities.
Maintain an inventory catalog of all the third party components. It is recommended to automatically create SBOMs (Software-Bill-Of-Materials) from within the build pipeline. A SBOM contains all used third-party dependencies and their versions and can be automatically monitored by a variety of supply chain management tools.
Perform continuous checks. Use your SBOMs together with periodic or continuous monitoring tools such as OWASP dependency-track to automatically detect well-known publicly disclosed vulnerabilities.
Verify for security early and often - integrate SCA tools in early stages of software development, to gain visibility in the number and criticality of security vulnerabilities of the software and its dependencies from every stage of the software development life cycle.
Proactively update libraries and components. Updating software must be a recurring task that occurs throughout the life cycle of the application or product, from ideation to retirement.
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 using vulnerable and outdated components with known vulnerabilities Top 10 2021.
"},{"location":"the-top-10/c6-use-secure-dependencies/#references","title":"References","text":"Digital Identity is a unique representation of an individual, organization (or another subject) as they engage in an online transaction. Authentication is the process of verifying that an individual or entity is who they claim to be.
Session management is the process by which a server maintains the state of the user\u2019s authentication so that the user may continue to use the system without re-authenticating. Digital identity, authentication, and session management are very complex topics. We're scratching the surface of the topic of Digital Identity here. Ensure that your most capable engineering talent is responsible for maintaining the complexity involved with most Identity solutions. The NIST Special Publication 800-63B: Digital Identity Guidelines (Authentication and Life Cycle Management provide solid guidance on implementing digital identity, authentication, and session management controls. Below are some recommendations for secure implementation to ensure strong digital identity controls are implemented in applications.
"},{"location":"the-top-10/c7-implement-digital-identity/#authentication-assurance-levels","title":"Authentication Assurance Levels","text":"NIST 800-63b describes three levels of authentication assurance called Authentication Assurance Level (AAL):
NIST 800-63b AAL level 2 is reserved for higher-risk applications that contain \"self-asserted PII or other personal information made available online.\" At AAL level 2 multi-factor authentication is required including OTP or other forms of multi-factor implementation. Multi-factor authentication (MFA) ensures that users are who they claim to be by requiring them to identify themselves with a combination of:
NIST 800-63b Authentication Assurance Level 3 (AAL3) is required when the impact of compromised systems could lead to personal harm, significant financial loss, harm the public interest or involve civil or criminal violations. AAL3 requires authentication that is \"based on proof of possession of a key through a cryptographic protocol.\" This type of authentication is used to achieve the strongest level of authentication assurance. This is typically done through hardware cryptographic modules. When developing web applications, this will commonly lead to WebAuthn or PassKeys.
"},{"location":"the-top-10/c7-implement-digital-identity/#session-management-client-vs-server-side-sessions","title":"Session Management: client- vs server-side sessions","text":"HTTP on its own is a session-less protocol: no data is shared between requests. When you look at how we are using the web, this is clearly not what is user-visible as for example you log into a website and stay logged in during subsequent requests. This is possible as session-management has been implemented on top of HTTP. Once the initial successful user authentication has taken place, an application may choose to track and maintain this authentication state for a limited amount of time. This will allow the user to continue using the application without having to keep re-authentication with each request. Tracking of this user state is called Session Management. Session-Management can be roughly categorized in client- and server-side session management. In the former, all session data is stored within the client and transmitted on each request to the server. The latter stores session-specific data on the server, e.g., in a database, and only transmits an identifier to the client. The client then submits only the session-identifier on each request and the server retrieves the session-data from the server-side storage.
From a security-perspective server-side sessions have multiple benefits:
Passwords should comply with the following requirements at the very least:
It is common for an application to have a mechanism for a user to gain access to their account in the event they forget their password. A good design workflow for a password recovery feature will use multi-factor authentication elements. For example, it may ask a security question - something they know, and then send a generated token to a device - something they own. Please see the Forgot_Password_Cheat_Sheet and Choosing_and_Using_Security_Questions_Cheat_Sheet for further details.
"},{"location":"the-top-10/c7-implement-digital-identity/#implement-secure-password-storage","title":"Implement Secure Password Storage","text":"In order to provide strong authentication controls, an application must securely store user credentials. Furthermore, cryptographic controls should be in place such that if a credential (e.g., a password) is compromised, the attacker does not immediately have access to this information. Please see the OWASP Password Storage Cheat Sheet for further details.
"},{"location":"the-top-10/c7-implement-digital-identity/#server-side-session-management","title":"Server-Side Session-Management","text":"Typically server-side session management is implemented with HTTP cookies which are used to store a session-identifier. When a new session is requested, the server generates a new session-identifier and transmits it to the client (browser). On each subsequent request, the session-identifier is transmitted from the client to the server, and the server uses this session-identifier to lookup session-data within a server-side database.
"},{"location":"the-top-10/c7-implement-digital-identity/#session-generation-and-expiration","title":"Session Generation and Expiration","text":"User state is tracked in a session. This session is typically stored on the server for traditional web based session management. A session identifier is then given to the user so the user can identify which server-side session contains the correct user data. The client only needs to maintain this session identifier, which also keeps sensitive server-side session data off of the client. Here are a few controls to consider when building or implementing session management solutions:
Please see the Session Management Cheat Sheet further details. ASVS Section 3 covers additional session management requirements.
"},{"location":"the-top-10/c7-implement-digital-identity/#client-side-session-management","title":"Client-Side Session-Management","text":"Server-side sessions can be limiting for some forms of authentication. \"Stateless services\" allow for client side management of session data for performance purposes so the server has less of a burden to store user sessions. These \"stateless\" applications typically generate a short-lived access token containing all of the current user\u2019s access permissions which is then included in all subsequent requests. Cryptography must be employed so that the client cannot alter the permissions stored within the token. When a client requests a server operation, the client includes the retrieved access token and the server verifies that the token has not been tampered with and extracts the permissions from the token. These permissions are then used for subsequent permission checks.
"},{"location":"the-top-10/c7-implement-digital-identity/#jwt-json-web-tokens","title":"JWT (JSON Web Tokens)","text":"JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted as long as it is digitally signed by a trusted authority. A JWT token is created during authentication and is verified by the server (or servers) before any processing. However, JWTs are often not saved by the server after initial creation. JWTs are typically created and then handed to a client without being saved by the server in any way. The integrity of the token is maintained through the use of digital signatures so a server can later verify that the JWT is still valid and was not tampered with since its creation. This approach is both stateless and portable in the way that client and server technologies can be different yet still interact. Please note, that if you are using JWTs you have to make sure that the returned JWT is actually using one of the signing algorithms that you are using. Otherwise, an attacker could try to create a JWT signed with the NULL algorithm, use a MAC-vs-Signature confusion attack, or provide a custom JWS key for signing. When you are issuing JWTs, make double-sure that you are using a secure private key for signing the JWTs: each output JWT gives an attacker all information needed to perform an offline cracking attack, so you should rotate keys frequently too.
"},{"location":"the-top-10/c7-implement-digital-identity/#browser-cookies","title":"Browser Cookies","text":"Browser cookies are a common method for web applications to store session identifiers for web applications implementing standard session management techniques. Here are some defenses to consider when using browser cookies.
Browsers are the gateway to the web for most users. As such, it's critical to employ robust security measures to protect the user from various threats. This section outlines the techniques and policies that can be implemented to bolster browser security.
While we are currently focusing upon traditional web browsers, please note that there is a diverse world of other client programs out there, ranging from mobile apps, API clients to smart-TVs. We encourage to verify what client-side security features are supported by your client and use the respective HTTP headers to configure them.
"},{"location":"the-top-10/c8-leverage-browser-security-features/#opportunistic-security-and-browser-support","title":"Opportunistic Security and Browser-Support","text":"Instructing the web browser to enforce security measures is always opportunistic: the web application cannot verify that the browser heeds the guidance given and thus these security measures should always be seen as additional (and optional) Hardening Measures that further complicate an attacker\u2019s life.
In addition, web browsers must actually support the security guidance offered by web applications. The level of support differs between different browsers and their versions. Web sites such as https://caniuse.com can be used to check which web browser (versions) support which features. The supported security features can change over time, e.g., the X-XSS-Protection header has been removed from all major browsers; the browsers\u2019 default behavior can change over time as seen with Referrer-Policy; and even the semantics of existing headers can change over time as seen with X-Content-Type-Options.
While the changing browser feature set can be problematic, typically newer browser provide more security features. They sometimes even enable them by default. Explicitly setting those security headers can unify the different browsers\u2019 behaviors and thus reduces maintenance effort.
A fully compromised browser might not heed security guidance but if an adversary was able to take full control of a browser, they already have far more damaging attack paths than just ignoring security guidance.
"},{"location":"the-top-10/c8-leverage-browser-security-features/#threats","title":"Threats","text":"Referer HTTP headers when proper Referrer-Policy is not set, potentially exposing private data or user activities.Typically, there are two (Security Header specific) ways that web applications can use to instruct web browsers about security: HTTP headers and HTML tags.
The behavior taken if a security directive is given more than one time is security header specific. For example, a duplicate X-Frame-Options header will disable its protection while a duplicate Content-Security-Policy header will lead to a stricter policy thus tightening its security. The following is a non-exhaustive list of potential Hardening mechanisms:
"},{"location":"the-top-10/c8-leverage-browser-security-features/#configure-the-browser-to-prevent-information-disclosure","title":"Configure the Browser to prevent Information Disclosure","text":"Information disclosure occurs if the browser transmits information over unencrypted channels (HTTP instead of HTTPS) or sends our too much information in the first place (e.g., through the Referer-Header). The following mechanisms reduce the possibility of information disclosure:
JavaScript based XSS attacks have been very common for decades. To reduce the potential impact of vulnerabilities, browsers offer rich defensive mechanisms that should reduce the potential impact of XSS attacks:
Clickjacking, also known as UI-redress attacks, try to confuse users by overlaying a malicious site on top of a benign one. The user believes to interact with the benign one while in reality they are interacting with the malicious one.
Modern browsers do not only display HTML code but are used to interface with multiple system components such as WebCams, Microphones, USB Devices, etc. While many websites do not utilize those features, attackers can abuse those.
CSRF attacks abuse an existing trust relationship between the web browser and web sites.
Implementing these browser defenses can help mitigate a range of vulnerabilities, including but not limited to:
Logging is a concept that most developers already use for debugging and diagnostic purposes. Security logging is an equally basic concept: to log security information during the runtime operation of an application. Monitoring is the live review of application and security logs using various forms of automation. The same tools and patterns can be used for operations, debugging and security purposes.
"},{"location":"the-top-10/c9-security-logging-and-monitoring/#benefits-of-security-logging","title":"Benefits of Security Logging","text":"Security logging can be used for:
Use logging to identify activity that indicates that a user is behaving maliciously. Potentially malicious activity to log includes:
Logging solutions must be built and managed in a secure way. Secure Logging design may include the following:
The following is a list of security logging implementation best practices.
For years, developers have suffered through introducing the same security issues into the things they build. The most common issues, which have existed for decades, have been documented by the OWASP Top Ten. Many of the issues in the earliest version still exist in some form today. A mechanism is needed to counter these challenges, and that mechanism is proactive controls.
Proactive controls are a catalog of better practices, a set of items developers can embrace and implement in their code bases to avoid many common security issues. Proactive controls provide positive patterns to implement solutions considered secure by design.
Imagine working on a web-based software, releasing a new version, and then getting reports that it contained a security vulnerability that is now being exploited in the wild. You are now forced to act reactively: analyzing the vulnerability, fixing it, creating a new software release, and getting it to your users. All this is tedious and a bit awkward, esp. When the security vulnerability was critical.
Proactive controls prevent this by focusing on the development itself. Their idea is to prevent common vulnerabilities during an application's inception so that those tedious and embarrassing bug fixes can be avoided altogether. Common knowledge is that a proactive approach will save resources and money in the long run.
The OWASP Top 10 Proactive Controls 2024 is a list of security techniques every software architect and developer should know and heed. The main goal 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.
Please note that while complying with best proactive practices will reduce the chance of a vulnerability being in your code, there is no guarantee that code is security-bug free. And that\u2019s okay: You have to break an egg to make an omelet \u2014 the only way of not introducing any security bugs is not to code at all. We accept that while striving to prevent as many security issues as possible.
"},{"location":"the-top-10/introduction/#how-this-list-was-created","title":"How this List Was Created","text":"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.
"},{"location":"the-top-10/introduction/#security-controls","title":"Security Controls","text":"The description of each control has the same structure. The control itself has an unique name preceded by the control number: Cx: Control Name, e.g., C1: Implement Access Control.
Each control has the same sections:
Helping with Input Validation:
diff --git a/the-top-10/c4-secure-architecture/index.html b/the-top-10/c4-secure-architecture/index.html index 5d7ce1b..10a48ab 100644 --- a/the-top-10/c4-secure-architecture/index.html +++ b/the-top-10/c4-secure-architecture/index.html @@ -1753,8 +1753,10 @@