APIsec Resource Center

Check out our latest articles covering how you can protect your APIs from vulnerabilities and other threats

FEATURED ARTICLE

What Is OWASP API Security Top 10: A Deep Dive

The rise of APIs has changed the landscape of vulnerabilities so fundamentally that a new approach was necessary, and 2019 OWASP added the API Security Top 10 list.
July 20, 2021
 • 
10 min read
Read Story
Tags
Penetration Testing

Dan Barahona

API Testing

Best Penetration Testing Tools to Secure Your APIs

What is Penetration Testing? Penetration testing, also known as ethical hacking, is a simulated cyberattack carried out by professionals to assess the security of a computer system or network. Pen tests are a key component of an organization's security strategy that helps you identify vulnerabilities that attackers could exploit. Organizations can then take steps to mitigate these risks and protect their systems more effectively. Organizations should consider penetration testing as part of their wider security strategy. Regular testing can help to identify weaknesses in systems before malicious actors exploit them. What are the Best Penetration Testing Tools? While there are a variety of tools available on the market, these are our top picks for the best penetration testing tools in 2022: APIsec Kali Linux Burp Suite ZAP Astra Pentest 1. APIsec APIsec provides an automated approach to finding the most serious security vulnerabilities in your APIs using a zero-touch deployment model that runs at speeds comparable with DevOps practices. Unlike other testing methods where you have to spend hours writing test scripts, APIsec uses an AI-based solution to write thousands of test cases unique to your API's architecture. The APIsec platform has been proven to be one of the most effective automated pen testing tools on today's market because it can find both common vulnerabilities as well hidden business logic flaws (loopholes that allow attackers to exploit legitimate functions of your API). Top Features Fully Automated Pen Tests: APIsec's automated pen tests take only minutes to run, allowing you to test your APIs with every new release. Business Logic Flaw Identification: APIsec analyzes every aspect of your API so it can find and illuminate deeply buried business logic flaws that other testing tools miss. AI-Powered: APIsec uses the power of machine learning to deeply understand how your APIs work, creating a unique solution. Actionable Insight Integration: APIsec provides the most actionable insights directly into your dev workflow to ensure that vulnerabilities are never left unnoticed. Pricing Before selecting one of APIsec's three main packages, customers can take advantage of APIsec's free API assessment to find any vulnerabilities in their endpoints and receive a detailed report on the findings. Aside from that, they offer: Standard ($500 per month*): The robust plan includes over 100 API test categories to choose from and full OWASP coverage with daily tests for both application logic and security. Professional ($1,950 per month*): This plan is the perfect option for those looking to take their operation up a notch. It includes advanced ticketing, pipeline integration, and single sign-on capabilities with APIs that other applications or systems can use within your business. Enterprise (Contact for price): With this plan, you get access to every feature APIsec has in its arsenal, from volume discounts and account management to a dedicated team of support professionals who can create custom test categories for your business needs. *Note: All prices apply per API. Why we recommend this tool: APIsec's innovative approach to securing APIs and uncovering business logic flaws makes them the best pen testing tool for protecting you against potential threats. 2. Kali Linux Kali Linux is a powerful open-source distribution tool geared toward those who want to perform penetration tests and other information security tasks. It provides common tools, configurations, and automations, so you can focus on your task without getting distracted by other aspects of security research or software development practices. The Kali toolkit includes everything you'll need for testing and auditing, including several hundred tools for various information technologies like penetration testing, computer forensics (including reverse engineering), and vulnerability management. Since Kali is tailored to security professionals, you'll need a decent understanding of the Linux operating system and other advanced security protocols to get the most out of it. Top Features Hundreds of Pen Tests: Kali includes over 600 penetration testing tools, which can be used for discovering vulnerabilities in an organization's system or network structure. Built-In Integrations: Kali easily integrates with other penetration testing tools like Wireshark and Metasploit, making this the solid choice for anyone who needs to take their security game up a notch. Wireless Device Support: Kali Linux is versatile and compatible with a wide range of wireless devices, allowing it to run properly on a wide variety of hardware. Pricing The developers of this distribution are committed to providing an open-source, free operating system for anyone. They will never charge you a penny! Why we recommend this tool: Kali Linux is made with pen testing professionals in mind, and if you're comfortable using Linux and command line, then this software will provide all of your needs. 3. Burp Suite Burp Suite is one of the most popular tools out there. It's a comprehensive platform that covers all aspects of pen testing, from reconnaissance to exploitation. BurpSuite aims to be a versatile tool that can be customized to meet your needs. It's possible for you to download add-ons called "BApps," which will provide additional functionality and enhance the capabilities you already have. Burp Suite is one of the best "man in the middle" tools for website penetration testing/exploit development, giving you complete control to see what's going on. Like any other complex system, many pieces in Burp Suite need detailed knowledge for you to get the most out of them. Top Features Intercepting Proxy: This feature allows you to intercept and modify traffic passing between your browser and the target website. Intruder: The intruder tool is a brute-force attack tool that can be used to guess passwords, cookies, and other types of information. Spider: The spider tool crawls the target application, following links and submitting forms to build up a map of the application's functionality. Pricing Burp Suite is available in both a free and paid version. The free version is fully functional, but it does have some limitations. The paid versions include: Burp Suite Professional: This package costs $449 per user per year, but you can add more people to your account at any time. The price is calculated based on how many remaining days there are in their current subscriptions. Burp Suite Enterprise: This edition comes at a price of $8,395 per year, which includes one concurrent scan. You can add another for an additional $599. Why we recommend this tool: Burp Suite is a comprehensive penetration testing platform that can be customized to meet your specific requirements and covers a wide range of testing requirements. 4. ZAP Zed Attack Proxy (ZAP) is a dynamic application security testing tool for finding vulnerabilities in web applications, and like all OWASP projects, it's completely free and open source. The OWASP ZAP is an excellent tool to use in place of Burp Suite. The ZAP security scanner can find potential vulnerabilities in your web application even before it's deployed. This is made easy by the automated nature of this tool. It can be easily deployed at scale because it is open-source, so it makes an ideal beginner's tool for assessing web traffic security. Zap is a great tool for beginners, but it falls short when you want more details and higher coverage of your scan. Top Features AJAX Spidering: The advanced testing tool for discovering requests on AJAX-rich web apps that cannot be found with traditional tools, and you customize your crawl configurations. Automated Scripting: With ZAP's extensibility and scriptability features, you can automate many of your application security testing needs with scripts written in almost any programming language. Intercepting Proxy: With the help of this amazing feature, you can analyze how your web application server responds when it receives certain types of messages. Pricing As an open-source tool, ZAP is free. Why we recommend this tool: It's easy enough for anyone, even if you're just starting out with pen testing or have some experience under your belt—it will suit all levels of expertise. 5. Astra Pentest The Astra Pentest is a premier API pen test tool that can conduct more than 3000 tests to find vulnerabilities within APIs. The platform is designed to be simple and straightforward, making it ideal for beginners. It also offers a wide range of features, making it a versatile tool for more experienced users. Astra's security engine is powered by creative hacker knowledge and constantly evolves their techniques to stay one step ahead of today's most sophisticated cybercriminals and hackers. Even though they provide a solid platform for all your security testing needs, they aren't pen testing professionals. Top Features Interactive Dashboard: With their all-purpose dashboard, you can manage and monitor vulnerabilities from anywhere in the world. Actionable Reports: The platform creates a detailed and comprehensive report that is easy to read and contains all of the information necessary for taking action on its findings. Easy to Integrate: With Astra's pentest platform, you can integrate your scans with workflow management tools like Slack and Jira to make security testing a part of the software development lifecycle. Pricing Astra Pentest offers three plans that users can choose from; however, only their "Pentest" plan ($4,500 per year) comes with a pentest. They do offer additional pen testing and enterprise plans, but you'll have to contact them for their pricing. Why we recommend this tool: The Astra PenTest platform has a simple interface that makes finding vulnerabilities and getting in contact with support easy. FAQ Why Should You Perform Penetration Testing? Performing penetration testing is important for a number of reasons. For starters, it helps identify vulnerabilities in your system that attackers could exploit. By testing your system's defenses, you can ensure that they are up to par and able to resist attacks. Penetration testing also improves your organization's security posture. When you identify and address weaknesses in your system, you can reduce the risk of data breaches and other security incidents by making it more difficult for attackers to breach your network. Additionally, penetration testing provides valuable insights into your organization's security processes and procedures. Conducting tests regularly helps you identify areas where improvements can be made. All this knowledge is used to refine and improve your organization's security posture. How is Penetration Testing Automated? In the past, penetration testing was a manual process that required significant time and resources. However, with the advent of new technologies, penetration testing can now be automated. To conduct an automated penetration test, security professionals need to identify the targets for testing, such as websites, web applications, network infrastructure, etc. Once the targets have been identified, they will need to configure the automated tools and processes for testing. Then, the automated penetration testing process will begin. The tools and processes will work to identify vulnerabilities in the target systems and applications. Security professionals will need to analyze vulnerabilities and determine which pose a risk to the organization once they have been uncovered. There are a number of different tools that can be used for automated penetration testing (some of them are listed above). How Much Does Manual Pen Testing Cost? The cost of manual pen testing depends on a number of factors, including the size and complexity of the system being tested, the level of expertise of the testers, and the time frame in which the testing needs to be completed. Generally speaking, manual pen testing is a major expense for an organization, costing anywhere from a few hundred dollars to several thousand dollars. For this reason, many businesses only opt to conduct manual testing once per year. Final Thoughts There are a variety of different pen testing tools available on the market. It is important to choose the right tool for the job at hand, as not every tool is suitable for your unique API. While this can seem like a challenge, there are a few things to keep in mind: What are the limitations of the tool? Will you have to supplement with another tool or service? What type of support is available? Are you able to use the tool to its full potential? With these things in mind, you should be able to choose the right pen testing tool for your needs. If you still have questions, reach out to our team and get a free vulnerability assessment.
September 16, 2022
6 mins
Continuous Testing
Bug Bounty

Dan Barahona

API Security

