Coders Conquer Security Infrastructure as Code Series - Business Logic
Well, this is it (for now). We have reached the end of our Infrastructure as Code series. We hope you've had fun conquering security issues in Docker, Ansible, Kubernetes, Terraform, and CloudFormation. Before we sign off, though, we've got one more vulnerability for you to master: business logic bugs.
Think you're ready to test your skills now? Try the final gamified challenge:
If you're still unclear on a few things, keep reading:
The vulnerabilities we want to focus on today are business logic flaws. These can occur when coders fail to properly implement business logic rules which could leave their applications vulnerable to different kinds of attacks should a malicious user choose to exploit them. Depending on the purpose and functionality implemented within each application, a business logic flaw may allow privilege escalation, improper resource usage or any number of unintended business processes to be performed.
Unlike many vulnerabilities, incorrect implementation of business logic rules can be surprisingly subtle. They require special vigilance to ensure that they don't sneak into applications and code.
What are some examples of business logic flaws?
As an example of how easy it can be to induce business logic flaws, consider the following example from a Docker environment defined with a Docker Compose file. To prepare containers to perform functions, a developer might use a standard resource policy, defined in the Docker Compose file, like the following example:
deploy:
resources:
limits:
cpus: "0.5"
reservations:
cpus: "0.5"
While that looks fine on the surface, this resource policy for containers isn't properly limiting resource usage. An attacker could take advantage of the business logic flaw to implement a denial of service (DoS) attack.
To try and limit users from taking up too many resources, a developer might try to better define what each container can support. So the new code might include a placement constraint:
deploy:
resources:
limits:
cpus: "0.5"
reservations:
cpus: "0.5"
placement:
constraints:
- "node.labels.limit_cpu == 100M"
- "node.labels.limit_memory == 0.5"
At first glance, this looks like it would resolve the business logic flaw. However, the new placement constraint does not affect the resource usage limit for the Docker container service. It's only used to select a node to schedule the container. In this case, a DoS attack is still possible. The attacker would need to compromise a Docker container first, but would be able to drain resources without limits after that.
As you can see, thinking about business logic flaws and programming to eliminate them can be a tricky endeavor.
Eliminating business logic flaws
With business logic flaws, the key is knowing that they exist. You need to be vigilant about keeping them out of your environment while new code is being written. Business rules and best practices should be clearly defined and checked at all phases of the application development process including design, implementation and testing.
For example, to prevent a business logic flaw from enabling a DoS attack like in the above example, a best practice is to limit the amount of resources that every Docker container you create can use. Specifically, the limits section must specify the number of CPUs and the amount of memory a Docker container can use. An example would be:
deploy:
resources:
limits:
cpus: "0.5"
memory: 100M
reservations:
cpus: "0.5"
memory: 50M
Using code like the example above as a policy would remove a major business logic flaw from the environment and prevent DoS attacks. This would work even if an attacker compromised one of the Docker containers. In that case, the attacker would still not be able to use their foothold to deplete resources.
Threat modeling can be helpful by defining how different attacks take place and ensuring that business logic rules are used to prevent and restrict them. Testing based on compliance rules and known abuse cases could also be helpful in catching business logic flaws that slip through the cracks.
Business logic flaws are some of the most subtle vulnerabilities that can sneak into applications, but are no less dangerous than other more high-profile risks. Knowing how they can occur and using best practices can keep them out of your environment during application development, ensuring that they never reach a production environment where they can be abused by attackers who are very familiar with how to exploit them.
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 this IaC challenge in the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.


This vulnerability can occur when coders fail to properly implement business logic rules, which could leave their applications vulnerable to different kinds of attacks should a malicious user choose to exploit them.
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.


