The security superstar Brian Krebs released today details on an USPS vulnerability that exposed millions of accounts without proper authorization control (Broken Access Control). The leak has been already plugged; but only when Krebs himself reached out to USPS, after the company had ignored the warnings of of an anonymous security researcher that notified USPS one year ago –this alone could justify another blog post!
The USPS API information leak incident
The security weaknesses leaked account data for around 60 million users. Any malicious user logged in the system could exploit the API to collect user data by simply introducing wildcard characters in a search function of the API.
Essentially, the root cause of the USPS incident is having insufficient authorization controls, which in turn allow attackers to retrieve (and modify) data beyond their lawful control.
OWASP recognizes the importance of this security aspect in its Top 10, in the A5:2017 Broken Access Control risk specifically, which resulted from merging the previous A4:2013 and A7:2013 risks. In their own words:
“Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside of the limits of the user. “ 
Automating Access Control
Let’s look at the reasons why this risk continues to be a key attack vector and why it is important to us at Hdiv.
1. Traditional Application Security vendors are focused on syntax bugs
We like to separate the universe of security issues into two different groups. First, syntax issues, which follow a regular pattern in the source code that can be detected by AST tools. Traditional security vendors focus on this type of issues. And second, design flaws. which do not follow a pattern and can’t be detected by tools. Design flaws are also known as business logic security flaws. Issues like this are insufficient access control, data tampering, binding attacks etc.
“Exploitation of access control is a core skill of attackers. SAST and DAST tools can detect the absence of access control but cannot verify if it is functional when it is present.“ 
App Sec vendors normally deem this class of defects to be 100% responsibility of the developers. Which takes us to the next point:
2. Reliance on manual checks by developers
Due to the lack of proper protection from insufficient authentication, developers implement manual checks. For each app feature, the developer checks whether the user is allowed to perform this action on this piece of data. Of course, when the human factor is involved, there is plenty of room for mistakes such as the USPS bug.
3. Automatic domain (instance level) authorization
Some attempts at automating authorization, such as Spring Security Domain Object Security (ACLs) have turned out to be very difficult to apply, and often causing performance issues.
Hdiv Protection (RASP) implements automatic enforcement of the domain contract. This contract controls the flow of all the data generated at server side, ensuring its integrity. In short, it ensures automatically and efficiently that users can only modify records they own.
At Hdiv we are on the developers’ side, and we want to make their lives easier. That is why since the beginning we have been building security components that focus on the automation of this security aspect.