How to Continuously Test APIs (and Why That's Impossible for Bug Bounty Programs)

What Determines “Continuous” API Testing? Continuous API testing runs ongoing, automated, evolving tests against an API to ensure high performance and security. This testing is typically carried out throughout the development lifecycle to catch any bugs or vulnerabilities before the API is released. There are a few key factors that determine whether an API testing solution is truly continuous: Automation: A continuous API testing solution should be automated to run tests independently, without manual intervention. This way, the testing process can keep up with the pace of development and ensure proper security testing against all changes before they're released. Comprehensive coverage: A continuous API testing solution should provide comprehensive coverage of an API, including all endpoints and parameters, to ensure that no bugs or vulnerabilities slip through the cracks. Adaptability: A continuous API testing solution should constantly evolve its tests to keep up with changes in the API landscape. As new threats arise, tests should be updated to address them. Scalability: A continuous API testing solution should be able to scale up or down as needed, depending on the size and complexity of the API being tested. Here is a summary of how each method stacks up: Why is Continuous Security Testing so Hard? Many CISOs and members of the AppSec community find it hard to believe that any platform can effectively automate API security testing to cover the entire OWASP list. Those concerns are valid because finding the most dangerous vulnerabilities, like business logic flaws, is notoriously difficult because they're usually found deep within an application's code. To complicate the matter even further, business logic flaws aren't errors in the coding. Rather, these flaws exist in the application's logic, so any scanner looking for flaws in the code would fail to identify the dangerous vulnerabilities. Application complexity, the vast number of endpoints, and ever-expanding potential attack vectors have historically made it impossible for any engineering team to programmatically test for all possible security flaws. That's no longer the case. With the help of recent advancements in machine learning, automated API testing platforms, like APIsec, provide continuous, comprehensive testing coverage of an API, including all endpoints and parameters. Dev and security teams were historically stuck with limited options for protecting their APIs, the most popular being manual pen testing, vulnerability scanning, and bug bounty programs. Let's quickly break down each testing method, how they work, and where they come up short. Manual penetration testing is a process in which testers manually attempt to exploit vulnerabilities in an application. Some concerning issues with manual pen testing include: It's time-consuming and expensive since it requires highly skilled testers manually writing hundreds or thousands of tests that can take weeks or even months to complete. It's a point-in-time test that doesn't cover continuous code updates leaving significant windows of high vulnerability in the time between pen tests. Vulnerability scanning is similar to manual penetration testing but uses automated tools to scan for known vulnerabilities. Vulnerability scanning can be a fast and cost-effective way to find some security issues, but it has several limitations, including: It can only find known vulnerabilities, so as new flaws arise, they will go undetected. It can be noisy, creating many false positives that waste security and development resources chasing down phantom vulnerabilities. It can't find business logic flaws, which are often the most dangerous. Bug bounty programs consist of a crowd of ethical hackers who are paid to find and report vulnerabilities in an application. While this can be a helpful way to supplement other testing methods, it has several drawbacks: It’s time-consuming to set-up properly and requires continuous management to ensure researchers stay focused. It's reactive approach only tests for vulnerabilities after they’re in a production environment, leaving potential vulnerabilities exposed for weeks, months, or even years. It's often used as a replacement for other testing methods, which can be dangerous since it provides incomplete coverage. Bug bounty programs, along with manual pen testing and vulnerability scanning, can often do more harm than good by creating a false sense of security. Continuous testing is the only way to effectively protect your APIs from vulnerabilities, automating the entire process, including incorporating detailed reports directly into your CI/CD pipeline. While pen testing, vulnerability scanning, and bug bounties can be valuable tools in your API security arsenal, they simply can't provide the same level of coverage or speed as continuous, automated testing. Continuous Testing Starts with the Right Tools The first step to protecting your APIs using continuous testing is finding the right tool. Up until this point, we have only covered continuous testing for API security, but that’s only one piece of the puzzle. To truly test your API continuously, you need to find a suite of tools that cover every part of the API journey from security to functionality. No matter what type of testing you want to run, you should evaluate solutions based on their ability to execute the options we covered earlier: automation, comprehensive coverage, adaptability, and scalability. Next you should look at each solution’s ease-of-use, support, price, and any other feature that matters to you... here is a snapshot summary of tools that we love: We actually broke these tools down in more detail when we wrote this post covering the Top 5 API Security Tools on the market today, when to use them, and why we recommend them. Key Building Blocks of Continuous API Security Testing Are you ready to start continuous API security testing? Here are three key steps to take as you work toward a continuous API security testing environment: 1. Identify any manual bottlenecks in your security process today, and automate them. Automating as much as you possibly can is the cornerstone of continuous testing - not only will this strengthen your security, but it will free up your team to focus on other key tasks since testing will no longer require valuable human resources to perform (automation offers a significant, lasting ROI).‍ 2. Integrate everything directly into Continuous Integration / Continuous Delivery It’s highly likely your organization is already leveraging CI/CD technology to improve product quality and developer productivity. Don’t “re-invent the wheel,” rather, leverage these same processes/technology to test new code when it’s ready without needing to manually trigger a test. 3. Leverage your current developer feedback loop Finding a security vulnerability is only the first half of API security testing. Someone needs to fix them. This often requires inter-team communication for security engineers to recruit developers to fix these critical issues. As we mentioned before, there are existing processes you can leverage to deliver feedback to developers without the added manual step. Integrating with Developer Ticketing or Productivity software is a guaranteed way to prevent slowing the pace of development without missed issues, which may lead to deploying exploitable vulnerabilities to production. Ensure Continuous API Security Testing with APIsec Continuous API security testing is well on its way to becoming the new norm thanks to its scalability, accuracy, and cost-effectiveness. If you still haven't adopted continuous API security testing, you're almost guaranteed to leave your APIs exposed to data breaches and other cyber threats. For years, organizations had to rely on pen testing, vulnerability scanning, and bug bounty programs to protect their API assets. APIsec offers a superior alternative to all of them. By leveraging the power of AI and machine learning, APIsec can automatically generate and execute hundreds of custom-tailored attack scenarios based on the unique architecture of your API. Check out this quick demo to see it in action: Want to learn more? Get in touch with our team today to schedule a demo, or get a free vulnerability assessment.
July 19, 2022
7 minutes
API Vulnerabilities

Dan Barahona

API Testing

The Hidden Risks of API Monitoring That Leave APIs More Vulnerable

‍API Monitoring: A Quick Refresher API monitoring is the process of checking your API's endpoints and data exchanges to make sure they're functional, available, and performing as expected. This allows developers to identify and fix API issues before they impact the end-user. Additionally, you get visibility into how well each function within the API operates by viewing metrics such as the number of API function calls, the time it takes to respond to those calls, and the amount of data returned. In today's world, monitoring is essential to ensure your APIs are sustainable, the applications that depend on them receive the services/data they need while the end-user has a streamlined experience. Some companies think that API monitoring is enough to cover all of their API security needs. Here are 5 reasons why API monitoring alone is not sufficient to ensure API security. 5 Risks of API Monitoring That No One Wants to Tell You About While API monitoring gives you insight into certain information, there are some areas that slip through the cracks. We've put together a list of the most important vulnerabilities your API monitoring tools are missing. 1. Monitoring Tools Cannot Identify Business Logic Vulnerabilities Business logic can't be parsed using API monitoring tools, which means you won't discover an entire cluster of potential security risks that exist in your API governance Business logic vulnerabilities are either weaknesses or bugs in the design or legitimate functionalities of an application. Because business logic is unique to every application, business logic vulnerabilities typically go overlooked until your data has already been compromised. In late 2021 a security researcher ran vulnerability research on a group of financial services and FinTech companies. Every single API tested contained business logic flaws which created Broken Authentication vulnerabilities that allowed the researcher to perform API requests on other bank customer accounts without authenticating. That's what makes these vulnerabilities so dangerous. The fact that these vulnerabilities are often exploited without the need for special tools or techniques makes them widely cited as the number one API security threat. Since these vulnerabilities are rooted in your API's governance, you'll need to have a deep understanding of every process, rule, and workflow that directly or indirectly informed the setup of your API. 2. False Positives and Negatives Cause Teams to Miss Auditable Events API monitoring tools have a tendency to produce a fair amount of false positives while simultaneously missing other potential auditable events. An auditable event occurs when a user performs a certain action that may affect the security of your API or correlates to a security breach, such as: Changing or deleting policies, permissions, and data Making large transactions Failed login attempts Altering system functions Since many API monitoring tools run on pass/fail alerts that are based on your API’s governance, many IT departments find themselves overwhelmed with the number of false positives they need to investigate, especially if the ticket doesn't include enough information. It's like having a doorbell camera that alerts you every time a car goes by; eventually, you stop looking at the notifications and miss an important event. Similarly, IT teams either deprioritize their investigations or become less confident in their monitoring tool—IT teams reported that 44% of their alerts go unexplored, exposing them to potential attacks. When teams fail to investigate false positives promptly, they run the risk of missing an actual threat to the system. This is one of the main reasons why insufficient API logging and monitoring are listed as one of OWASP's Top Ten API Security threats. 3. Synthetic API Monitoring Tools Fail to Simulate Real-world Events Synthetic monitoring, sometimes called synthetic testing, was developed as a proactive way to test your API, but it does little more than conduct basic acceptance tests to check your API's performance. Synthetic monitoring involves a monitoring client actively sending a previously-made client request to your API, meaning that they aren't monitoring what your users are currently doing. While using these predefined requests helps you assess your API's performance, it only accounts for what you anticipate or what some users have done in the past. Additionally, these tests only occur on single endpoints, severely limiting their ability to detect functional errors. Synthetic monitoring tools don't unify work silos, they create more. This means the teams with the deepest knowledge of creating real-world tests specific to your API won't be involved in their creation. 4. API Monitoring Cannot Continuously, and Proactively Test API Vulnerabilities While you can set up a monitoring routine that runs at regularly scheduled intervals throughout the SDLC lifecycle, you'll find that API monitoring is nowhere near enough to ensure continuous API security testing. Continuous testing is the process of integrating automated testing into SDLC pipelines so that businesses can identify and resolve risks quickly and efficiently. This is done by applying shift-left testing methodologies, which only work if your testing doesn’t slow down your dev team. While API monitoring tools complement continuous testing methods by adding another layer of screening on their own, they aren't enough to ensure security and can’t keep up with new cybersecurity threats. 5. Monitoring Can't Match Specialized API Security Testing Solutions API monitoring tools claim to analyze your entire API, but they only return certain metrics without providing your details to the underlying cause of a vulnerability—or miss it altogether. On the other hand, specialized API testing solutions, like APIsec, are designed to dissect every endpoint, variable, method, and input parameter to uncover hidden API security threats, including business logic flaws. APIsec has the perfect plan to keep your API safe and secure. Check out this quick demo to see how the platform works: Our engine creates thousands of automated attack playbooks, which are designed for testing every corner of your system so that you can be confident no vulnerability is left uncovered. Here’s how it’s done: We learn your API architecture: With just a list of endpoints and methods, our platform can integrate directly with your API platform, OpenAPI spec, Postman collection, Swagger, or other interface. We generate custom API test cases: We offer a comprehensive API security testing platform that automatically creates and executes thousands of test cases tailored to your unique architecture. We run our tests in multiple environments: With the ability to run our tailored tests throughout the SDCL, we ensure every corner of your API is tested for any potential vulnerabilities. We find what everyone else misses: Since our test cases are tailored to the unique architecture of a given API, the platform uncovers hidden layers of vulnerabilities that are impossible to catch with pen testing or vuln scanning. Want to learn more? Find out how APIsec helps companies take their API security testing to the next level here or schedule a demo.
July 12, 2022
5 minutes
API Design

Dan Barahona

API Testing

Shift Left Security: The Ultimate Guide

GitHub estimates that developers outnumber security professionals 500 to 1, meaning organizations need to integrate shift left security measures into their development to stay competitive. The use of traditional testing is often not in line with DevOps, which emphasizes delivering features and updates from one production stage to the next without unnecessary delays. How did they fix this? By implementing agile methodologies, like shift left, into DevOps practices. Shifting left means integrating testing and security activities into every relevant stage of development, from design to production. How Shift Left Impacts Security Shifting security left means taking a new approach to how DevSecOps teams develop and design software. The goals of this shift are simple: Build security best practices into your process from start-to-finish Detect potential issues as early in the lifecycle as possible Fix problems quickly without expensive miscalibrations later down the line Maintain an affordable price point for any company or organization To do this effectively and efficiently, developers must be aware of what they need during each stage to avoid gaps in their defenses against vulnerabilities that malicious actors could use. Integrating CI/CD into SDLC The adoption of CI/CD transforms the SDLC as it automates and monitors every step of the development process, from code integration to live production environments. In addition to reorganizing teams into DevSecOps teams, companies will have to incorporate security testing earlier into their deployment pipelines as CI remains crucial for software development. Benefits of Shift Left Security Shift left testing is a powerful way to identify and fix defects before they become costly, meaning your team can make faster progress in the development cycle. Other benefits include: Improve code quality and security posture Easily manage risks with cloud technologies Create a security-conscious culture Continual assessment Driving Technologies for Shift Left Security To make sure organizations maintain a high level of security, OWASP suggests DevSecOps use a variety of tools. Here are five commonly used tools: SAST (static analysis) DAST (dynamic analysis) Interactive Application Security Testing (IAST) Software Composition Analysis (SCA) Cloud Security Posture Management (CSPM) How to Implement Shift Left Security: 5 First Steps Shift left security can be implemented in a number of ways, but these are the most crucial steps. 1. Establish and Define Shift Left Security Strategy It's critical that you identify what shift left means for your team to help them understand how to achieve success. To do this, you'll need to: Define Common Goals The goal of DevSecOps is to promote collaboration and alignment among all stakeholders involved in the development process. To do this, teams need to come together to clearly establish their goals and objectives for their shift left security strategy. This should include: Who has ownership or responsibilities over what processes? What metrics will be used to gauge success? What parts of your applications and APIs operate with sensitive data? How many resources are you willing to allocate to the testing process? What will your milestones look like? Change the Culture Enable a security-centric development environment where security is considered at every stage of the development lifecycle—whether it's selecting a package during project planning, developing code, or conducting tests. You'll most likely have to do some shift left myth-busting to facilitate a smooth transition. The most common misconception is that shift left means moving the testing to an earlier stage and then neglecting to test later. Establish a Set of Security Requirements for APIs Because APIs are windows into your system, the safety of an application depends on the security policies you establish for them. Including security requirements for APIs in your shift left security strategy, will boost your security posture. There are a few factors to consider when establishing a set of security requirements for APIs, such as: The type of data being accessed by the API The environment in which the API will be used The user base that will be using the API For example, if the API is accessing sensitive data in a public environment by many users, then a higher level of security will be required. When determining the security requirements for an API, it is essential to consult with experts in the field. They will be able to help identify what security measures need to be put in place to protect the data that is being accessed by the API. They will also help determine what level of security is needed. 2. Understand Where Software is Created Understanding your software development pipeline is an important first step in securing it. This will be more challenging depending on the complexity of your business units. Before you can start shifting security left, identify who's responsible for developing code and how that person or team moves from creating new features through deployment to production. This helps you identify what technology will be used throughout this process, so there are no gaps. Make sure you identify: The individuals responsible for developing code The workflow process The technology used in this process 3. Implement Security Controls at the API Level Through APIs, applications and software interact with your business, allowing outsiders direct access to sensitive information. Without proper security measures in place, cybercriminals will exploit these vulnerabilities. To address OWASP's Top 10 API security risks, it's recommended that you implement security controls at the API level, which help protect your data and systems. Some of the most widely used security measures are: Authentication and Authorization: Ensure only authorized users access the API using OAuth 2.0 or OpenID protocols. Encryption: Protect the data that passes through your API from interception and tampering, for example, using SSL/TSL encryption. Principle of least privilege: With this principle, subjects are granted only the minimum access necessary to complete a stated function—this includes access to your APIs. Use rate limits: To prevent denial-of-service attacks, set a threshold above which subsequent requests will be rejected. 4. Automate Security Processes Penetration testing and vulnerability scanners are the most common ways to test the security of your APIs. However, they each have unique problems when using a shift left security approach. Vulnerability scanners are deployed to test your APIs against a list of known vulnerabilities, but they do not consider your API's architecture. This means they miss business logic flaws that leave you vulnerable. On the other hand, pen testers use black box or white box testing methods to simulate attacks on your API, which are extremely time-consuming and expensive when applied to the shift left testing framework. But there’s a third way. You can use APIsec. APIsec is an automated security testing solution that uses AI to analyze the architecture of your APIs to generate and execute hundreds of custom-tailored attack scenarios. 5. Implement Security Fixes as the Code is Developed It is important to implement security fixes as you develop the code so that your application and APIs have no vulnerabilities. It’s a good idea to retest once you fix your code as loopholes often open up after remediation. This ensures no weak spots are left where an attacker could exploit simple errors. Give your DevSecOps team the tools they need to implement shift left security. Contact our team to schedule a free demo.
May 31, 2022
15 mins read
Business Logic

Dan Barahona

API Security

What is Broken Object Level Authorization (BOLA) and How to Fix It

With APIs projected to become the main attack vector in 2022, companies that downplay the importance of API security risk making the headlines as the next victim of a major data breach—losing customer trust for years to come. While most API threats are relatively easy to catch using vulnerability scanners, some can remain undetected for years. This makes them a ticking time bomb until bad agents spot them. Today, we're going to cover one of them. Broken Object Level Authorization (BOLA) vulnerabilities sit at the top of the OWASP API Security Top 10 list. Why is that the case? Keep reading to find out the answer and learn how to protect yourself from it. What is Broken Object Level Authorization, and Why Is It #1 on the OWASP Top 10 List? Object-level authorization is a security measure that controls which users can access which objects, be it database records or files. For example, a user might be allowed to view specific files but not edit or delete them. Broken object-level authorization (BOLA) vulnerabilities occur when a user is able to access other users' data due to the flaws in authorization controls validating access to data objects. BOLA vulnerabilities are often caused by insecure coding practices, such as failing to properly validate user input or check permissions before granting access to an object. This happens when an API uses overly permissive access controls or when API resources are not properly protected. BOLA vulnerabilities lead to devastating data breaches and other ramifications. The USPS hack, one of the largest data breaches in history, happened because of, you guessed it, broken access controls. “The USPS hack is a classic example of a broken authorization vulnerability. User A was able to authenticate to the API and then pivot and access user B’s and 60 million other people’s information.”- Dan Barahona, Head of Marketing at Biz Dev at APIsec How to Protect Your APIs from BOLA Vulnerabilities Since BOLA vulnerabilities are the most dangerous cluster of API threats, companies need to take proactive steps to prevent them. Here are the most effective ones. 1. Enforce Robust Authorization Mechanisms Enforcing robust authorization mechanisms is the first step any organization should take to combat BOLA vulnerabilities. Many organizations think their APIs are secure because they have strong authentication. But that's not really going to help a whole lot when it comes to BOLA vulnerabilities. To keep your APIs safe, you need strong authentication mechanisms, but the bigger challenge is ensuring you've got well-controlled authorization policies that you are testing rigorously and continuously to make sure they're free of logic flaws or loopholes.2. Use Random Universally Unique Identifiers (UUIDs)The next step is redefining how you approach the process of generating and managing IDs within your API ecosystem. Auto-incrementing IDs absolutely have to go. As an alternative, use random IDs when creating and accessing APIs. These IDs, commonly referred to as UUIDs, are designed specifically to be difficult for cybercriminals or unauthorized users to guess. UUIDs are made up of a combination of letters, numbers, and symbols that have no inherent meaning or pattern, making them virtually impossible to guess or reverse-engineer. Using UUIDs minimizes the risk of malicious tampering, one of the root causes of BOLA vulnerabilities.3. Laser-focus on Your Business Logic Layer BOLA vulnerabilities are so tricky because they often lurk in the business logic layer of your APIs. The implications? It means that BOLA vulnerabilities typically occur due to the flaws in the design of the legitimate functionalities of your APIs rather than bad agents using complex exploits to break into your systems. That's why it's critical to meticulously test your business logic layer to spot vulnerabilities that are impossible to reliably address upon each release with vulnerability scanners. “BOLA is already #1 on the OWASP API Security Top 10 list - and for good reasons. API providers do a great job at making sure that users are authenticated to the API, so they want to make sure that legitimate users have access. But the number one thing that's often overlooked is authorization, ensuring that user A can't access user’s B resources. And it's one thing to hide the resource IDs, but the important factor there is that user A should not be able to access, interact with, or alter user B's resources - at all.”- Corey Ball, Cybersecurity Consulting Manager and Author of "Hacking APIs"4. Implement the Zero-Trust Security Model Enforcing the zero-trust security model is another step organizations typically take to protect APIs from BOLA vulnerabilities. In a traditional security model, authorized and authenticated users are trusted by default. However, in the zero-trust security model, all users must be authenticated and authorized before accessing any resources. Additionally, the authorized users are constantly monitored to prevent insider threats. Based on this model, each API call must be authenticated and authorized before it can be executed. Once the user has been authenticated, the authorization mechanisms in place determine whether the user is allowed to access the requested resource. If the user is not authorized, then the API call will not be executed, making it more difficult for attackers to exploit BOLA vulnerabilities.5. Ensure Continuous API Security Testing This is arguably the most effective way to protect APIs from BOLA vulnerabilities. However, here's the rub. Traditional API security testing tools aren't reliable since vulnerability scanners don't take into account the unique architecture of your API while pen testing is impossible to scale to ensure full coverage with each update. This is where APIsec comes into play. APIsec is an industry-leading solution that leverages the power of AI to dissect your API and generate custom-tailored attack scenarios aimed at identifying business logic vulnerabilities. APIsec is the only reliable way to automatically secure your API from BOLA vulnerabilities and, most importantly, business logic flaws while ensuring full coverage and eliminating human error. Sounds too good to be true? Get in touch with our team today to get a free demo.
May 11, 2022
6 mins
No items found.

Dan Barahona

API Testing

Penetration Testing Best Practices for Every Stage of Testing

Due to the ever-changing cyber threat landscape, it's more important than ever for businesses and governments around the world to recognize and protect themselves from potential cybersecurity risks. Even if you think that your company's security measures are on point, there's always a chance they won't be enough to prevent an intrusion. Penetration tests uncover cybersecurity weaknesses in your systems and reveal how attackers could potentially exploit them before it becomes too late. These tests are an essential security practice where you intentionally attack your applications, networks, APIs, and computer systems to find and exploit vulnerabilities. By following our best practices for effective results, you ensure that your organization gets the most out of its penetration testing initiative. Pen Testing Best Practices No matter what stage of the testing process you're in, we have aligned our best practices with your needs to provide the most helpful information. Scope1. Set Clear Objectives The first step in developing a secure test is to plan it by setting your scope. This involves selecting specific objectives and conditions for your test that will affect the outcome. For example, you might want to cover an entire network, certain applications within that network, test the security of your APIs, or even specific users who work remotely from home offices. The objectives and goals of a penetration test often vary greatly, from improving security to ensuring compliance with regulations. You'll need to clearly understand, "Why are we even doing a pen test?" To avoid wasting time and resources on unimportant areas, focus on the high-risk vulnerabilities that are likely to be exploited first. During this process, your team should clearly: Evaluate the reasons for conducting pen testing Define the target environment Identify resourcing requirements Establish and define liabilities Determine the testing to be conducted Discuss follow-up activities 2. Establish your Budget Your budget is one of the most important things to take into consideration when you're looking for a security solution. The price you pay for security depends on the value of your assets and what kind of objectives you are trying to achieve. Factors that affect your budget: In-house testing versus hiring an external service provider Type of testing you want to do (black, white, grey, or red teaming)The amount of time needed to conduct the test The scope and coverage focus One way to keep your costs down is to use automated testing instead of manual testing. Another way to eliminate costs is by using white box testing, which gives the tester all the information they need to find vulnerabilities faster. Remember, there is no one-fits-all solution because every organization has its own needs that translate into dollar figures—the more coverage you want, the more you pay. Expertise3. Choose a Penetration Testing Methodologies There are five common methods you can use for a penetration test, and the results will vary depending on which one is employed. Open Source Security Testing Methodology Manual (OSSTMM): This peer-reviewed methodology provides technical details for identifying what needs to be tested, how to measure the results, and what to do during every step of testing. Open Web Application Security Project (OWASP): This industry-leading organization is dedicated to improving cybersecurity by providing lists of the most common cyber threats as well as tools, forums, and documentation to anyone who needs them. National Institute of Standards and Technology (NIST): The methodology by which NIST approaches security assessment of information technology systems is less comprehensive than the OSSTMM; however, their approach is more accepted by regulatory agency standards. Information System Security Assessment Framework (ISSAF): This peer-reviewed framework provides field inputs for security assessments for real-life scenarios. Penetration Testing Execution Standard (PTES): This methodology was created by industry specialists and provides a common language standard for penetration testing. Pro Tip: External pen testers use varying methods. Make sure their methodology aligns with what's necessary for this test, and make it clear from day one which objectives need completion before they start testing.4. Find the Right Pen Testers When hiring pen testers, make sure you ask the right questions and find the right experts for your target domains: if it's API security, look no further than those who specialize in this field. An expert will know how systems are built as well as their common weaknesses, so they'll help guarantee the success of any pen test by taking advantage from all possible angles. Advantages of hiring external penetration testing providers: They have experienced staff dedicated to conducting highly-effective tests. They complete independent assessments that provide a comprehensive analysis of your security posture. They conduct a wide variety of testing that satisfies any environment and objective.5. Prepare for the Pen Test In order to ensure your pen test yields maximum results, you'll need to: Request sample reports from your pen tester. If anything, in particular, catches your eye or interests you (for example, missing data points on important metrics or the findings don't include enough non-technical corrective actions), indicate this when making queries during regular meetings. Clean up the test environment by restoring it back as close to its original state. Ideally, you want to test in a live environment, but many perform their tests in development test environments to avoid disruptions. Make sure your team is ready for anything by identifying those who will review the test report and fix any issues that were discovered during testing. Grant proper authorizations to conduct testing if needed.Monitor6. Establish Monitoring Solutions Make sure that your security monitoring solutions are in place before starting a pen test. Not only will this help you oversee the testing performance, but you'll also be able to make sure appropriate actions are taken when necessary. To do this, we recommend: Implement logging: This is a vital component in security monitoring and investigation because it provides insights into pen tests' impacts on your systems as well as identifying potential vulnerabilities before they become threats. Establish risk management processes: They should cover many areas, including tests that don't work as planned or problems caused by penetration testing gone wrong. Additionally, they should look for breaches in contract/codes for both company and individual policies regarding security vulnerabilities and provide ways for effective resolutions when needed.Remediation7. Prioritize Pen Test Results Now that we have all of this data, it's time to take action! Schedule a team meeting with your security leaders and specify which vulnerabilities need immediate attention. Your pen testers should provide you with: How the vulnerabilities were discovered Potential outcomes if they are exploited The risk level for each vulnerability Remediation advice The tester will use their technical expertise to determine the most pressing vulnerabilities. You should review their prioritization and decide which ones make the most critical impact on your business to tackle first. Ask yourself: Should we fix this? What happens if I don't? How will that affect my company? If we can't fix the vulnerability, can we mitigate the damage if exploited? Remember, defects may arise from mistakes made during design or implementation, new attack techniques that were unknown at the time of testing, or simply coding errors. Your development team needs to identify areas where they can improve their process for them to have successful products. Pro Tip: When selecting a pen tester, make sure their reports include both technical and non-technical terms so that your entire team has access to this information. If the report is too complex for audiences outside of tech-related fields, it may not provide enough information needed to justify adjustments within an organization's business practices.8. Review Vulnerabilities and Adapt After you've prioritized your results, you'll begin remediation. During this process, we recommend: Keep communication channels open by providing regular feedback and being available for quick meetings to provide clarity or address questions and concerns. Assign a dedicated task force to handle any uncovered vulnerabilities, ensuring they have all the resources necessary and an appropriate amount of time and experience for this job. Identify the root cause of the vulnerability and develop strategies to take corrective action for each one. Re-evaluate your security measures after they have been fixed to ensure that any previously found vulnerabilities were indeed eliminated. Maximize Your Security Posture While penetration tests are a great way to identify vulnerabilities, they have clear limitations. The main one is that it only captures a snapshot of a specific point in time. To get the most out of your security processes, you need to pair it with a robust security partner that has the ability to test your system and processes continually. APIsec offers a fully automated and continuous testing solution that runs comprehensive attacks on every endpoint in your network—giving you the most up-to-date information. Ready to start securing your APIs and networks? Reach out to one of our security specialists for more information.‍
May 11, 2022
5 mins
No items found.

