Category:OWASP Enterprise Security API

Revision as of 08:36, 20 August 2007 by Jeff Williams (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

OWASP Enterprise Security API (ESAPI) Project

Many organizations share similar security concerns and require a similar set of security controls to address these concerns. Many platforms, frameworks, and toolkits contain security mechanisms, but they are frequently complex and require security expertise to use correctly. The purpose of the ESAPI is to provide a simple interface that provides all the ordinary security functions a developer is likely to need in a clear, consistent, and easy to use way.

We hope that organizations will adopt the ESAPI and build their applications to use it. While we will provide a reference implementation of the ESAPI, we expect that most organizations will modify and extend this implementation to suit their own internal security mechanisms. For example, the access control functions may be modified to use a set of roles determined by an existing network access control system. Or the logging function may be implemented as a wrapper of an existing logging infrastructure.

By using the ESAPI, applications across an organization will be easier to develop, more consistent, and easier to update in a single place. The use of the ESAPI will make it much easier for static analysis tools to verify an application, as the ESAPI calls can be built into the ruleset.

ESAPI Design Principles

- Easy to retrofit to existing applications - Easy to extend and customize - Dead simple to understand and use with confidence - Based on use cases - Full test case suite - Must support organizations with no other security infrastructure - Absolute emphasis on correctness over performance - Focus on the most risky areas, and leave out less important areas for simplicity

EASIAPI Design Choices

- Interfaces with concrete reference implementation - The interface only contains the public methods a developer would be expected to call - Avoid confusing "pluggable" implementations - Simple singleton approach with many non-static methods - Threadsafe