This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Category:OWASP Source Code Flaws Top 10 Project Index"
From OWASP
(→The OWASP Source Code Flaws Top 10) |
(→The OWASP Source Code Flaws Top 10) |
||
| Line 21: | Line 21: | ||
|[[Source_Code_Flaws_Top_10_2009-C5|C5 - Information leakage and improper error handling]] | |[[Source_Code_Flaws_Top_10_2009-C5|C5 - Information leakage and improper error handling]] | ||
| − | | | + | |Actually it is the same as the one listed in the original Top 10 just seen from a source code point of view. Every missing exception handling or a too verbose logging string in example, must be stored in this flaw category. |
|- | |- | ||
|[[Source_Code_Flaws_Top_10_2009-C6|C6 - Direct object reference]] | |[[Source_Code_Flaws_Top_10_2009-C6|C6 - Direct object reference]] | ||
| − | | | + | |Actually is the same as the one listed in the original Top 10 just seen from a source code point of view. |
|- | |- | ||
|[[Source_Code_Flaws_Top_10_2009-C7|C7 - Misuse of local resources]] | |[[Source_Code_Flaws_Top_10_2009-C7|C7 - Misuse of local resources]] | ||
| − | | | + | |Often people pretends that operating system provided resources are an infinite |
|- | |- | ||
Revision as of 11:54, 15 December 2008
The OWASP Source Code Flaws Top 10
| C1 - Design Weakness | A design weakness occurs when your business logic isn't strong enough to a threat modeling activity so it may be easy for an attacker to subvert your application behavior. Design is also about objects scope and visibility so extra care must be taken to what your program expose to others. |
| C2 - Architectural Weakness | Your application at runtime is not a standalone part of the entire world, it depends over auxiliary system. An architectural weakness occurs when your code interact in a non safe way to auxiliary systems. |
| C3 - Missing input validation | Actually, when a source code has been developed no defensive programming is used. Although defensive programming doesn't mean to provide always a secure code, it is a good idea not taking the user input and using it without any form of filtering or validation routine.
Often the usage of not sanitized input can lead to very dangerous runtime vulnerabilities such as cross Site scripting, injection flaws, and others. |
| C4 - Insecure communications | Web applications use TCP/IP stack to communicate to the world, no magic in this. An insecure communication vulnerability seen from the source code point of you is about how operating system provided abstraction layer (sockets, ...), communication layer provided by framework (java sockets, ...) are used. This is more than just checking about SSL usage, this is about how the communication code is written. |
| C5 - Information leakage and improper error handling | Actually it is the same as the one listed in the original Top 10 just seen from a source code point of view. Every missing exception handling or a too verbose logging string in example, must be stored in this flaw category. |
| C6 - Direct object reference | Actually is the same as the one listed in the original Top 10 just seen from a source code point of view. |
| C7 - Misuse of local resources | Often people pretends that operating system provided resources are an infinite |
| C8 - Usage of potentially dangerous APIs | A |
| C9 - Documentation weakness | A |
| C10 - Best practices violation | A |
This category currently contains no pages or media.
