Category:OWASP Source Code Flaws Top 10 Project Index
From OWASP
Revision as of 11:29, 15 December 2008 by Thesp0nge (talk | contribs) (→The OWASP Source Code Flaws Top 10)
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 | A |
| C6 - Direct object reference | A |
| C7 - Misuse of local resources | A |
| C8 - Usage of potentially dangerous APIs | A |
| C9 - Documentation weakness | A |
| C10 - Best practices violation | A |
This category currently contains no pages or media.