Dan Barahona

API Security

What is Business Constraint Exploitation?

Business constraint exploitation, commonly known as business constraint bypass, is not a typical data breach where sensitive data is stolen; rather, this vulnerability occurs when an application's business logic constraints are circumvented by an attacker. Since this flaw is more challenging to discover than OWASP vulnerabilities, we've put together an article that discusses the importance of identifying it and what you can do to test for potential attacks. Why It's Important to Identify Business Constraint Bypass? Business Constraint Bypass is an overlooked threat that can seem harmless at first. But if left unchecked, this simple exploit could lead to serious problems for your company's data and applications—from getting access where it shouldn't have to DoS-based attacks. For example, your website has a flash sale of a product, but each customer is limited to 10 items per transaction. When a web application or an API has a loophole, malicious users are given carte blanche to modify and exploit this parameter (limit per customer to purchase more, therefore bypassing your business constraint. If you've tried to get your hands on a new gaming system during its initial launch, you've experienced this type of exploit from a customer's perspective. Let's see ways to correct business constraint exploitations. How to Combat Business Constraint Bypass Vulnerabilities? The best way to get more information from a program is by looking at its controller. This can be done in two ways: finding parameters that may be changed or examined and then modifying them to have better data sets for your analysis. Modifying a program's parameters to return more data than necessary is an effective way of finding bugs in the application. Usually, this involves looking at all its possibilities and then choosing which ones can be modified for better results. Here are some other remediation steps you could take: Monitor API Calls: Make sure they are being used as intended. If an API call is available on the internet, someone has a chance to exploit it. Set Limits on API Keys: Regular users should never have limitless capabilities or access. Set User Limits on Dynamic APIs: Limit requests by user or use cases, including session data in requests themselves. Observe HTTP Traffic: Look at both request and response blocks. Analyze POST/GET Requests: Malicious actors might use POST/GET requests with typical parameters either in name-value pair, JSON, or XML. Search Hidden Parameters: Look for hidden parameters and their values, analyzing specific calls as these constraints on a business can become targets if the end-user of your application or website does not understand them. Start Securing Your Business Constraints with APIsec Finding business constraints on your own is time-consuming, and you still risk missing a flaw. APIsec is leading the industry with its innovative, comprehensive, and continuous API testing. Here's how they find the often undiscovered constraint flaws: API Analyzer: With API Analyzer, you can dissect your company's APIs down to every endpoint, call, and input parameter so that the engine knows how best to attack it. API Attacker: API Attacker is an attack generator that applies hundreds of different scenarios and maps them onto your API to create custom-tailored attacks based on your unique API architecture. API Scanner: The engine that searches for anything unexpected in the test generated by API Attacker and generates a report. APIsec's solution makes it possible to continuously test APIs with each release - not just once or twice per year. Don't wait until you've been exploited; contact an API security specialist to schedule a free demo.
May 5, 2022
5 mins
No items found.

