Coders Conquer Security: Share & Learn Series: Insecure Direct Object Reference
URLs are essential to navigating all the websites and web applications we know and love. Their basic function is to identify where resources are and how to retrieve them. While URLs are necessary for the World Wide Web to work, they can also pose a security risk if not secured properly.
In this post, we will learn:
- What IDOR is and how attackers use IDOR
- Why IDOR is dangerous
- Techniques that can fix this vulnerability
Understand IDOR
A direct object reference is when a specific record (the "object"), is referenced within an application. It usually takes the form of a unique identifier and may appear in a URL.
For instance, you might notice something like "?id=12345" at the end of a URL. The number, 12345, is a reference to a specific record. Security vulnerabilities creep in when access control is not present for individual records. This allows users to access records and data they shouldn't see. This is an attack that requires a relatively low skill level.
In this instance, let's say an attacker changes the ID in the URL to 12344. In an application that is vulnerable to IDOR, the attacker would be able to see the data pertaining to that record.
How much damage can this type of vulnerability really cause?
Know Why IDOR is Dangerous
When developers are not careful, they can design a system that displays and leaks application records in various places. A breach of this magnitude can be significant, especially when sensitive data or PII are involved.
The Australian Tax Office set up a website to help businesses collect a new tax. Unfortunately, it came packaged with the unwanted feature of an IDOR vulnerability. An inquisitive user realized that the URLs within the site contained his Australian Business Number, or ABN. It just so happens that this is an easily discoverable number for any registered business. This user decided to put the numbers of other companies into the URL. He was gifted with their bank account information and personal details!
Apple recently fell victim to an IDOR vulnerability. When the iPad was first released, 114,000 customer email addresses were leaked. (To be fair, it was more a mistake on AT&T's part).
You see, AT&T built a service to support 3G connectivity for iPads. The iPad sent an identifier stored on the SIM card to AT&T's service. The service then returned the user's email address.
Unfortunately, these identifiers were simply sequential integers and thus were easily guessable. Attackers iterated through the identifiers and stole the email addresses.
Another mistake was that AT&T's service tried to "secure" the service by only returning the email address if the request's user-agent header indicated that it came from an iPad. The user-agent is only a string value that can be easily manipulated.
IDOR vulnerabilities can be subtle and sneaky. Let's discuss how to defeat them.
Defeating IDOR
Access control is the key to solving IDOR. When a user requests a specific record, make sure they are authorized to view the requested record.
Using centralized authorization modules is the best way to do this. Tools such as Spring Security provide robust and customizable authentication and authorization for applications.
Bottom line: have one module that all other code relies upon to perform authorization checks.
Another common mitigation is the use of surrogate references. Instead of using the actual database record identifiers in your URLs, you can create random numbers that map back to the actual records.
Using surrogate references ensures that an attacker cannot get to a record just by guessing the next valid identifier.
And finally, don't rely on anything that the user can manipulate to provide authorization. AT&T tried to use the user-agent header to authorize their service. Don't rely on HTTP headers, cookies, or GET and POST parameters.
With these mitigations in place, IDOR will be a thing of the past.
Secure Your References
Insecure Direct Object References are one of the easiest vulnerabilities to exploit. Don't let them sneak up on you when you least expect it. Always check that users are authorized. Don't use real database identifiers. Don't depend on user-controlled data for authorization.
Build your mastery by checking out our Learning Resources. By practicing how to mitigate IDOR vulnerabilities in the language of your choice, you'll have no problem finding and fixing this problem in your production codebases. You can also put your newfound defensive knowledge to the test with a free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.
Ready to defend against IDOR attacks right now? Head to the platform and challenge yourself for free: [Start Here]
A direct object reference is when a specific record (the 'object'), is referenced within an application. It usually takes the form of a unique identifier and may appear in a URL.
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
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 demo
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
URLs are essential to navigating all the websites and web applications we know and love. Their basic function is to identify where resources are and how to retrieve them. While URLs are necessary for the World Wide Web to work, they can also pose a security risk if not secured properly.
In this post, we will learn:
- What IDOR is and how attackers use IDOR
- Why IDOR is dangerous
- Techniques that can fix this vulnerability
Understand IDOR
A direct object reference is when a specific record (the "object"), is referenced within an application. It usually takes the form of a unique identifier and may appear in a URL.
For instance, you might notice something like "?id=12345" at the end of a URL. The number, 12345, is a reference to a specific record. Security vulnerabilities creep in when access control is not present for individual records. This allows users to access records and data they shouldn't see. This is an attack that requires a relatively low skill level.
In this instance, let's say an attacker changes the ID in the URL to 12344. In an application that is vulnerable to IDOR, the attacker would be able to see the data pertaining to that record.
How much damage can this type of vulnerability really cause?
Know Why IDOR is Dangerous
When developers are not careful, they can design a system that displays and leaks application records in various places. A breach of this magnitude can be significant, especially when sensitive data or PII are involved.
The Australian Tax Office set up a website to help businesses collect a new tax. Unfortunately, it came packaged with the unwanted feature of an IDOR vulnerability. An inquisitive user realized that the URLs within the site contained his Australian Business Number, or ABN. It just so happens that this is an easily discoverable number for any registered business. This user decided to put the numbers of other companies into the URL. He was gifted with their bank account information and personal details!
Apple recently fell victim to an IDOR vulnerability. When the iPad was first released, 114,000 customer email addresses were leaked. (To be fair, it was more a mistake on AT&T's part).
You see, AT&T built a service to support 3G connectivity for iPads. The iPad sent an identifier stored on the SIM card to AT&T's service. The service then returned the user's email address.
Unfortunately, these identifiers were simply sequential integers and thus were easily guessable. Attackers iterated through the identifiers and stole the email addresses.
Another mistake was that AT&T's service tried to "secure" the service by only returning the email address if the request's user-agent header indicated that it came from an iPad. The user-agent is only a string value that can be easily manipulated.
IDOR vulnerabilities can be subtle and sneaky. Let's discuss how to defeat them.
Defeating IDOR
Access control is the key to solving IDOR. When a user requests a specific record, make sure they are authorized to view the requested record.
Using centralized authorization modules is the best way to do this. Tools such as Spring Security provide robust and customizable authentication and authorization for applications.
Bottom line: have one module that all other code relies upon to perform authorization checks.
Another common mitigation is the use of surrogate references. Instead of using the actual database record identifiers in your URLs, you can create random numbers that map back to the actual records.
Using surrogate references ensures that an attacker cannot get to a record just by guessing the next valid identifier.
And finally, don't rely on anything that the user can manipulate to provide authorization. AT&T tried to use the user-agent header to authorize their service. Don't rely on HTTP headers, cookies, or GET and POST parameters.
With these mitigations in place, IDOR will be a thing of the past.
Secure Your References
Insecure Direct Object References are one of the easiest vulnerabilities to exploit. Don't let them sneak up on you when you least expect it. Always check that users are authorized. Don't use real database identifiers. Don't depend on user-controlled data for authorization.
Build your mastery by checking out our Learning Resources. By practicing how to mitigate IDOR vulnerabilities in the language of your choice, you'll have no problem finding and fixing this problem in your production codebases. You can also put your newfound defensive knowledge to the test with a free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.
Ready to defend against IDOR attacks right now? Head to the platform and challenge yourself for free: [Start Here]
URLs are essential to navigating all the websites and web applications we know and love. Their basic function is to identify where resources are and how to retrieve them. While URLs are necessary for the World Wide Web to work, they can also pose a security risk if not secured properly.
In this post, we will learn:
- What IDOR is and how attackers use IDOR
- Why IDOR is dangerous
- Techniques that can fix this vulnerability
Understand IDOR
A direct object reference is when a specific record (the "object"), is referenced within an application. It usually takes the form of a unique identifier and may appear in a URL.
For instance, you might notice something like "?id=12345" at the end of a URL. The number, 12345, is a reference to a specific record. Security vulnerabilities creep in when access control is not present for individual records. This allows users to access records and data they shouldn't see. This is an attack that requires a relatively low skill level.
In this instance, let's say an attacker changes the ID in the URL to 12344. In an application that is vulnerable to IDOR, the attacker would be able to see the data pertaining to that record.
How much damage can this type of vulnerability really cause?
Know Why IDOR is Dangerous
When developers are not careful, they can design a system that displays and leaks application records in various places. A breach of this magnitude can be significant, especially when sensitive data or PII are involved.
The Australian Tax Office set up a website to help businesses collect a new tax. Unfortunately, it came packaged with the unwanted feature of an IDOR vulnerability. An inquisitive user realized that the URLs within the site contained his Australian Business Number, or ABN. It just so happens that this is an easily discoverable number for any registered business. This user decided to put the numbers of other companies into the URL. He was gifted with their bank account information and personal details!
Apple recently fell victim to an IDOR vulnerability. When the iPad was first released, 114,000 customer email addresses were leaked. (To be fair, it was more a mistake on AT&T's part).
You see, AT&T built a service to support 3G connectivity for iPads. The iPad sent an identifier stored on the SIM card to AT&T's service. The service then returned the user's email address.
Unfortunately, these identifiers were simply sequential integers and thus were easily guessable. Attackers iterated through the identifiers and stole the email addresses.
Another mistake was that AT&T's service tried to "secure" the service by only returning the email address if the request's user-agent header indicated that it came from an iPad. The user-agent is only a string value that can be easily manipulated.
IDOR vulnerabilities can be subtle and sneaky. Let's discuss how to defeat them.
Defeating IDOR
Access control is the key to solving IDOR. When a user requests a specific record, make sure they are authorized to view the requested record.
Using centralized authorization modules is the best way to do this. Tools such as Spring Security provide robust and customizable authentication and authorization for applications.
Bottom line: have one module that all other code relies upon to perform authorization checks.
Another common mitigation is the use of surrogate references. Instead of using the actual database record identifiers in your URLs, you can create random numbers that map back to the actual records.
Using surrogate references ensures that an attacker cannot get to a record just by guessing the next valid identifier.
And finally, don't rely on anything that the user can manipulate to provide authorization. AT&T tried to use the user-agent header to authorize their service. Don't rely on HTTP headers, cookies, or GET and POST parameters.
With these mitigations in place, IDOR will be a thing of the past.
Secure Your References
Insecure Direct Object References are one of the easiest vulnerabilities to exploit. Don't let them sneak up on you when you least expect it. Always check that users are authorized. Don't use real database identifiers. Don't depend on user-controlled data for authorization.
Build your mastery by checking out our Learning Resources. By practicing how to mitigate IDOR vulnerabilities in the language of your choice, you'll have no problem finding and fixing this problem in your production codebases. You can also put your newfound defensive knowledge to the test with a free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.
Ready to defend against IDOR attacks right now? Head to the platform and challenge yourself for free: [Start Here]
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 demo
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
URLs are essential to navigating all the websites and web applications we know and love. Their basic function is to identify where resources are and how to retrieve them. While URLs are necessary for the World Wide Web to work, they can also pose a security risk if not secured properly.
In this post, we will learn:
- What IDOR is and how attackers use IDOR
- Why IDOR is dangerous
- Techniques that can fix this vulnerability
Understand IDOR
A direct object reference is when a specific record (the "object"), is referenced within an application. It usually takes the form of a unique identifier and may appear in a URL.
For instance, you might notice something like "?id=12345" at the end of a URL. The number, 12345, is a reference to a specific record. Security vulnerabilities creep in when access control is not present for individual records. This allows users to access records and data they shouldn't see. This is an attack that requires a relatively low skill level.
In this instance, let's say an attacker changes the ID in the URL to 12344. In an application that is vulnerable to IDOR, the attacker would be able to see the data pertaining to that record.
How much damage can this type of vulnerability really cause?
Know Why IDOR is Dangerous
When developers are not careful, they can design a system that displays and leaks application records in various places. A breach of this magnitude can be significant, especially when sensitive data or PII are involved.
The Australian Tax Office set up a website to help businesses collect a new tax. Unfortunately, it came packaged with the unwanted feature of an IDOR vulnerability. An inquisitive user realized that the URLs within the site contained his Australian Business Number, or ABN. It just so happens that this is an easily discoverable number for any registered business. This user decided to put the numbers of other companies into the URL. He was gifted with their bank account information and personal details!
Apple recently fell victim to an IDOR vulnerability. When the iPad was first released, 114,000 customer email addresses were leaked. (To be fair, it was more a mistake on AT&T's part).
You see, AT&T built a service to support 3G connectivity for iPads. The iPad sent an identifier stored on the SIM card to AT&T's service. The service then returned the user's email address.
Unfortunately, these identifiers were simply sequential integers and thus were easily guessable. Attackers iterated through the identifiers and stole the email addresses.
Another mistake was that AT&T's service tried to "secure" the service by only returning the email address if the request's user-agent header indicated that it came from an iPad. The user-agent is only a string value that can be easily manipulated.
IDOR vulnerabilities can be subtle and sneaky. Let's discuss how to defeat them.
Defeating IDOR
Access control is the key to solving IDOR. When a user requests a specific record, make sure they are authorized to view the requested record.
Using centralized authorization modules is the best way to do this. Tools such as Spring Security provide robust and customizable authentication and authorization for applications.
Bottom line: have one module that all other code relies upon to perform authorization checks.
Another common mitigation is the use of surrogate references. Instead of using the actual database record identifiers in your URLs, you can create random numbers that map back to the actual records.
Using surrogate references ensures that an attacker cannot get to a record just by guessing the next valid identifier.
And finally, don't rely on anything that the user can manipulate to provide authorization. AT&T tried to use the user-agent header to authorize their service. Don't rely on HTTP headers, cookies, or GET and POST parameters.
With these mitigations in place, IDOR will be a thing of the past.
Secure Your References
Insecure Direct Object References are one of the easiest vulnerabilities to exploit. Don't let them sneak up on you when you least expect it. Always check that users are authorized. Don't use real database identifiers. Don't depend on user-controlled data for authorization.
Build your mastery by checking out our Learning Resources. By practicing how to mitigate IDOR vulnerabilities in the language of your choice, you'll have no problem finding and fixing this problem in your production codebases. You can also put your newfound defensive knowledge to the test with a free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.
Ready to defend against IDOR attacks right now? Head to the platform and challenge yourself for free: [Start Here]
Table of contents
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
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 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.
Quests: Industry leading learning to keep developers ahead of the game mitigating risk.
Quests is a learning platform that helps developers mitigate software security risks by enhancing their secure coding skills. With curated learning paths, hands-on challenges, and interactive activities, it empowers developers to identify and prevent vulnerabilities.
Resources to get you started
The Decade of the Defenders: Secure Code Warrior Turns Ten
Secure Code Warrior's founding team has stayed together, steering the ship through every lesson, triumph, and setback for an entire decade. We’re scaling up and ready to face our next chapter, SCW 2.0, as the leaders in developer risk management.
10 Key Predictions: Secure Code Warrior on AI & Secure-by-Design’s Influence in 2025
Organizations are facing tough decisions on AI usage to support long-term productivity, sustainability, and security ROI. It’s become clear to us over the last few years that AI will never fully replace the role of the developer. From AI + developer partnerships to the increasing pressures (and confusion) around Secure-by-Design expectations, let’s take a closer look at what we can expect over the next year.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
