Coders Conquer Security OWASP Top 10 API Series - Broken Object Level Authorization
Threats to cybersecurity these days are ubiquitous and relentless. It's gotten so bad that trying to keep up with them after programs are deployed has become almost impossible. However, in this age of DevSecOps, continuous delivery, and more data paydirt than ever before, shrewd organizations are helping their developers upskill into security-aware superstars that assist in eliminating common vulnerabilities before they ever make it to production. We've addressed web vulnerabilities, plus our own Top 8 Infrastructure as Code bugs, and now it's time to get acquainted with the next big software security challenge. Are you ready?
This next series of blogs will focus on some of the worst security bugs as they relate to Application Programming Interfaces (APIs). These are so bad that they made the Open Web Application Security Project (OWASP) list of top API vulnerabilities. Given how important APIs are to modern computing infrastructures, these are critical problems that you need to keep out of your applications and programs at all costs.
A perfect example of why it's essential to use code to enforce security can be found in an examination of the broken object level authorization vulnerability. This happens when programmers fail to explicitly define which users are able to view objects and data, or provide any form of verification to view, change, or make other requests to manipulate or access objects, allowing them to modify and access objects and data through API endpoints. An API endpoint is a touchpoint, often an URL, that is utilized for communication between the API itself and another system. The ability for connectivity between apps has elevated some of the world's most beloved software, but it comes at the risk of exposing multiple endpoints if they are not air-tight.
It can also occur when coders forget or inherit properties from parent classes, without realizing that doing so also leaves out a critical verification process within their code. In general, object level authorization checks should be included for every function that accesses a data source using an input from the user.
Think you're already familiar with these, and can find, fix and eliminate an access control bug right now? Play the gamified challenge:
How did you fare? If you want to work on your score, keep reading!
What are some examples of broken object level authorization vulnerabilities?
Object level access control vulnerabilities allow attackers to take actions that they should not be allowed to do. This might be an action that should be reserved for administrators, like accessing or viewing sensitive data, or destroying records. In a highly secure environment, it might even mean preventing anyone from viewing records at all unless they are specifically authorized to do so.
You should keep all possible actions in mind when defining object level authorization. For example, in Java Spring API, an endpoint with a potential issue might look like this:
public boolean deleteOrder(Long id) {
Order order = orderRepository.getOne(id);
if (order == null) {
log.info("No found order");
return false;
}
User user = order.getUser();
orderRepository.delete(order);
log.info("Delete order for user {}", user.getId());
return true;
The API endpoint deletes orders by ID, but does not verify if this order has been made by the current logged-in user. This presents an opportunity for an attacker to exploit this loophole and delete the orders of other users.
For safe access restrictions to be properly implemented, the code would look more like this:
public boolean deleteOrder(Long id) {
User user = userService.getUserByContext();
boolean orderExist = getUserOrders().stream()
.anyMatch(order -> (order.getId() == id));
if (orderExist) {
orderRepository.deleteById(id);
log.info("Delete order for user {}", user.getId());
return true;
} else {
log.info("No found order");
return false;
Eliminating broken object level authorization vulnerabilities
The access control code does not need to be overly complicated. In the case of our Java Spring API environment example, it can be fixed by tightly defining who can access objects.
First, a verification process must be implemented in order to identify who is making the request:
User user = userService.getUserByContext();
Next, we must ensure the object id exists and belongs to the user making the request:
boolean orderExist = getUserOrders().stream()
.anyMatch(order -> (order.getId() == id));
And finally, we proceed to delete the object:
orderRepository.deleteById(id);
Keep in mind that you need to ensure that the authorization method in your code aligns with your organization's user policies and data access controls. As a way to ensure that your code is fully secure, you should carry out checks to verify that users with different permission levels have access to the data they need to perform their jobs, but are prevented from viewing or changing anything that should be restricted to them. Doing so might uncover missing object control vulnerabilities that have accidentally been overlooked.
The main takeaways from these examples are to first define every action that a user could take with an object, and then add strong access controls directly to the code. And finally, never trust the inherited parent properties to do that job or to delegate that authority elsewhere. Instead, define user permissions and actions in the code explicitly for every object type that you need to protect.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.


In general, object level authorization checks should be included for every function that accesses a data source using an input from the user, and failure to do so comes at a great risk.
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.

Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoMatias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.


Threats to cybersecurity these days are ubiquitous and relentless. It's gotten so bad that trying to keep up with them after programs are deployed has become almost impossible. However, in this age of DevSecOps, continuous delivery, and more data paydirt than ever before, shrewd organizations are helping their developers upskill into security-aware superstars that assist in eliminating common vulnerabilities before they ever make it to production. We've addressed web vulnerabilities, plus our own Top 8 Infrastructure as Code bugs, and now it's time to get acquainted with the next big software security challenge. Are you ready?
This next series of blogs will focus on some of the worst security bugs as they relate to Application Programming Interfaces (APIs). These are so bad that they made the Open Web Application Security Project (OWASP) list of top API vulnerabilities. Given how important APIs are to modern computing infrastructures, these are critical problems that you need to keep out of your applications and programs at all costs.
A perfect example of why it's essential to use code to enforce security can be found in an examination of the broken object level authorization vulnerability. This happens when programmers fail to explicitly define which users are able to view objects and data, or provide any form of verification to view, change, or make other requests to manipulate or access objects, allowing them to modify and access objects and data through API endpoints. An API endpoint is a touchpoint, often an URL, that is utilized for communication between the API itself and another system. The ability for connectivity between apps has elevated some of the world's most beloved software, but it comes at the risk of exposing multiple endpoints if they are not air-tight.
It can also occur when coders forget or inherit properties from parent classes, without realizing that doing so also leaves out a critical verification process within their code. In general, object level authorization checks should be included for every function that accesses a data source using an input from the user.
Think you're already familiar with these, and can find, fix and eliminate an access control bug right now? Play the gamified challenge:
How did you fare? If you want to work on your score, keep reading!
What are some examples of broken object level authorization vulnerabilities?
Object level access control vulnerabilities allow attackers to take actions that they should not be allowed to do. This might be an action that should be reserved for administrators, like accessing or viewing sensitive data, or destroying records. In a highly secure environment, it might even mean preventing anyone from viewing records at all unless they are specifically authorized to do so.
You should keep all possible actions in mind when defining object level authorization. For example, in Java Spring API, an endpoint with a potential issue might look like this:
public boolean deleteOrder(Long id) {
Order order = orderRepository.getOne(id);
if (order == null) {
log.info("No found order");
return false;
}
User user = order.getUser();
orderRepository.delete(order);
log.info("Delete order for user {}", user.getId());
return true;
The API endpoint deletes orders by ID, but does not verify if this order has been made by the current logged-in user. This presents an opportunity for an attacker to exploit this loophole and delete the orders of other users.
For safe access restrictions to be properly implemented, the code would look more like this:
public boolean deleteOrder(Long id) {
User user = userService.getUserByContext();
boolean orderExist = getUserOrders().stream()
.anyMatch(order -> (order.getId() == id));
if (orderExist) {
orderRepository.deleteById(id);
log.info("Delete order for user {}", user.getId());
return true;
} else {
log.info("No found order");
return false;
Eliminating broken object level authorization vulnerabilities
The access control code does not need to be overly complicated. In the case of our Java Spring API environment example, it can be fixed by tightly defining who can access objects.
First, a verification process must be implemented in order to identify who is making the request:
User user = userService.getUserByContext();
Next, we must ensure the object id exists and belongs to the user making the request:
boolean orderExist = getUserOrders().stream()
.anyMatch(order -> (order.getId() == id));
And finally, we proceed to delete the object:
orderRepository.deleteById(id);
Keep in mind that you need to ensure that the authorization method in your code aligns with your organization's user policies and data access controls. As a way to ensure that your code is fully secure, you should carry out checks to verify that users with different permission levels have access to the data they need to perform their jobs, but are prevented from viewing or changing anything that should be restricted to them. Doing so might uncover missing object control vulnerabilities that have accidentally been overlooked.
The main takeaways from these examples are to first define every action that a user could take with an object, and then add strong access controls directly to the code. And finally, never trust the inherited parent properties to do that job or to delegate that authority elsewhere. Instead, define user permissions and actions in the code explicitly for every object type that you need to protect.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.

Threats to cybersecurity these days are ubiquitous and relentless. It's gotten so bad that trying to keep up with them after programs are deployed has become almost impossible. However, in this age of DevSecOps, continuous delivery, and more data paydirt than ever before, shrewd organizations are helping their developers upskill into security-aware superstars that assist in eliminating common vulnerabilities before they ever make it to production. We've addressed web vulnerabilities, plus our own Top 8 Infrastructure as Code bugs, and now it's time to get acquainted with the next big software security challenge. Are you ready?
This next series of blogs will focus on some of the worst security bugs as they relate to Application Programming Interfaces (APIs). These are so bad that they made the Open Web Application Security Project (OWASP) list of top API vulnerabilities. Given how important APIs are to modern computing infrastructures, these are critical problems that you need to keep out of your applications and programs at all costs.
A perfect example of why it's essential to use code to enforce security can be found in an examination of the broken object level authorization vulnerability. This happens when programmers fail to explicitly define which users are able to view objects and data, or provide any form of verification to view, change, or make other requests to manipulate or access objects, allowing them to modify and access objects and data through API endpoints. An API endpoint is a touchpoint, often an URL, that is utilized for communication between the API itself and another system. The ability for connectivity between apps has elevated some of the world's most beloved software, but it comes at the risk of exposing multiple endpoints if they are not air-tight.
It can also occur when coders forget or inherit properties from parent classes, without realizing that doing so also leaves out a critical verification process within their code. In general, object level authorization checks should be included for every function that accesses a data source using an input from the user.
Think you're already familiar with these, and can find, fix and eliminate an access control bug right now? Play the gamified challenge:
How did you fare? If you want to work on your score, keep reading!
What are some examples of broken object level authorization vulnerabilities?
Object level access control vulnerabilities allow attackers to take actions that they should not be allowed to do. This might be an action that should be reserved for administrators, like accessing or viewing sensitive data, or destroying records. In a highly secure environment, it might even mean preventing anyone from viewing records at all unless they are specifically authorized to do so.
You should keep all possible actions in mind when defining object level authorization. For example, in Java Spring API, an endpoint with a potential issue might look like this:
public boolean deleteOrder(Long id) {
Order order = orderRepository.getOne(id);
if (order == null) {
log.info("No found order");
return false;
}
User user = order.getUser();
orderRepository.delete(order);
log.info("Delete order for user {}", user.getId());
return true;
The API endpoint deletes orders by ID, but does not verify if this order has been made by the current logged-in user. This presents an opportunity for an attacker to exploit this loophole and delete the orders of other users.
For safe access restrictions to be properly implemented, the code would look more like this:
public boolean deleteOrder(Long id) {
User user = userService.getUserByContext();
boolean orderExist = getUserOrders().stream()
.anyMatch(order -> (order.getId() == id));
if (orderExist) {
orderRepository.deleteById(id);
log.info("Delete order for user {}", user.getId());
return true;
} else {
log.info("No found order");
return false;
Eliminating broken object level authorization vulnerabilities
The access control code does not need to be overly complicated. In the case of our Java Spring API environment example, it can be fixed by tightly defining who can access objects.
First, a verification process must be implemented in order to identify who is making the request:
User user = userService.getUserByContext();
Next, we must ensure the object id exists and belongs to the user making the request:
boolean orderExist = getUserOrders().stream()
.anyMatch(order -> (order.getId() == id));
And finally, we proceed to delete the object:
orderRepository.deleteById(id);
Keep in mind that you need to ensure that the authorization method in your code aligns with your organization's user policies and data access controls. As a way to ensure that your code is fully secure, you should carry out checks to verify that users with different permission levels have access to the data they need to perform their jobs, but are prevented from viewing or changing anything that should be restricted to them. Doing so might uncover missing object control vulnerabilities that have accidentally been overlooked.
The main takeaways from these examples are to first define every action that a user could take with an object, and then add strong access controls directly to the code. And finally, never trust the inherited parent properties to do that job or to delegate that authority elsewhere. Instead, define user permissions and actions in the code explicitly for every object type that you need to protect.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.

Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demoMatias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
Threats to cybersecurity these days are ubiquitous and relentless. It's gotten so bad that trying to keep up with them after programs are deployed has become almost impossible. However, in this age of DevSecOps, continuous delivery, and more data paydirt than ever before, shrewd organizations are helping their developers upskill into security-aware superstars that assist in eliminating common vulnerabilities before they ever make it to production. We've addressed web vulnerabilities, plus our own Top 8 Infrastructure as Code bugs, and now it's time to get acquainted with the next big software security challenge. Are you ready?
This next series of blogs will focus on some of the worst security bugs as they relate to Application Programming Interfaces (APIs). These are so bad that they made the Open Web Application Security Project (OWASP) list of top API vulnerabilities. Given how important APIs are to modern computing infrastructures, these are critical problems that you need to keep out of your applications and programs at all costs.
A perfect example of why it's essential to use code to enforce security can be found in an examination of the broken object level authorization vulnerability. This happens when programmers fail to explicitly define which users are able to view objects and data, or provide any form of verification to view, change, or make other requests to manipulate or access objects, allowing them to modify and access objects and data through API endpoints. An API endpoint is a touchpoint, often an URL, that is utilized for communication between the API itself and another system. The ability for connectivity between apps has elevated some of the world's most beloved software, but it comes at the risk of exposing multiple endpoints if they are not air-tight.
It can also occur when coders forget or inherit properties from parent classes, without realizing that doing so also leaves out a critical verification process within their code. In general, object level authorization checks should be included for every function that accesses a data source using an input from the user.
Think you're already familiar with these, and can find, fix and eliminate an access control bug right now? Play the gamified challenge:
How did you fare? If you want to work on your score, keep reading!
What are some examples of broken object level authorization vulnerabilities?
Object level access control vulnerabilities allow attackers to take actions that they should not be allowed to do. This might be an action that should be reserved for administrators, like accessing or viewing sensitive data, or destroying records. In a highly secure environment, it might even mean preventing anyone from viewing records at all unless they are specifically authorized to do so.
You should keep all possible actions in mind when defining object level authorization. For example, in Java Spring API, an endpoint with a potential issue might look like this:
public boolean deleteOrder(Long id) {
Order order = orderRepository.getOne(id);
if (order == null) {
log.info("No found order");
return false;
}
User user = order.getUser();
orderRepository.delete(order);
log.info("Delete order for user {}", user.getId());
return true;
The API endpoint deletes orders by ID, but does not verify if this order has been made by the current logged-in user. This presents an opportunity for an attacker to exploit this loophole and delete the orders of other users.
For safe access restrictions to be properly implemented, the code would look more like this:
public boolean deleteOrder(Long id) {
User user = userService.getUserByContext();
boolean orderExist = getUserOrders().stream()
.anyMatch(order -> (order.getId() == id));
if (orderExist) {
orderRepository.deleteById(id);
log.info("Delete order for user {}", user.getId());
return true;
} else {
log.info("No found order");
return false;
Eliminating broken object level authorization vulnerabilities
The access control code does not need to be overly complicated. In the case of our Java Spring API environment example, it can be fixed by tightly defining who can access objects.
First, a verification process must be implemented in order to identify who is making the request:
User user = userService.getUserByContext();
Next, we must ensure the object id exists and belongs to the user making the request:
boolean orderExist = getUserOrders().stream()
.anyMatch(order -> (order.getId() == id));
And finally, we proceed to delete the object:
orderRepository.deleteById(id);
Keep in mind that you need to ensure that the authorization method in your code aligns with your organization's user policies and data access controls. As a way to ensure that your code is fully secure, you should carry out checks to verify that users with different permission levels have access to the data they need to perform their jobs, but are prevented from viewing or changing anything that should be restricted to them. Doing so might uncover missing object control vulnerabilities that have accidentally been overlooked.
The main takeaways from these examples are to first define every action that a user could take with an object, and then add strong access controls directly to the code. And finally, never trust the inherited parent properties to do that job or to delegate that authority elsewhere. Instead, define user permissions and actions in the code explicitly for every object type that you need to protect.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.
Table of contents
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.

Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Secure by Design: Defining Best Practices, Enabling Developers and Benchmarking Preventative Security Outcomes
In this research paper, Secure Code Warrior co-founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., along with expert contributors, Chris Inglis, Former US National Cyber Director (now Strategic Advisor to Paladin Capital Group), and Devin Lynch, Senior Director, Paladin Global Institute, will reveal key findings from over twenty in-depth interviews with enterprise security leaders including CISOs, a VP of Application Security, and software security professionals.
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
Finding meaningful data on the success of Secure-by-Design initiatives is notoriously difficult. CISOs are often challenged when attempting to prove the return on investment (ROI) and business value of security program activities at both the people and company levels. Not to mention, it’s particularly difficult for enterprises to gain insights into how their organizations are benchmarked against current industry standards. The President’s National Cybersecurity Strategy challenged stakeholders to “embrace security and resilience by design.” The key to making Secure-by-Design initiatives work is not only giving developers the skills to ensure secure code, but also assuring the regulators that those skills are in place. In this presentation, we share a myriad of qualitative and quantitative data, derived from multiple primary sources, including internal data points collected from over 250,000 developers, data-driven customer insights, and public studies. Leveraging this aggregation of data points, we aim to communicate a vision of the current state of Secure-by-Design initiatives across multiple verticals. The report details why this space is currently underutilized, the significant impact a successful upskilling program can have on cybersecurity risk mitigation, and the potential to eliminate categories of vulnerabilities from a codebase.
Secure code training topics & content
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peak of what our content catalog has to offer by topic and role.
Resources to get you started
Revealed: How the Cyber Industry Defines Secure by Design
In our latest white paper, our Co-Founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., sat down with over twenty enterprise security leaders, including CISOs, AppSec leaders and security professionals, to figure out the key pieces of this puzzle and uncover the reality behind the Secure by Design movement. It’s a shared ambition across the security teams, but no shared playbook.
Is Vibe Coding Going to Turn Your Codebase Into a Frat Party?
Vibe coding is like a college frat party, and AI is the centerpiece of all the festivities, the keg. It’s a lot of fun to let loose, get creative, and see where your imagination can take you, but after a few keg stands, drinking (or, using AI) in moderation is undoubtedly the safer long-term solution.