Wesley Meier

API Security

Web Attacks: Intro to HTTP Verb Tampering

In the early days of the internet, you had to type "http://" before entering the web address of a website. Redirects have made our lives easier in that sense, but HTTP (Hypertext Transfer Protocol) still plays an integral part in applications across the web. Since this application-layer protocol for transferring hypermedia documents, such as HTML to render pages, is so common — it’s also a popular attack vector for cybercriminals. What Are HTTP Verbs? The HTTP verbs specify how the server should handle data identified by the URL. Often called "HTTP methods," they're called verbs because they are simply actions. Web servers accept many different HTTP verbs, but some of the most common instances are: GET - Returns a representation of a specified resource. Only retrieves data. POST - Submits an entity to the specified resource, often causing a change in state or side effects on the server. PUT- Writes the request payload to the specified location. PATCH - Makes a partial change to an existing resource. DELETE - Deletes the resource at the specified location. GET and POST are traditionally the two most commonly used HTTP verbs. For example, when you want to visit a website like Google, you’re performing a GET HTTP verb, retrieving the data from the website to your device. Performing a POST HTTP verb often shows up as entering information into a form on a website. You're "posting" new data, or a state change, on the web server. Links with the standard style trigger a GET request, while forms submitted with the 'POST' method trigger a POST request. In the absence of an HTTP verb, the form sends data via GET by default. As you can see, there’s not much difficulty in being able to change HTTP verb inputs. Attackers easily perform sensitive functions like DELETE once it's evident that there are vulnerabilities in the HTTP configuration. How Does HTTP Verb Tampering Work? HTTP verb tampering attacks take advantage of vulnerabilities in authentication and access control mechanisms of HTTP methods. The most common HTTP methods allow access with limited security because that’s how the authentication mechanisms were intended. Sites that required authentication originally were deemed secure with only password protection. As the Web got smarter, so did cybercriminals. Because most HTTP verbs are not fully secure, tampering is as simple as manipulating a password-protected area, allowing unauthorized access to restricted resources. HTTP verb tampering tends to be caused by misconfigured security settings either in the web application or the backend server. An attacker will exploit the vulnerability to bypass authentication and access sensitive data—with the option to manipulate or delete data by simply changing the request method. Common Attack Scenarios Insecure default configurations: Analyze whether any of your endpoints run on out-of-the-box settings and allow the usage of all HTTP verbs by default. Storing HTTP verbs in URL strings: Attackers can extract which HTTP verbs are allowed if stored in the URL strings. Ensure that your URLs do not contain HTTP verbs that can allow the URL to be easily manipulated. Using hidden fields to store status information: Hidden fields might be great and easy to use at design time, but attackers can easily read those hidden fields by inspecting the web page and then tamper with the information in them. Man-in-the-Middle attacks: Two servers are communicating without encryption, which allows an attacker to intercept and monitor traffic and communication. Lack of authorization and authentication of API endpoints: API vulnerabilities are commonly caused by inadequate authorization and authentication controls. An attacker can compromise an account protected by a single layer of authentication and abuse a lack of checks to expose information. Insecure coding: A web developer often applies specific filters to mitigate particular vulnerabilities within the written code, but leaves the code insecure by not applying those filters to all HTTP verbs. HTTP verbs being transferred between the client and the server: An attacker hijacks the message being passed between client and server to tweak the HTTP verb. How to Combat HTTP Verb Tampering Vulnerabilities There are a few actions you should take immediately to prevent HTTP verb tampering. Check Configurations: Make sure your code is not set to "allow all" in your security configurations. Failure to do so means attackers can use alternative HTTP verbs like HEAD or arbitrary character strings in their requests to gain access. Test: Penetration testing (or pen testing) involves simulating attack scenarios on your HTTP verbs to look for vulnerabilities that could lead to HTTP verb tampering before they're exploited. If you're regularly conducting pen tests, checking for problems like modified data or request smuggling will help prevent any issues from happening later. Be sure to include not only whether or not they're accessible, but what may happen once access has been granted. Automate the process: Automation saves time and resources all around. Automating your pen-testing means more quality analysis in finding potential vulnerabilities and preventing them before they happen. APIsec is the only automated API security testing solution that covers both vulnerability scanning and pen testing. APIsec provides ten times the coverage of manual pen testing at one-tenth the cost. APIsec doesn’t stop there, though. When vulnerabilities are uncovered, APIsec automatically provides a detailed description of the attack playbook used, giving you an actual "recording" or wire logs of the successful attack and remediation recommendations. Engineers never have to waste time investigating issues; instead, they can focus on remediation of the underlying problem. Schedule a demo today to see how APIsec can automate API security testing for your organization. ‍
May 5, 2022
6 mins
No items found.