Well, this is it (for now). We have reached the end of our Infrastructure as Code series. We hope you've had fun conquering security issues in Docker, Ansible, Kubernetes, Terraform, and CloudFormation. Before we sign off, though, we've got one more vulnerability for you to master: business logic bugs.
Think you're ready to test your skills now? Try the final gamified challenge:
If you're still unclear on a few things, keep reading:
The vulnerabilities we want to focus on today are business logic flaws. These can occur when coders fail to properly implement business logic rules which could leave their applications vulnerable to different kinds of attacks should a malicious user choose to exploit them. Depending on the purpose and functionality implemented within each application, a business logic flaw may allow privilege escalation, improper resource usage or any number of unintended business processes to be performed.
Unlike many vulnerabilities, incorrect implementation of business logic rules can be surprisingly subtle. They require special vigilance to ensure that they don't sneak into applications and code.
What are some examples of business logic flaws?
As an example of how easy it can be to induce business logic flaws, consider the following example from a Docker environment defined with a Docker Compose file. To prepare containers to perform functions, a developer might use a standard resource policy, defined in the Docker Compose file, like the following example:
deploy:
resources:
limits:
cpus: "0.5"
reservations:
cpus: "0.5"
While that looks fine on the surface, this resource policy for containers isn't properly limiting resource usage. An attacker could take advantage of the business logic flaw to implement a denial of service (DoS) attack.
To try and limit users from taking up too many resources, a developer might try to better define what each container can support. So the new code might include a placement constraint:
deploy:
resources:
limits:
cpus: "0.5"
reservations:
cpus: "0.5"
placement:
constraints:
- "node.labels.limit_cpu == 100M"
- "node.labels.limit_memory == 0.5"
At first glance, this looks like it would resolve the business logic flaw. However, the new placement constraint does not affect the resource usage limit for the Docker container service. It's only used to select a node to schedule the container. In this case, a DoS attack is still possible. The attacker would need to compromise a Docker container first, but would be able to drain resources without limits after that.
As you can see, thinking about business logic flaws and programming to eliminate them can be a tricky endeavor.
Eliminating business logic flaws
With business logic flaws, the key is knowing that they exist. You need to be vigilant about keeping them out of your environment while new code is being written. Business rules and best practices should be clearly defined and checked at all phases of the application development process including design, implementation and testing.
For example, to prevent a business logic flaw from enabling a DoS attack like in the above example, a best practice is to limit the amount of resources that every Docker container you create can use. Specifically, the limits section must specify the number of CPUs and the amount of memory a Docker container can use. An example would be:
deploy:
resources:
limits:
cpus: "0.5"
memory: 100M
reservations:
cpus: "0.5"
memory: 50M
Using code like the example above as a policy would remove a major business logic flaw from the environment and prevent DoS attacks. This would work even if an attacker compromised one of the Docker containers. In that case, the attacker would still not be able to use their foothold to deplete resources.
Threat modeling can be helpful by defining how different attacks take place and ensuring that business logic rules are used to prevent and restrict them. Testing based on compliance rules and known abuse cases could also be helpful in catching business logic flaws that slip through the cracks.
Business logic flaws are some of the most subtle vulnerabilities that can sneak into applications, but are no less dangerous than other more high-profile risks. Knowing how they can occur and using best practices can keep them out of your environment during application development, ensuring that they never reach a production environment where they can be abused by attackers who are very familiar with how to exploit them.
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 this IaC challenge in the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.

