|
|
Line 9: |
Line 9: |
| ==OWASP API Security Project== | | ==OWASP API Security Project== |
| | | |
− | <!-- Instructions are in RED and should be removed from your document by deleting the text with the span tags.-->
| + | In today's increasingly programmatic world, many organizations employ public and private APIs. These APIs may be used for internal activities, or to interface with third parties. Unfortunately, many APIs do not undergo the rigorous security testing that would render them secure from attack. |
− | <span style="color:#ff0000">
| |
− | This is where you need to add your more robust project description. A project description should outline the purpose of the project, and the value it provides to application security. Ideally, project descriptions should be written in such a way that there is no question what value the project provides to the software security community. This section will be seen and used in various places within the Projects Portal. Poorly written project descriptions therefore detract from a project’s visibility, and project leaders should ensure that the description is meaningful.
| |
− | </span>
| |
| | | |
− | Inevitably applications are designed with security principles architects knew about, security folks included. However, as this project demonstrates there are far more than just a 'few' principles, most of which never make it into the design.
| + | The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a '''Top 10 API Security Risks''' document, as well as a documentation portal for best practices. |
− | | |
− | For example, security design happens with perhaps a handful of principles:
| |
− | | |
− | * Least Privilege
| |
− | * Perimeter Security
| |
− | * Defence in Depth
| |
− | | |
− | However, we regularly see designs without '''separation of privilege'''!
| |
− | | |
− | Think about that, most web applications today have all their eggs in a single basket. The business logic, the identities, passwords, products, policy enforcement, security rules are all found in the same application database that makes up the typical website! It is little wonder then, that attacks on the database have been so completely devastating, since there is no separation of privilege!
| |
− | | |
− | The aim of this project, is to identify and describe a minimum functional set of principles that must be present in a secure design.
| |
| | | |
| ==Description== | | ==Description== |