Dan Barahona

API Security

Sensitive Data Exposure: What It Is and How to Avoid It

The amount of sensitive data we share with outsiders has skyrocketed thanks to the technological advances that undoubtedly make our lives easier. However, these same advancements come with a cost—increasing exposure of our personal data. So, how is sensitive data exposed? What Is Sensitive Data Exposure? A sensitive data exposure occurs when an organization unknowingly exposes its customers' private information, leading to accidental destruction, alteration, or distribution of sensitive data. Personally identifiable information (PII) such as financial, business, and personal data is not the only sensitive information that needs to be protected. Other forms of sensitive data that need rigorous safeguarding include: Race, ethnicity, religious beliefs, political associations, or philosophical beliefs Passwords/login credentials Genetic and biometric data Trade-union membership Health-related information Details surrounding an individual's sex life or sexual orientation Sensitive Data Exposure vs. Data Breach It's important to remember that sensitive data exposure is different from a data breach, even though these terms are often used interchangeably. A data breach occurs when a third party with malicious intent gains unauthorized access to sensitive information. This typically occurs when sensitive data is exposed; however, breaches still happen without a preexisting exposure. On the other hand, it's possible for an organization to have sensitive data exposure without having their information breached. Just because an exposure exists doesn't mean it will be breached, but it significantly increases the chances. How Do Sensitive Data Exposures Lead to Attacks? The more you know about how data is prone to exposure, the better equipped your organization will be at mitigating potential attacks on this sensitive information. And since regulations, like the GDPR and CCAP, require organizations to protect sensitive data or face serious consequences, it's essential to know specifically where your company's sensitive files may run into trouble. Digital data is found in several different states, and to better understand where attacks occur, we need to take a quick look at them first. Data at Rest Many web applications typically store data at rest in servers, files, networks, and databases. While this data appears to be less vulnerable to attacks, the security of this information is entirely dependent on the protocols in place to protect it. Cyberattacks such as SQL injections or malicious payloads are used to circumvent security measures and gain unauthorized access to stored data. Data in Motion As data is exchanged between servers, channels, and application programming interfaces (APIs), it's at risk of interception by third parties along the way. Cybercriminals take advantage of security flaws that exist when two applications or servers communicate without encryption. One common attack is known as a man-in-the-middle (MITM), where the attacker intercepts and monitors traffic and communication. Data in Use Unlike data in motion or rest, data in use is a reflection of the current activity happening within an organization's IT infrastructure. This means that it can be actively updated, processed, or erased at any time, rather than simply being stored for later access. Data in this state is equally vulnerable to attacks and even more likely to be initiated by insider attacks. Now that you know where data can be attacked, let’s look at the way these attacks happen. Common Ways Data is Infiltrated: Broken access controls - Broken access control attacks rank #1 on OWASP's Top 10 list for web applications in 2021 and occur when an unauthorized user breaks through preexisting security barriers put in place to protect your data and applications. Weak or missing TSL/HTTPS - Lack of or weak encryptions is also a major cause of sensitive data exposure. Storing plain text files containing personal information onto your website leaves it vulnerable to exploits. SQL injection flaw - SQL injections occur when attackers introduce malicious queries into the system to extract information about users or other important details with a simple command. Phishing - Phishing attacks are designed to mislead users and get them to provide sensitive information via emails, instant messages, and text messages. Insider attacks - Insider attacks occur when current or former employees with authorized access initiate an attack by breaking in and stealing data, often going unnoticed because most organizations focus on outside attacks rather than those coming from within. How to Prevent Sensitive Data Exposure While web applications and web surfaces have their own vulnerabilities, however, Gartner predicts that APIs will be the main attack vector by 2022. To help prevent exposures, OWASP suggests you take these minimum steps against cryptographic failures (another name for sensitive data exposure). Identify, filter, and classify client data Avoid storing non-essential data Encrypt data at rest Update algorithms regularly Encrypt data in transit (with TSL) Disable caching for sensitive data Enforce authorization for all APIs (even internal) Address excessive data exposure vulnerabilities While these steps offer a great starting point, taking advanced measures will ensure your data is well protected. We recommend taking some advanced security measures. Advanced Recommendations Automated security - Use an automated end-to-end vulnerability scanning solution to improve your security posture by benchmarking web applications against the OWASP Top 10 list. Automated API testing platforms detect potential problems before they grow into something major. Continuous testing - Integrating security into software that includes continuous testing from development through production gives you complete coverage and ensures there are no loopholes for attackers to exploit.. As the world continues to accelerate development cycles, organizations should never compromise security to meet the demands of digital transformation. With APIsec, you won't have to. APIsec is the only platform that offers an automated, comprehensive way to test your company's API security. With ten times the coverage of manual pen testing, APIsec enables in-depth security assessments for your entire breadth of APIs. The automated platform tests against both known vulnerabilities and newly found threats to give you peace of mind with every vulnerability test. Reach out to a security expert and see how APIsec protects APIs from sensitive data exposures, or run a free API pen test to see how your API may be vulnerable right now.
May 5, 2022
5 mins
Rest API

Dan Barahona

Tutorials

Generating OpenAPI Specification (OAS) documentation for your REST APIs