Well, this is it (for now). We have reached the end of our Infrastructure as Code series. We hope you've had fun conquering security issues in Docker, Ansible, Kubernetes, Terraform, and CloudFormation. Before we sign off, though, we've got one more vulnerability for you to master: business logic bugs.
Think you're ready to test your skills now? Try the final gamified challenge:
If you're still unclear on a few things, keep reading:
The vulnerabilities we want to focus on today are business logic flaws. These can occur when coders fail to properly implement business logic rules which could leave their applications vulnerable to different kinds of attacks should a malicious user choose to exploit them. Depending on the purpose and functionality implemented within each application, a business logic flaw may allow privilege escalation, improper resource usage or any number of unintended business processes to be performed.
Unlike many vulnerabilities, incorrect implementation of business logic rules can be surprisingly subtle. They require special vigilance to ensure that they don't sneak into applications and code.
What are some examples of business logic flaws?
As an example of how easy it can be to induce business logic flaws, consider the following example from a Docker environment defined with a Docker Compose file. To prepare containers to perform functions, a developer might use a standard resource policy, defined in the Docker Compose file, like the following example:
deploy:
resources:
limits:
cpus: "0.5"
reservations:
cpus: "0.5"
While that looks fine on the surface, this resource policy for containers isn't properly limiting resource usage. An attacker could take advantage of the business logic flaw to implement a denial of service (DoS) attack.
To try and limit users from taking up too many resources, a developer might try to better define what each container can support. So the new code might include a placement constraint:
deploy:
resources:
limits:
cpus: "0.5"
reservations:
cpus: "0.5"
placement:
constraints:
- "node.labels.limit_cpu == 100M"
- "node.labels.limit_memory == 0.5"
At first glance, this looks like it would resolve the business logic flaw. However, the new placement constraint does not affect the resource usage limit for the Docker container service. It's only used to select a node to schedule the container. In this case, a DoS attack is still possible. The attacker would need to compromise a Docker container first, but would be able to drain resources without limits after that.
As you can see, thinking about business logic flaws and programming to eliminate them can be a tricky endeavor.
Eliminating business logic flaws
With business logic flaws, the key is knowing that they exist. You need to be vigilant about keeping them out of your environment while new code is being written. Business rules and best practices should be clearly defined and checked at all phases of the application development process including design, implementation and testing.
For example, to prevent a business logic flaw from enabling a DoS attack like in the above example, a best practice is to limit the amount of resources that every Docker container you create can use. Specifically, the limits section must specify the number of CPUs and the amount of memory a Docker container can use. An example would be:
deploy:
resources:
limits:
cpus: "0.5"
memory: 100M
reservations:
cpus: "0.5"
memory: 50M
Using code like the example above as a policy would remove a major business logic flaw from the environment and prevent DoS attacks. This would work even if an attacker compromised one of the Docker containers. In that case, the attacker would still not be able to use their foothold to deplete resources.
Threat modeling can be helpful by defining how different attacks take place and ensuring that business logic rules are used to prevent and restrict them. Testing based on compliance rules and known abuse cases could also be helpful in catching business logic flaws that slip through the cracks.
Business logic flaws are some of the most subtle vulnerabilities that can sneak into applications, but are no less dangerous than other more high-profile risks. Knowing how they can occur and using best practices can keep them out of your environment during application development, ensuring that they never reach a production environment where they can be abused by attackers who are very familiar with how to exploit them.
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 this IaC challenge in 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.
Well, this is it (for now). We have reached the end of our Infrastructure as Code series. We hope you've had fun conquering security issues in Docker, Ansible, Kubernetes, Terraform, and CloudFormation. Before we sign off, though, we've got one more vulnerability for you to master: business logic bugs.
Think you're ready to test your skills now? Try the final gamified challenge:
If you're still unclear on a few things, keep reading:
The vulnerabilities we want to focus on today are business logic flaws. These can occur when coders fail to properly implement business logic rules which could leave their applications vulnerable to different kinds of attacks should a malicious user choose to exploit them. Depending on the purpose and functionality implemented within each application, a business logic flaw may allow privilege escalation, improper resource usage or any number of unintended business processes to be performed.
Unlike many vulnerabilities, incorrect implementation of business logic rules can be surprisingly subtle. They require special vigilance to ensure that they don't sneak into applications and code.
What are some examples of business logic flaws?
As an example of how easy it can be to induce business logic flaws, consider the following example from a Docker environment defined with a Docker Compose file. To prepare containers to perform functions, a developer might use a standard resource policy, defined in the Docker Compose file, like the following example:
deploy:
resources:
limits:
cpus: "0.5"
reservations:
cpus: "0.5"
While that looks fine on the surface, this resource policy for containers isn't properly limiting resource usage. An attacker could take advantage of the business logic flaw to implement a denial of service (DoS) attack.
To try and limit users from taking up too many resources, a developer might try to better define what each container can support. So the new code might include a placement constraint:
deploy:
resources:
limits:
cpus: "0.5"
reservations:
cpus: "0.5"
placement:
constraints:
- "node.labels.limit_cpu == 100M"
- "node.labels.limit_memory == 0.5"
At first glance, this looks like it would resolve the business logic flaw. However, the new placement constraint does not affect the resource usage limit for the Docker container service. It's only used to select a node to schedule the container. In this case, a DoS attack is still possible. The attacker would need to compromise a Docker container first, but would be able to drain resources without limits after that.
As you can see, thinking about business logic flaws and programming to eliminate them can be a tricky endeavor.
Eliminating business logic flaws
With business logic flaws, the key is knowing that they exist. You need to be vigilant about keeping them out of your environment while new code is being written. Business rules and best practices should be clearly defined and checked at all phases of the application development process including design, implementation and testing.
For example, to prevent a business logic flaw from enabling a DoS attack like in the above example, a best practice is to limit the amount of resources that every Docker container you create can use. Specifically, the limits section must specify the number of CPUs and the amount of memory a Docker container can use. An example would be:
deploy:
resources:
limits:
cpus: "0.5"
memory: 100M
reservations:
cpus: "0.5"
memory: 50M
Using code like the example above as a policy would remove a major business logic flaw from the environment and prevent DoS attacks. This would work even if an attacker compromised one of the Docker containers. In that case, the attacker would still not be able to use their foothold to deplete resources.
Threat modeling can be helpful by defining how different attacks take place and ensuring that business logic rules are used to prevent and restrict them. Testing based on compliance rules and known abuse cases could also be helpful in catching business logic flaws that slip through the cracks.
Business logic flaws are some of the most subtle vulnerabilities that can sneak into applications, but are no less dangerous than other more high-profile risks. Knowing how they can occur and using best practices can keep them out of your environment during application development, ensuring that they never reach a production environment where they can be abused by attackers who are very familiar with how to exploit them.
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 this IaC challenge in 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.