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
Category:OWASP Source Code Flaws Top 10 Project Index
From OWASP
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 container of memory, disk space and cpu time. Well, it isn't. You must also consider that poorly designed local resource utilization, can lead an application to have poor response time and than it can lead to a denial of service if an attacker will try to consume all the resources. |
| C8 - Usage of potentially dangerous APIs | Frameworks and libraries evolve in order to solve security issues. Often they leave backward compatibility routines in order to let developers enough time to change their code. More often developers simply forget to change their code using the potentially dangerous APIs even if deprecated.
All the potentially dangerous routine calls fit this category |
| C9 - Documentation weakness | Source code must be documented in order to maintainable. If your code is not well commented, may be you won't be able to understand what did you write month ago, maybe you misunderstood your business logic flow then introducing some bugs or maybe you could not understand one of your colleague's work.
Missing or not well documented code hit this flaw category. |
| C10 - Best practices violation | This is the category that fits all generic best practices in source code development that are violated by the code. In this category it falls all the things that did not match any of the previous categories. |
This category currently contains no pages or media.