The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection.[1] APISec supports 1.0, 2.0, 3.x versions of the OpenAPI specification (OAS) as well as Postman and RAML formats. The following is a list of some libraries and resources which can be helpful in generating an OpenAPI Specification (OAS) document for your existing REST API application grouped by implementation technology. ASP.NET Core The two main OpenAPI implementations for .NET are Swashbuckle and NSwag. They are explained nicely in the Microsoft ASP.NET documentation - ASP.NET Core web API documentation with Swagger / OpenAPI | Microsoft Docs The OpenAPI.NET SDK contains a useful object model for OpenAPI documents in .NET along with common serializers to extract raw OpenAPI JSON and YAML documents from the model - GitHub - microsoft/OpenAPI.NET Spring Springfox supports automated JSON API documentation for API's built with Spring - GitHub - springfox/springfox The springdoc-openapi Java library helps automating the generation of API documentation using Spring Boot projects - GitHub - springdoc/springdoc-openapi Java For JAX-RS based projects(Jersey/RESTEasy/Mule), Swagger Core provides examples and server integrations for generating the Swagger API Specification, which enables easy access to your REST API - GitHub - swagger-api/swagger-core The Swagger Maven Plugin is a JAX-RS & SpringMVC supported maven build plugin, helps you generate Swagger JSON and API document in build phase - GitHub - kongchen/swagger-maven-plugin Python Flask-RESTX is an extension for Flask which provides a coherent collection of decorators and tools to describe your API and expose its documentation properly using Swagger - GitHub - python-restx/flask-restx Falcon-apispec is an apispec plugin that generates OpenAPI specification (aka Swagger) for Falcon web applications - Github - alysivji/falcon-apispec drf-yasg - Yet another Swagger generator helps in automated generation of real Swagger/OpenAPI 2.0 schemas from Django REST Framework code. - GitHub - axnsan12/drf-yasg drf-spectacular is a sane and flexible OpenAPI 3 schema generation for Django REST framework - GitHub - tfranzel/drf-spectacular Node.js swagger-autogen performs the automatic construction of the Swagger documentation - swagger-autogen - npm NestJS provides a dedicated module which allows generating OpenAPI (Swagger) - Github - nestjs/swagger swagger-express is a simple and clean solution to integrate swagger with Express - swagger-express - npm express-oas-generator automatically generates OpenAPI (Swagger) specification for existing ExpressJS 4.x REST API applications - express-oas-generator - npm Hapi-swagger is a OpenAPI (aka Swagger) plug-in for Hapi When installed it will self document the API interface in a project - hapi-swagger - npm PHP swagger-php is a php swagger annotation and parsing library which generates interactive OpenAPI documentation for your RESTful API using doctrine annotations. - GitHub - zircote/swagger-php Ruby rspec-openapi generates OpenAPI schema from RSpec request specs - Github - rspec-openapi rswag seamlessly adds a Swagger to Rails-based APIs - Github - rswag zero-rails_openapi is a concise DSL for generating OpenAPI Specification 3 (OAS3) JSON documentation for Ruby application - GitHub - zhandao/zero-rails_openapi The grape-swagger gem provides an auto generated documentation for your Grape API - GitHub - ruby-grape/grape-swagger Swagger::Blocks is a DSL for pure Ruby code blocks that can be turned into Swagger JSON - .GitHub - fotinakis/swagger-blocks openapi-rails is a CRUD interface for Rails models with OpenAPI (Swagger) specification support and Swagger UI integration - GitHub - slate-studio/openapi-rails Go swag automatically generates RESTful API documentation with Swagger 2.0 - GitHub - swaggo/swag go-swagger (golang implementation of Swagger 2.0) is a complete suite of fully-featured, high-performance, API components to work with a Swagger API: server, client and data model - Github - Swagger 2.0 implementation for go APISec seamlessly integrates with most of the popular API gateways and automatically pulls the API specs in OAS format for easy API registration. For the purpose of document completion and developer curiosity, a select few are mentioned below. AWS API Gateway get-export is a CLI command to export OAS from AWS API Gateway - get-export — AWS CLI 2.4.27 Command Reference Google Cloud Endpoints Generating the OpenAPI document is described here -, Adding API management | Cloud Endpoints Frameworks for App Engine Azure API Management API developers can export API definitions in OAS format - Export API definitions from API Management developer portal | Azure updates | Microsoft Azure Apigee Edge Apigee Edge Proxy to OpenAPI 2.0 conversion tool. - GitHub - anil614sagar/apigee2openapi Postman Convert Postman Collections v2.1/v2.0 to OpenAPI v3.0 - postman-to-openapi - npm Help us improve this article by sending your suggestions and comments to support@apisec.ai. Thanks! References: OpenAPI Initiative
April 10, 2022
4 min read
Business Logic
API Design

Dan Barahona

Business Logic

How to Address Business Logic Flaws During Application Design

Business logic vulnerabilities often go undetected for years. Nothing makes cybercriminals happier than an application with vulnerabilities they can exploit without any special tools—simply working within the normal functionality of the app. Since most vulnerabilities are exposed in the development phase, catching them during the design phase will require new strategies beyond what has been the industry norm. “Without proper testing, you’re leaving those APIs exposed and just ripe for the picking.” - Corey Ball, Cybersecurity Consulting Manager & Author of "Hacking APIs" We’ve identified common business logic flaws and provided our top tips for eliminating them during application design. 1. Ensure Proper Authorization and Authentication Measures From Day 1 Attackers often gain access to sensitive data through vulnerabilities in authentication and authorization resources that they should not have access to. Here are the most common business logic flaws associated with this cluster of API threats and how you address them from the start: Unprotected APIs: Implement stringent authorization and authentication for all internal and staging APIs so they can’t be compromised to pivot to other systems. Weak credential policy: Restrict the use of insecure or previously exposed passwords to guard yourself against automated brute force attacks. Flawed credential recovery process: Ensure that permit recovery or credential reset can’t be triggered with insufficient information. Broken authentication: Make it impossible to view, modify, or remove the data of another account without the corresponding user privileges. Read More: API Security Checklist: What You Need To Know 2. Eliminate Data Input And Client-Side Loopholes Malicious attackers can alter a database query without using any exploits to make the application execute unauthorized commands. To combat this, we recommend evaluating the most common business logic flaws related to data input and client-side vulnerabilities. Critical parameter manipulation: Inspect HTTP request parameters (the values sent in the request body) to make it impossible to tamper them to query the database. Cookie tampering: Encrypt session and cookie data to prevent the attacker from reverse engineering business logic and modifying cookie parameters to launch a privilege escalation attack. LDAP injection attacks: Check LDAP parameters for any business logic flags to prevent bad actors from changing them to bypass the business layer. Client-side vulnerabilities: Examine your business routines embedded in JavaScript, Flash, or other client-side languages. Read More: Drilling Down Into Excessive Data Exposure: How to Protect Your APIs Sensitive Data 3. Eliminate Logic Flaws From Processes and Workflows When application workflows or processes have design flaws built into the business logic, users short-circuit them in unintended ways to bypass security checks and gain unauthorized access to data and functionalities. That’s why it's essential to meticulously test every action and task the user can perform to uncover potential loopholes. These business logic vulnerabilities would be a great starting point: Business constraint exploitation: Ensure that no hidden user fields contain values that control the constraints or restrictions defined by the business logic layer. Business flow bypass: Break down your application workflows to verify steps can’t be hijacked, skipped, or bypassed to perform a certain task. Denial of Services (DoS) with business logic: Check for the possibility of short-circuiting processes with infinite loops to overload or crash the system. Auto-increment IDs: Graduate from using automatically-incrementing identifiers when generating database records to make it impossible for the attacker to automatically harvest all of your records should you find your defense lines compromised. Read More: What Is API Privacy and How to Protect Your Sensitive Data 4. Ensure Critical Data Is Secured APIs and web applications often leak credentials and sensitive data without an organization ever knowing it happened. By following these best practices, you help to ensure that your API is secure: Identity extraction: Examine the parameters that control user profiles and make it impossible for the attacker to reverse engineer or guess tokens to harvest user data. Getting entire database objects: Ensure that the server returns only the values requested by the user, not entire database objects. Never leave data filtering to the client. Unauthorized file URL access: Dissect the mechanisms that generate temporary links to restricted files to ensure they can’t be reverse-engineered or hijacked with a custom API call. Read More: How Improper Assets Management Leaves Your APIs Vulnerable to Attacks The Only Automated API Security Testing Tool that Detects Business Logic Flaws Armed with this list, you will drastically reduce the likelihood and severity of data breaches caused by this vulnerability cluster. APIsec is the only fully automated API security testing solution that identifies business logic vulnerabilities at scale. By automating the process of identifying these flaws, APIsec helps organizations protect their applications and data from being compromised. If you want to learn more about how APIsec can help you identify and fix business logic flaws, contact us for a free demo.
April 10, 2022
5 min read
No items found.

Wesley Meier

Business Logic

Business Logic vs. Application Logic: The Key Differences You Need to Know

Business logic refers to the rules and procedures that govern a business, including things like pricing, discounts, inventory levels, customer eligibility, etc. Application logic, on the other hand, is the code that implements those business rules within a specific application. The key difference between business logic and application logic is that business logic is all about the data inputs based on your business, while application logic is all about how the user interacts with the app. For example, business logic is concerned with calculating interest on a loan, whereas application logic is concerned with what happens when the user clicks the "Get pre-approved" button on a website. To better understand why this distinction matters, it is important to fully understand how these logics function and how they work together to ensure that your applications are more reliable and scalable. What is the Function of Business Logic? Business logic encodes real-world business rules that determine how users interact with the application and how data should be created, exchanged, and managed. This code is typically written in if-then statements or decision trees and sits between the user interface and the database. It is responsible for ensuring that all data that passes through it is valid, consistent, and accurate. "If a user makes an out-of-state purchase over $500, flag the transaction as suspicious." Business logic should be written independently of the technology used to implement it. That way, if the technology ever needs to change, you won't have to rewrite your business logic. Or, if your business rules change, then alterations can quickly be made to the business logic. Business logic is also responsible for handling all of the behind-the-scenes work that needs to happen in order to keep the data safe and secure. If the logic isn't sound, a loophole occurs. This is known as a "business logic flaw," and it has serious consequences. What Goes Wrong with Business Logic? One of the most common problems with business logic is that it becomes outdated as a business changes. This leads to inaccurate calculations, bad decisions, or simply an inability to function correctly. Malicious actors frequently exploit business logic flaws. If there are security holes in the system, attackers use them to gain access to sensitive data, disrupt operations, or even take control of the entire system. Adopting security measures to test your logic for any loopholes or flaws is one way to protect your business logic. What is the Function of Application Logic? Application logic is the engine that bridges the gap between business logic and the user interface: It takes the back-end business logic input and turns it into the front-end output that the user sees. In short, the actions run with application logic have nothing to do with business, it simply outlines a series of actions triggered by an event. "If a user clicks this button, a tab will open in a new window." It contains all of the rules and processes that control how the user interacts with the data. Its main responsibility is to ensure the user interface is easy to navigate, providing a good experience. Unlike business logic, application logic is typically written in high-level programming languages, including C++, Java, or Python. This code is what makes the system work. Without proper application logic, an application would be nothing more than a bunch of disconnected code snippets. What Goes Wrong with Application Logic? The complexity of the programming in the application logic is what also makes it susceptible to errors. If the code is poorly written, if there are bugs in the system, or if the data that's being used is incorrect—the entire app can collapse. Since application logic is user-facing, any glitches will directly affect consumers. This could cause problems ranging from minor inconveniences to completely losing customer loyalty. The good news is that these bugs are much easier to find than vulnerabilities in business logic. How do Application Logic and Business Logic Work Together? Even though they each have distinct functions, business logic and application logic work together to ensure that a business runs smoothly and efficiently. Companies rely on both types of logic to automate tasks, keep data safe, and provide a consistent user experience. The two types of code are often combined within an application or program. For example, an e-commerce application might have business logic that defines the process for adding items to a shopping cart and application logic that actually adds the items to the cart. When an application needs to perform a task, it uses business logic to determine how to carry it out. The business logic will tell the application what rules to follow and in what order they should be performed. The application logic will then use this information to carry out those steps. The important thing to remember is that business logic and application logic need to work together in order for a company to be successful. They are essential for creating a successful web application that is both efficient and user-friendly. Read More: Why APIs Are Your Biggest Security Risk Protect Your Application from Business Logic Vulnerabilities with APIsec With APIs well on their way to becoming the primary attack vector in 2022, business logic flaws are the most dangerous type of vulnerabilities that can't be detected with traditional scanners and testing tools. APIsec is the only fully automated API security testing solution that identifies business logic flaws at scale. With thousands of attack scenarios tailored to the unique architecture of your APIs, APIsec investigates every corner of your API and leaves it completely covered. Reach out to a consultant to get set up with a free demo.
April 10, 2022
6 min read
No items found.

