OWASP Vulnerability #7 – Missing Function Level Access Control

Rear view of young man typing and looking at computer monitor while sitting at the table in dark room

The next vulnerability to look at from the OWASP Top 10 List of Web Vulnerabilities is #7, Missing Function Level Access Control.  This vulnerability is easy to understand, but is important to acknowledge because of its abundance in web applications.  At Clearent, we have always paid close attention to function level access control because it is a critical element of the reporting and administration of our payments platform.

Applications that have missing function level access control allow an end user to simply enter a given URL or manually call a function that shouldn’t be exposed to them in order to access data or functionality that has not been explicitly assigned.  Sometimes this vulnerability is manifested by data or application navigation becoming exposed to a user that shouldn’t see it, but more often it is manifested by not performing a security check on individual function calls.  One of the easiest ways to test for this vulnerability is to log into an application as a user with restricted privileges, then type in the URL of a resource that requires more privilege, and see what happens.  If the restricted resource is brought up, the application has this vulnerability.  If not, the application is most likely doing the right things.

The Solution

The solution for missing function level access control is to have individual functions and resources in an application check the privileges granted to the requesting user and then only fulfill requests for users that have explicitly granted permission.  Many applications use components external to the application code to verify privileges.  Depending on the component, application code may be annotated to secure individual function calls.  If an application is susceptible to this flaw, it is important to understand all of the access points and to address them, starting with the most critical functions.

Compass is the web-visible entry point to our payments platform.  When we built the administration and reporting functions of Compass, we wanted to control access across two dimensions: features assigned to users and position in our business hierarchy.  Compass uses traditional application features to enable or disable functionality within the application for users.  This is currently handled with a homegrown system and would be familiar to most developers.  Additionally, we track and maintain a hierarchy that allows us to define arbitrary reporting structures for our partners, allowing for very flexible reporting and data access.  The hierarchy is used to ensure that a user only gets data that he or she is supposed to have.  The use of application features and a hierarchical data structure allows us to secure individual functions.

Many developers view the OWASP vulnerabilities as things they need to address to pass an audit.  At Clearent, we embraced securing individual functions early on in Compass in order to create a unique and flexible payments platform that has grown with us over time.