OWASP Proactive Controls OWASP Foundation

One example of a failure involves using untrusted software in a build pipeline to generate a software release. Another example is insecure deserialization, where an application receives an object from another entity and does not properly validate that object, resulting in an attack being loosed upon the application that received the object. 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, webservice, 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.

It is impractical to track and tag whether a string in a database was tainted or not. Instead, you build proper controls in the presentation layer, such as the browser, to escape any data provided to it. This cheatsheet will help users of the owasp proactive controls identify which cheatsheets map to each proactive controls item. No matter how many layers of validation data goes through, it should always be escaped/encoded for the right context. This concept is not only relevant for Cross-Site Scripting (XSS) vulnerabilities and the different HTML contexts, it also applies to any context where data and control planes are mixed. Database injections are probably one of the best-known security vulnerabilities, and many injection vulnerabilities are reported every year.

Link to the OWASP Top 10 Project¶

Test cases should be created to confirm the existence of the new functionality or disprove the existence of a previously insecure option. When the story is focused on the attacker and their actions, it is referred to as a misuse case. Always treat data as untrusted, since it can originate from different sources which you may not always have insights into. Recently, I was thinking back at a great opening session of DevSecCon community we had last year, featuring no other than Jim Manico. Use the extensive project presentation that expands on the information in the document.

For any of these decisions, you have the ability to roll your own–managing your own registration of users and keeping track of their passwords or means of authentication. As an alternative, you can choose to managed services and benefit from the cloud’s Serverless architecture of services like Auth0. Databases are often key components for building rich web applications as the need for state and persistency arises.

C1: Define Security Requirements

Threat modeling analyzes a system representation to mitigate security and privacy issues early in the life cycle. Secure design patterns and reference architectures provide a positive, secure pattern that developers can use to build new features. Many future vulnerabilities can be prevented by thinking about and designing for security earlier in the software development life cycle (SDLC).

Building a secure product begins with defining what are the security requirements we need to take into account. Just as business requirements help us shape the product, security requirements help us take into account security from the get-go. First, security vulnerabilities continue to evolve and a top 10 list simply can’t offer a comprehensive understanding of all the problems that can affect your software.