Dan Barahona

Business Logic

5 Real-world Examples of Business Logic Vulnerabilities that Resulted in Data Breaches

Business logic flaws are considered to be the most dangerous cluster of API vulnerabilities - and for good reason. While some vulnerabilities are relatively easy to spot with scanners and penetration tests, business flaws are typically hard to detect as they occur within the bounds of your system's legitimate functionalities. A rapidly growing list of organizations falling victim to major cybersecurity incidents resulting from business logic flaws serves as a cautionary warning for anyone overlooking thorough API security testing processes. Business Logic Vulnerabilities 101 A business logic vulnerability refers to a flaw in the design of an API that can be exploited to achieve a malicious goal. These flaws allow attackers to gain unauthorized access to sensitive data without turning to malware or exploits by using the API as it was designed in ways unintended by developers. Because of this, business logic flaws can go undetected for years without triggering any alarms, making them a favorite target for bad actors. That's why companies must have a process for identifying and fixing business logic vulnerabilities before they are exposed and exploited. Read More: Why Business Logic Flaws Are Your #1 API Security Risk These 5 Major Data Breaches Were Caused by Business Logic Flaws Companies that don't take data security seriously often find themselves in trouble. A data breach may result in a tsunami of lawsuits, massive financial losses, and permanent damage to an organization's reputation. In fact, nearly a quarter of Americans stop doing business with companies that have experienced a data breach. To help you avoid becoming a statistic, below we'll break down five real-world data breaches caused by business logic flaws and provide actionable tips on protecting yourself against them. 1. USPS Data Breach: 60 Million User Records Exposed In 2018, the United States Postal Service (USPS) became a data breach victim when a cyberattacker opened the system to allow anyone with an active account at usps.com to view - or even view modify - account details of other users. What Information Was Lost or Exposed? Approximately 60 million records of users were exposed as a result of this major data breach. The incident led to the unauthorized access of real-time delivery data, exposing all sensitive personal information on the affected accounts, including email addresses, user IDs, usernames, phone numbers, and street addresses. How Did This Breach Happen? The USPS data breach happened due to broken access controls in their informed delivery API. This business logic flaw allowed attackers - or any authorized user for that matter - to gain access to other people’s sensitive data without any exploits by abusing the flaws in the legitimate authentication mechanisms. How to Combat This Business Logic Flaw Companies can take several steps to protect their APIs from this business logic vulnerability - some of the best examples include: Authenticate all API requests to ensure that user A can’t access user B’s information. Adopting the zero-trust security model to monitor both unauthorized and authorized users. Eliminating Basic Authentication (the standard combination of a username and password) and implement OAuth, JWT, or OpenID instead. Avoiding auto-increment IDs to drastically reduce the severity of a data breach should one occur. Considering the use of short-lived access tokens. 2. Citi Data Breach: Over 350,000 Customer Records Stolen Since financial institutions contain large amounts of highly sensitive data that can be sold on the dark web, they have traditionally been a prime target for cybercriminals. In 2011, Citi announced the security of its online banking platform was compromised, leaking personally identifiable information. What Information Was Lost or Exposed? A seemingly minor vulnerability allowed attackers to gain unauthorized access to 350,000 customer records of North American cardholders. The breach exposed the names, account numbers, and contact information of the customers. While sensitive financial data was not leaked, the company suffered major reputational losses. How Did This Breach Happen? The data breach occurred due to a parameter tampering attack targeting their business logic layer. An attack using this method involves manipulating certain parameters exchanged between the client and server. In this type of attack, web elements like cookies, URL strings, and hidden form fields can hijack a request to the database and gain unauthorized access to sensitive data or elevate their user privileges. Read More: How Cybercriminals Acquired 350K Citi Customer Records (In-depth Analysis) How to Combat This Business Logic Flaw Several methods exist to prevent parameter tampering attacks on web applications and APIs: Ensure that the application or API validates and sanitizes all input parameters before they are used. Many techniques can be used to accomplish this, including regular expression matching, whitelist validation, and blacklist validation. Enforce cookie encryption to prevent parameter tampering. Do not include parameters in URL query strings. 3. HealthEngine Data Breach: 59,000+ Containing Personally Identifiable Information Leaked Black market sales of medical records are on the rise since they contain all of an individual's personal information. Fraudulent transactions and blackmail can easily be carried out using these data sets. Over the last three years, 93% of healthcare organizations experienced a data breach - including HealthEngine, a marketplace and review platform for healthcare services. What Information Was Lost or Exposed? The data breach exposed over 59,000 records of patients’ personally identifiable information. The incident brought the attention of the Australian Competition and Consumer Commission that went in to audit the company and fined HealthEngine $2.9 million for violating privacy and consumer laws. How Did This Breach Happen? The attacker didn’t need to use any sophisticated hacking techniques to harvest the records as the data breach was caused due to a pretty common vulnerability known as excessive data exposure. Excessive data exposure vulnerabilities occur whenever an API returns more information than a user needs to perform a given task or action. In HealthEngine’s case, the backend of the system sent healthcare practice review data along with all the personally identifiable information of the patient who had submitted the feedback. Since the client was responsible for data filtering, it was easy for anyone to analyze network calls to collect the records. Read More: How Cybercriminals Acquired Patients' Personally Identifiable Information from HealthEngine (In-depth Analysis) How to Combat This Business Logic Flaw Excessive data exposure is a common yet overlooked cybersecurity issue that plagues web applications and APIs. Consider the following measures to reduce the attack surface: Avoid returning entire database objects in API responses. Never rely on the client for data filtering - simply hiding certain fields doesn’t prevent cybercriminals from accessing them. Minimize the amount of data in your API responses to the bare minimum needed to execute a certain task. Make sure your error pages don't contain any information that can help bad actors identify your tech stack. 4. Symantec Data Breach: 23,000 SSL Certificates Revoked In 2019, Symantec, one of the largest cybersecurity companies in the US, found itself on the receiving end of a data breach, which resulted in severe reputational and legal repercussions. What Information Was Lost or Exposed? After thousands of private keys were exposed, DigiCert, a leading provider of digital certificates, revoked 23,000 Symantec SSL certificates. How Did This Breach Happen? The incident was caused by a broken access control vulnerability in the business logic. The API failed to properly validate whether a given user was allowed to access sensitive data. The compromised records allowed the attackers to perform Man-in-the-middle attacks. Read More: How a Common API Flaw Gave Attackers Access to Symantec's Customer Certificates (In-depth Analysis) How to Combat This Business Logic Flaw This business logic flaw can be averted by implementing the following measures: Analyze all possible ways for authorized and unauthorized users to authenticate to your APIs Implement rate-limiting to prevent automated attacks Enforce multi-factor authentication 5. Venmo Data Breach: Over 200 Million Transactions Harvested In 2019, the money transfer site Venmo (owned by PayPal) became a victim of one of the largest data breaches in recent years. What Information Was Lost or Exposed? Approximately 200 million transactions were exposed along with massive amounts of sensitive data associated with them as a result of the data breach. As a result, it was possible to analyze the entire transaction history of the compromised users, including the recipients, the amount of money sent, and even the purpose of those transactions. How Did This Breach Happen? The attacker scraped millions of Venmo payment records through their unsecured API that was leaking data. The developer API was open to unauthenticated requests, making it possible for anyone to harvest highly sensitive data. This business logic flaw is related to security misconfiguration, a cluster of API threats that ranks #7 on the OWASP API Security Top 10 list. This vulnerability occurs when an API is left unsecured or poorly configured, leaving loopholes for attackers to take advantage of. How to Combat This Business Logic Flaw Consider implementing the following security measures to protect yourself against this cluster of vulnerabilities: Limit administrative access across all of your APIs. Enforce authorization and authentications mechanisms for all of your APIs - even for private or staging assets. Eliminate insecure default configurations. The Only Automated API Security Testing Tool that Can Tackle Business Logic Flaws Business logic flaws are almost impossible to spot using vulnerability scanners and penetration testing since each API is built in a unique way. Popular API testing tools can only give you a surface-level view of the API while leaving critical issues unaddressed. That’s where APIsec comes into play. APIsec is the only automated API security testing solution that leverages the power of AI to deeply analyze your APIs, generate hundreds of custom-tailored attack scenarios, and execute them within minutes - not hours or days. This approach allows APIsec to successfully identify business logic flaws for a fraction of the cost of manual pen-testing. Sounds too good to be true? Get in touch with our team today to schedule a free demo.
April 10, 2022
6 min read
No items found.

Dan Barahona

Business Logic

Why Business Logic Vulnerabilities Are Your #1 API Security Risk

