Jim Bird

About Jim Bird

Jim is an experienced CTO, software development manager and project manager, who has worked on high-performance, high-reliability mission-critical systems for many years, as well as building software development tools. His current interests include scaling Lean and Agile software development methodologies, software security and software assurance.

10 things you can do to make your app secure: #4 Access Control

This is #4 in a series on the OWASP Top 10 Proactive Controls: 10 things that developers can do to make sure that their app is secure.

Access Control aka Authorization, deciding who needs what access to which data and to which features, and how these rules will be enforced, needs to be carefully thought through up front in design. It’s difficult to retrofit access control later without making mistakes. Come up with a pattern early, and make sure that it is applied consistently. And make sure to follow these simple rules:
 
 
 

Deny by Default

In many apps, the default behaviour is to allow access to features and to data or other resources unless an access control check is added, and the check fails. Take a few seconds and think about what could go wrong with this approach. If it’s not obvious, go to OWASP’s Top 10 list of the most serious application vulnerabilities #7: Missing Function-Level Access Control. Then make sure to only permit access to a function if an authorization check passes.

What’s your Access Control Policy anyway?

Access checks – even checks that are done properly, using a positive access approach, are often sprinkled throughout application code, looking something like this:

if (user.isManager() || user.isAdministrator() || user.isEditor() || user.isUser()) { //execute action }

The problem with this approach is that it’s really hard to review your access control rules and make sure that they are correct, and it’s hard to make changes because you can’t be sure that you found all of the checks and changed them correctly.

Instead of embedding access control rules based on the user-id or role inside application logic, centralize access control rules in a data-driven authorization service which maps users against roles or other authorization schemes, and provide a simple API to this service that the application code can call. Much easier to audit, much more extensible and maintainable.

If this isn’t already available in the application framework that you are using, look for a good security library to do the job. Apache Shiro offers an easy and flexible access control framework which you can use to implement these ideas. OWASP’s ESAPI also has a framework to enforce fine-grained access control rules at function, service, URL, data, and file levels.

Don’t trust – verify

Back again to the issue of trusting data. Never use client-side data or other untrusted data in access control decisions. Only use trusted server-side data.

For more on Access Control patterns and anti-patterns and common problems in implementing Access Controls properly, please read OWASP’s Access Control Cheat Sheet.

Access Control is closely tied to Authentication – in fact, some people mix these ideas up entirely. So let’s look at key issues in implementing Authentication next.

Related Whitepaper:

Web Application Security; How to Minimize Prevalent Risk of Attacks

Vulnerabilities in web applications are now the largest vector of enterprise security attacks.

Stories about exploits that compromise sensitive data frequently mention culprits such as cross-site scripting, SQL injection, and buffer overflow. Vulnerabilities like these fall often outside the traditional expertise of network security managers.

Get it Now!  

One Response to "10 things you can do to make your app secure: #4 Access Control"

  1. Model Cars says:

    wonderful issues altogether, you simply received a new reader.
    What might you suggest in regards to your post that you made a few days in the past?
    Any sure?

Leave a Reply


× 9 = fifty four



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books