You may think it requires writing hundreds of lines of code to break through the most secure network defenses. In reality, cybercriminals typically gain access to your sensitive data through the standard functionalities of your API, used in a way you didn't anticipate. These loopholes are called Business Logic Flaws, and they are your biggest threat to your API security. What Are Business Logic Flaws? A business logic vulnerability is a flaw in an API's design that lets an attacker manipulate legitimate functionalities, data, or workflows to reach a malicious goal. Business logic flaws are so prevalent that four of the top five OWASP API attack vectors are related to this cluster of vulnerabilities, making it vital for you to understand how they work. From elevating user privileges to destroying databases, the key factor is that these flaws occur due to incorrect assumptions about how different parts of your systems work and interact. As a real-world example, a business logic vulnerability was the root cause of a massive data breach involving the United States Postal Service and 60 million records of sensitive user data, leaving a permanent mark on the organization's reputation. Read More: What is API Security and Why It's Important How Do Business Logic Flaws Happen? APIs are the pipelines that are allowed through the firewall. And if they're not tested properly, they could be vulnerable - essentially, by design - with business logic flaws. Corey Ball, Cybersecurity Consulting Manager & Author of "Hacking APIs" When an attacker tries to access your network systems using malware, SQL injections, or other techniques, even the most basic security measures will likely trigger an alarm and warn your security teams about an ongoing cyberattack. With business logic flaws, it's an entirely different story. Imagine a scenario where your dev team overlooks restriction protocols that allow HTTP request methods on the page displaying the current balance of a user's bank account. The attacker could potentially use the PUT method to edit the value or delete the record entirely. Since logic flaws like this happen within the bounds of legitimate API functionalities, they typically don't trigger any alarms until long after your data has been compromised - if ever. Businesses suffer financial losses, decreased customer confidence, damaged reputations, and even bankruptcy due to data breaches. Read More: What is API Testing Automation? What Are the Most Common Types of Business Logic Flaws? While business logic flaws are unique vulnerabilities based on the architecture of a given API, we can single out the most common types of them to help you stay ahead of cybercriminals. 1. Misusing HTML Elements and Other Client-side Code Web pages are often built using HTML, with dynamic elements that can be changed on the client-side using scripting languages like JavaScript. But these same elements can become a huge security risk when they are left vulnerable to manipulation by outside actors. If an attacker can alter these elements to make unauthorized queries, they can bypass any firewalls to access sensitive data. 2. Authorization Bypass A vulnerability known as authorization bypass allows certain users to access information that should be beyond their authorization level. Since this is a very broad umbrella of vulnerabilities, it's no surprise that many levels and instances of cyberattacks fall under this category. Broken Object Level Authorization (BOLA) is already #1 on the OWASP API Security Top 10 list - and for good reasons. API providers do a great job of ensuring that users are authenticated to the API, so they want to make sure that legitimate users have access. But the number one thing that's often overlooked is authorization, ensuring that user A can't access user’s B resources. And it's one thing to hide the resource IDs, but the important factor there is that user A should not be able to access, interact with, or alter user B’s resources - at all. Corey Ball, Cybersecurity Consulting Manager & Author of "Hacking APIs" The two most common subtypes of authorization bypass include: Lateral movement: accessing data of another account at the same privilege level Privilege escalation: accessing data that the current privilege level isn't supposed to have access to Strong authorization and authentication protocols - such as oAuth or OpenID - should be implemented to prevent authorization bypass and protect your systems against this attack vector. 3. Failing to Handle Unconventional User Input An attacker can trigger an unexpected response from your systems by providing inputs to an API that a developer failed to anticipate, potentially exposing sensitive data. Many APIs lack the security controls that other attack vectors have in place, making them the equivalent of the Death Star's thermal exhaust port: a path to doom and destruction for businesses. Corey Ball, Cybersecurity Consulting Manager & Author of "Hacking APIs" Businesses have to be very careful when it comes to handling unconventional user input and meticulously test for all data types, including unexpected values and characters. They can do this by running a series of fuzz tests to feed the systems with different kinds of random user input. 4. Putting Excessive Trust in Users Many IT systems trust their authorized users too much, creating a host of security potential security vulnerabilities. If an attacker can access the login credentials of real admin users - whether as a result of a phishing attack or by simply buying that data on the dark web - they can easily sneak in, access the database, and cause a data breach - similar to one led to the exposure of three billion Yahoo records. To keep yourself safe and protected, you have to assume that every user is a potential security threat, whether authorized or not. That's what the zero-trust security model is all about, ensuring that every user is properly authorized and authenticated - all while monitoring their behavior even after letting them in. 5. Domain-Specific Flaws Domain-specific flaws are the weaknesses in your system that are only present in a specific area. Unlike general vulnerabilities that affect your entire application, domain-specific flaws are only found within a particular module or function. This key aspect makes them harder to identify and fix because you need to deeply understand the objectives attackers may try to achieve by abusing domain-specific flaws. The more information you have about what your end users are doing, the easier it is to identify and flag suspicious actions accurately. A good starting point would be utilizing your API management tool's analytics and reporting capabilities to identify and analyze usage patterns. Read More: API Security Checklist: What You Need To Know How to Prevent and Test for Business Logic Flaws in Your API Security Effective API security testing is critical. And if we think back to the USPS data leak, that was tested a month before a leak of 60 million instances of private data. It’s not that you’re just testing APIs generically but that you’re using the right tools and techniques that will help your API security vulnerability management program to do a good job at preventing these sorts of attacks. Corey Ball, Cybersecurity Consulting Manager & Author of "Hacking APIs" Now that you know the most common types of business logic flaws, it’s time to do something about them. Here are some tips for testing for business logic flaws in your API security: 1. Ensure that Your Test Cases Cover All Possible Scenarios The first step towards ensuring that your API security is airtight is to craft as many test cases as possible to cover all possible attack scenarios. The more attack scenarios you test against, the higher the chances of identifying the underlying business logic vulnerabilities. That’s where you need a deep understanding of all aspects of your API to create test cases that actually move the needle. APIs have direct access to sensitive data. They connect to your application servers, your microservices, and your database applications, so they have to be really secure. And a lot of APIs are overpermissioned - with some of them, you don’t even realize they’re probably leaking credentials. Cecil Pineda, Co-Founder at CISO XC 2. Validate All User Input Treat user input as a security threat by default. This approach entails validating all user input, regardless of where it’s coming from or who submits it. That way, you’re protecting yourself from an entire layer of API vulnerabilities and drastically mitigate the risks related to insider threats. All invalid input should be logged and eventually monitored to uncover potential chinks in your armor that can lead to a data breach. The zero-trust security model has proven to be effective in reducing the number of cybersecurity incidents, so it’s a good idea to apply it to your APIs. Read More: What Is API Privacy and How to Protect Your Sensitive Data 3. Improve Your API Documentation Make sure that your APIs are adequately documented so that developers can understand how it works. This will boost your adoption rates and help you catch any errors or inconsistencies in your business logic. A well-documented API will make it easier for you to test for security vulnerabilities. 4. Monitor for Unusual Behavior and Review All Access Logs Regularly API logging and monitoring are absolutely vital to protect your users from cyberattacks. No system can ever be completely secure, so it’s crucial for your team to constantly track and analyze all auditable events - from failed logins to large transactions. Some user actions may point you toward a critical business logic vulnerability, so eye your logs like a hawk. 5. Use Automated API Security Testing Tools Automating your security testing is a great place to begin if you feel overwhelmed by this information or don't know where to begin. The problem is that business logic flaws are incredibly difficult to identify and detect, even when having a team of developers at your disposal. Often, your developers are the most expensive employees on your payroll. Popular API testing tools lack the depth needed to truly protect your APIs because security is not their specialty, allowing you only to automate the execution of thousands of test cases that you still have to create manually. That's where APIsec comes into play. APIsec runs on every release, not just once or twice a year with the pen test cycle, constantly updating the playbooks and making sure that any new code gets evaluated. APIsec is the only API security testing tool that automatically creates and executes thousands of test cases and actually makes it possible to identify business logic flaws based on the unique architecture of your API. Our customers ask us what we’re doing to protect their sensitive data on Seismic, and once they see what we have done with APIsec, their confidence grows. Tim Dzierzek, VP of Information Security Request a demo today to learn about APIsec’s one-of-a-kind technology to keep your APIs and data safe.
April 10, 2022
6 min read
No items found.

Dan Barahona

OWASP

How Improper Assets Management Can Leave Your APIs Vulnerable to Attacks

IT staff turnover is a normal part of doing business, but it’s also one of the biggest threats to API security. When employees leave your company, they take your organizational knowledge with them - which could include technical details that, when lost or overlooked due to improper assets management, lead to a high-risk API security vulnerability. Improper assets management is severe and common enough to regularly appear on the OWASP API Security Top 10 list of the most dangerous risks to your APIs. Keep reading to learn more about improper assets management and how you can mitigate the risk to your API security. What Is Improper Assets Management? Improper assets management is a security flaw that occurs when developers do not correctly document and manage their APIs. Improper assets management can occur when teams neglect obsolete APIs, use outdated or unpatched software, launch APIs prematurely, trust unsecured connections, or fail to vet third-party providers thoroughly. Improperly managed APIs are a prime target for cyberattacks because it is typically much easier to exploit them to access sensitive data and systems - and often can go undetected when APIs are no longer actively managed. How Improper Assets Management Flaws Occur & And How To Fix Them Improper assets management is a significant security threat to your business, but there’s a silver lining: it’s completely preventable. How you manage your company’s digital assets is up to you – and that means there are several measures you can take to avoid improper management and mitigate your security risk. Let’s look at the most common reasons this happens and how to avoid it for your business. Incomplete or Missing API Documentation Incomplete, inaccurate, or missing API documentation makes it easy to forget, overlook, and neglect proper security checks in the dev process. If the only person who understands how an API is built leaves the organization, a new team member is almost sure to miss critical flaws. The Solution: Keep An Up-To-Date Inventory of All APIs & Review It Regularly A simple but effective strategy requires your development teams to maintain accurate and up-to-date inventories of all APIs and related systems. Your team should record the location, purpose, security status, version, and access controls for every single digital asset they create – no exceptions allowed. Review your inventory regularly and take action to update security controls or decommission obsolete code as needed. We’ve already covered how knowledge lost during developer transitions leads to improper assets management and security risks. Avoid this problem by including processes to record and transfer essential knowledge when API developers leave your organization. Improper Management of User Roles & Responsibilities When you assign responsibility to everyone, you assign it to no one. When teams don’t know who is responsible for API documentation and security, they’re likely to leave it at the bottom of their priority list - focusing on consistently urgent fires that tend to pop up daily for most developers. The Solution: Clear Roles & Responsibilities It’s vital to have a clear understanding of who is responsible for managing different types of digital assets. Make sure everyone on your team knows who is responsible for securing and monitoring your APIs and other assets – and who is responsible for taking appropriate action if a breach occurs. Mismanaged Access Controls & Monitoring Unsecured APIs can provide cyber attackers with a foothold into your organization’s systems and data. Successful cyberattacks occur frequent;y because someone made public an API that should have been private. The Solution: Limit Access to All Public & Private APIs To avoid this, you should use a combination of role-based access controls (RBAC) and federated identity management (FIDM) to authenticate users, limit access to only those who need it, and control the type of actions users are allowed to take. Lack of Comprehensive API Security Throughout the Dev Cycle Insecure APIs and other asset management problems are missed due to a lack of comprehensive API security measures such as frequent testing and monitoring - often until a data breach forces you to examine your system's security. APIs are often hacked when they're in staging - these temporary pieces of code can and will become a security risk if they're not documented and maintained as well as more permanent ones. You can reduce your risk by constantly monitoring and controlling which APIs make requests to your data servers and what data they are accessing - but this can also be very resource-consuming when done manually. The Solution: Comprehensive API Security Testing API Testing software has revolutionized the way companies secure their APIs. APIsec specifically provides 100% automated, continuous API security testing that works at CI/CD speed. APIs are getting more powerful, versatile, and used in all kinds of industries, including financial services, healthcare, retail, and even professional services like legal firms. At the same time, cybercriminals are continually working on new tactics to breach and compromise data at firms of all sizes. With APIs becoming critical to the foundation of businesses, proper management of the APIs has never been more important. If you want a free vulnerability assessment of your APIs. Our experts will evaluate your network, answer your questions, and help you implement practical tools and effective strategies to keep your APIs secure. Reach out to us for a free vulnerability scan today.
April 10, 2022
7 min read
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

All the News Straight to Your Inbox

Sign up for APIsec’s monthly newsletter.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
This is some text inside of a div block.
This is some text inside of a div block.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.