What Is OWASP API Security Top 10: A Deep Dive

Keeping the data that gets shared between APIs private should be a key consideration for every organization. After all, APIs are critical elements of today’s multichannel customer experiences. They enable companies to gather, share and utilize data from third-party services to their advantage and also offer an avenue for monetization. However, APIs can also allow hackers to exploit customer data, which can be detrimental to the customer and to the business that failed to keep that information secure. In this article, we’ll explore why API privacy is crucial, some of the current initiatives that help organizations ensure their privacy, and show how they can effectively improve their APIs’ privacy. Why API Privacy Is Important Given the wealth of customer information shared via APIs daily, companies must understand the importance of API privacy. APIs are used to connect businesses, allowing them to share data and easily integrate third-party services. However, when these APIs become hacked, they can be responsible for major data breaches which expose sensitive customer data and company information. APIs drive almost every digital function that customers use today. They allow us to send money via mobile apps, track food orders on the way to our homes, and synchronize data across every device we use daily. This means that APIs are responsible for some of the most sensitive data one can imagine. Unfortunately, we’ve seen a growing number of public breaches that have specifically targeted APIs that are under-secured and over-permissioned. For example, when the money transfer site Venmo was breached in 2019, over 200 million transactions were harvested, which included tons of sensitive data. The hack occurred due to an unsecured API endpoint that required no user authentication. Another notable hack occurred in 2020 when dating site Bumble was breached, another open API endpoint without authentication enabling access to the data of 100 million users. But these breaches are only the beginning, as Gartner predicts that APIs will be the most frequent attack vector for hackers by next year. Due to the prevalence of API-related attacks that have already occurred and the likelihood that there could be more destructive attacks in the future, organizations must take steps to ensure the security of their APIs and, subsequently, their customer’s data. In order to assist companies, privacy regulations have been enacted across several domains. Below are some of the most important and how they relate APIs. GDPR Compliance for APIs When the European Union passed the General Data Protection Regulation Act (GDPR) in 2018, the aim was to give residents of the EU more control over their personal data. If a business held that data was within the EU, it was inconsequential, as long as that was where their customers resided. Failure to demonstrate compliance could result in fines of 4% of annual turnover or 20 million euros. For organizations outside of the EU, this meant that as long as they conducted business within the EU or had customers located there, they needed to be compliant. One of the requirements of GDPR is that data be “processed in a manner that ensures appropriate security of personal data, including protection against unauthorized or unlawful processing and accidental loss, destruction, or damage, using appropriate technical or organizational measures.” When it comes to guarding their APIs, companies need to take matters into their own hands. Considering there are no specific recommendations regarding APIs, organizations need to ensure that they are at the very minimum following API security best practices such as encryption, authentication, and monitoring. CCPA Compliance for APIs The California Consumer Privacy Act (CCPA) requires organizations to maintain control over what personally identifiable information is collected as well as how it is used and secured. The CCPA represents the first statute within the US that includes compensation for data breaches, which places added pressure on organizations to keep customer data secure. Requirements are that customers should be informed via privacy notices, terms of service, and data processing policies about what information is collected, disclosed, or even sold, as well as what the information collected will be used for. Protocols also need to be in place to enable customers to request, view, or delete their data if they so desire. Failure to comply could result in penalties ranging from $100 to $750 per violation, and considering that breaches could include hundreds of millions of users, that could become quite expensive. Like GDPR, there are no specific requirements related to APIs, yet organizations should conduct regular audits of their APIs and follow API security best practices. HIPAA Laws for APIs In 1996 when the Health Information Portability and Accountability Act (HIPAA) came into existence, it was essentially the first legislation specifically applied to health-related information. The rule establishes that organizations must safeguard the electronically protected health information (ePHI) of individuals. Penalties for violating the ruling can result in fines of $100 to $50,000 per violation. HIPAA applies to most workers within the US, health insurance providers, and employers that sponsor employee health insurance plans. There are three primary regulations for HIPAA. First, the privacy rule defines the standards for protecting ePHI in any format, even speaking. HIPAA establishes the security standards for ePHI at all times, whether that data is sitting in a database or transit. It also indicates the type and format of notifications if a breach occurs. When it comes to APIs, HIPAA essentially requires organizations to cover everything from how their API encryption keys are distributed to how ePHI is discussed by team members. Again, this requires organizations to follow best practices to keep their APIs secure at all times. APIsec: Assessing API Threats Before It’s Too Late The privacy guidelines outlined by GDPR, CCPA, and HIPAA are great starting points for any organization looking to safeguard its APIs. Unfortunately, many of the standard API best practices steps fail to properly secure APIs from threats that target logic flaws found within the API. As a result, a new approach is required. Most API security methods only identify potential vulnerabilities and breaches after an application has gone through to production or if a breach is already underway. With APIsec, you can use automated testing to find critical logic flaws in your APIs before it is too late. This continuous testing requires no human involvement and can ensure that your APIs are always up to the standard required by privacy regulations. Learn more about Best Practices for API Compliance & Privacy by reading our white paper.

With the introduction of APIs, companies now have a new way to expand their company's reach and also make it easier for customers to perform tasks. One of the most transformative shifts is the increased use of APIs to integrate data and information across channels, platforms, and devices. A well-designed API can be a key competitive advantage for your business. But what is an API? And what about the other pieces of the API ecosystem? This glossary will give you some short and handy definitions to understand more about APIs, cut through the jargon, and make the processes easier. API Application Programming Interface is what API stands for. API is a set of definitions and protocols that allow technology products and services to communicate via the internet. API Call The API call is simply the process of sending a request to your API after setting up the right endpoints. Upon receiving your information, it is processed, and you receive feedback. By entering your login and password into a website and hitting 'enter,' you made an API call. API Economy The API economy is just another term to describe the exchange of value between a user and an organization. The API economy enables businesses to leverage APIs from other providers such as Google to power their own apps, allowing an ecosystem that makes it possible for users to get value from a platform without having to build the APIs, like Uber does when it uses API calls to connect with Google Maps. API Endpoint An endpoint is the end of a communication channel. When APIs interact with other systems, each touchpoint of interaction is considered an endpoint. For example, an API endpoint could include a server, a service, or a database where a resource lives. API endpoints specify where resources live and who can access them. API Gateway An API gateway is an API management tool that serves as an intermediary between the client and a set of different backend services. API gateways act as gatekeepers and proxies that moderate all your API calls, aggregate the data you need, and return the correct result. Gateways are used to handle common tasks such as API identification, rate limiting, and usage metrics. API Integration In simple terms, API integration connects two or more applications to exchange data between them and connect to the outside world. API Keys An API key is a unique identifier that enables other software to authenticate a user, developer, or API calling software to an API to ensure that this person or software is who it says it is. API keys authenticate the API instead of a user and offer a certain degree of security to API calls. API Lifecycle The API lifecycle is an approach to API management and development that aims at providing a holistic view of how to manage APIs across its different life stages, from creation to retirement. The API lifecycle is often divided into three stages, the creation stage, the control stage, and the consumption stage. API Layer An API layer is a proxy that joins together all your service offerings using a graphic UI to provide greater user interactivity. API layers are language-agnostic ways of interacting with apps and help describe the services and data types used to exchange information API Portal An API portal is a bridge between the API provider and the API consumer. An API portal provides information about the APIs at every stage of the API lifecycle. API portals serve to make APIs public and offer content to educate developers about them, their use, and how to make the most of them. API Request APIs are everywhere and are part of every aspect of the web. An API request happens when a developer adds an endpoint to a URL and uses that endpoint to call the server or the database. API Security The ubiquitous nature of APIs makes them one of the favorite targets for hackers. API security is an umbrella term that defines a set of practices that aim to prevent malicious attacks, misuse, and exploit APIs. API security includes basic authentication and authorization, tokens, multi-factor authentication, and other advanced security measures. Apigee Apigee is an API gateway management tool offered by Google to exchange data across cloud services and applications. It enables developers to build and manage APIs. As a proxy layer, Apigee enables you to expose your backend APIs in abstraction or facade and helps protect your APIs, limit their rate, and provide analytics and other services. APIsec APIsec is an API security company. It leverages automated testing tools to find logic flaws before your code hits the production stage. APIsec addresses the business need to secure APIs before they reach production and provides the industry's only automated and continuous API testing platform that uncovers security vulnerabilities in APIs. Application The term application gets thrown around a lot these days. Application software is commonly defined as a program or a bundle of different programs designed for end-users. Every program can be called an application, and often the terms are used interchangeably. Burp Suite Burp —also called Burp Suite— is a set of tools used for penetration testing of web apps. Burp is an all-in-one penetration testing suite that offers users a one-stop shop for all their pen testing needs. BurpSuite contains an intercepting proxy that lets the user see and modify the contents of requests and responses while they are in transit for granular control of your APIs. CI/CD Continuous integration (CI) and continuous deployment (CD) are a set of operating principles and a collection of practices and agile methodologies that enable development teams to deliver better and faster changes to their code. CI/CD is one of the most important DevOps practices as it gives teams the tools to focus on meeting their business requirements, code quality, and security needs. CRUD CRUD is an acronym for create, read, update and delete. It refers to the necessary functions to implement a storage application, such as a hard drive. Unlike random access memory and internal caching, CRUD data is typically stored and organized into a database, which is simply a collection of data that can be viewed electronically. Cache The cache is a software or hardware component that stores data so users can access and retrieve that data faster. Cached data might be the result of a copy of certain data stored elsewhere. Cache reads data and retrieves it faster than you would otherwise. Client A client is a device that communicates with a server. A client can be a desktop computer, a laptop, a smartphone, or an IoT-powered device. Most networks allow communication between clients and servers as it flows through a router or switch. DDoS A distributed denial of service (DDoS) attack is a malicious attack that aims at disrupting the target's traffic. It usually overwhelms the target's infrastructure with a flurry of internet traffic aimed at saturating the servers and causing them to shut the page down. DevOps DevOps —a blending of development and operations— combines cultural philosophies, agile practices, and tools. DevOps practices aim at increasing an organization's ability to deliver software products and services faster than ever before. DevOps uses a toolchain made of interconnected technologies to build a software development infrastructure based on automation to achieve greater time-to-market speeds. DevSecOps DevSecOps —a blending of development, security, and operations— refers to the automation and integration of security at every step of the DevOps lifecycle, from the initial design process all the way to software delivery. DevSecOps emphasizes the need for proper security practices along the pipeline to enhance accountability and minimize data breaches. Developer Portal Developer portals are interfaces that bridge the gap between API providers and API consumers. It's called a developer portal because most of the API consumers are developers. Developer portals aim at educating developers on how to use APIs and provide all the information users need to leverage APIs. External APIs An external API is designed to be accessed by the outside public. Unlike internal APIs, APIs are consumed by external developers outside of the company. External APIs represent a secure way of sharing information and content outside a company. Framework A framework contains libraries of code, instructions, and APIs from which developers and API consumers can obtain information from an app. GET Method There are two ways to structure HTML (HyperText Markup Language, GET, and POST. GET refers to a method for requesting information from a particular website using HyperText Transfer Protocol (HTTP). You can also use it to derive a specific variable from a group of variables. GraphQL GraphQL is a query language that enables clients to define the structure of the data. That means that developers can use GraphQL to ask for specific data and return that data from multiple sources. HTTP Methods POST, GET, PUT, PATCH, and DELETE (or methods are formally called) are the most common HTTP verbs or actions. In other words, they represent Create, Read, Update, and Delete (or CRUD) operations within a database. JSON JSON (JavaScript Object Notation) is a lightweight data-interchange format based on a subset of JavaScript programming language standards. JSON has the advantage that it is both easy for humans to read and write and for machines to parse and generate. It is a format that is completely agnostic to languages and uses conventions that are familiar to programmers of C-family languages. Logic Flaw Business logic flaws result from faulty application logic. In simple terms, a logic flaw happens when an application, be it a web or mobile) behaves unexpectedly. A logic flaw allows attackers to misuse an application and circumvent its rules to change how it performs. Microservices Microservices —also known as microservices architecture— is a software architecture style that structures apps as a collection of loosely coupled, independent, and highly maintainable services that are organized to enhance an app, website, or platform's business capabilities. Monetization API monetization is a process by which a business can create revenue from its APIs. Since APIs enable users to access and integrate data from different sources, they can be used by different developers to integrate relevant services within their products, digital services, or applications, which could, in turn, become a source of revenue for both public and private services and applications. OWASP OWASP (Open Web Application Security Project®) is a nonprofit organization dedicated to enhancing software security. OWASP offers a range of tools to help developers and programmers secure the web through open-source software projects, hundreds of local chapters worldwide, and educational and training events. Over-Permissioned Container An over-permissioned container is a container that has all the root capabilities of a host machine. That means that it can access resources that aren't accessible to ordinary containers and users. The problem with over-permissioning is that it gives malicious actors a point where they can attack your infrastructure and compromise your implementation. Parameters Parameters are special types of variables used in computer programming to pass information between procedures and functions. An argument to a function is referred to as a parameter. Adding three numbers, for example, may require three parameters. Penetration Testing Also called pen testing or ethical hacking, penetration testing simulates attacks on your computer system to identify exploitable vulnerabilities. Pen testing identifies, tests, and highlights vulnerabilities in an organization's security posture. Web application firewalls (WAF) are generally augmented by penetration testing in the context of web application security. Production Environment In a production environment, software and other products are actually put into operation in how their intended users intend them to be used. Developers generally use this term to refer to the setting where end-users will actually use the products. In a production environment, software programs and hardware are run in real-time, and they are relied on daily by organizations and companies for their daily operations. REST Created by Roy Fielding, a computer scientist, REST, which stands for representational state transfer, is an application programming interface that conforms to the constraints of REST architectural style and enables a quicker interaction between different RESTful web services. A stateless Web service must be able to read and modify its resources using a predefined set of operations and a textual representation. Red Teams Red teams are cybersecurity professionals trained in attacking systems and breaking into them by finding compromised entry points or exploitable logic flaws. The objective of the red team is to improve a company's cybersecurity standing by showing it how they managed to gain access and exploit their system vulnerabilities. SDK SDK stands for software development kit and is a set of instructions, integrated practices, pieces, code samples, and documentation that enables developers to create software applications on a specific software platform. SDKs can be seen as workshops with everything developers need to build specific software for a determined platform. SDLC SDLC —also called software development lifecycle— is the process for planning, creating, testing, and deploying an information system. SDCL aims at producing quality software at the lowest cost in the shortest time possible. SDLC gives developers a structured flow divided into phases to help companies produce high-quality software. SOAP Simple Object Access Protocol (SOAP) is a protocol specification for exchanging structured information to implement web services. SOAP leverages XML Information Set for message format and other application-layer protocols, such as HTTP or SMTP for message transmission. The messaging services provided by SOAP are exclusively XML-based. Microsoft originally developed the SOAP protocol to replace old technologies such as Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (CORBA) that cannot work over the internet. SQL Injection An SQL injection technique is a way to inject code into a database that may damage it. SQL injections are one of the most common web hacking techniques and rely on the placement of malicious SQL code in SQL statements via web input using forms or other editable fields. Webhook A webhook (also called a web callback or HTTP push API) is a way for an app to provide other applications with real-time information. Webhooks deliver data directly to other applications, so data is available immediately instead of standard APIs requiring frequent polling for real-time data. Webhooks are beneficial to both consumers and providers in this way, but the only drawback is the difficulty of setting them up at first. ZAP Also called OWASP Zed Attack Proxy (ZAP) is one of the world's most popular free security tools, which lets you automatically find security vulnerabilities in your applications. With ZAP, you can also do nearly everything you can do with the desktop interface using its powerful API. By automating penetration testing and security regression testing, developers can automate an application's security testing during the CI/CD process. Conclusion If there’s a term missing here? Talk to us. If you’re looking for automated API security, set up a free pen test.

APIs occupy a significant position in software application architecture. They have revolutionized the way web applications are used by building communication pipelines between multiple services. With the growing need for new and disruptive digital solutions, it is ever more critical to ensure the security of APIs. According to a study by MIT of a major banking data breach, despite investing heavily in IT infrastructure and efficient security systems, the bank faced a severe unauthorized external intervention that exposed customer information. The resulting breach affected around 100 million individuals in the United States and approximately 6 million in Canada. The effects of these types of security breaches cannot be underestimated, and APIs continue to present a dangerous entry point for cyberattackers. This article will discuss API security and examine some of the fundamental reasons why API security strategy is a critical part of the application development lifecycle and infrastructure in today’s world. What Is API Security? API security is a set of best practices aimed at protecting an organization's APIs. Apart from the infrastructural security parameters, companies should also secure APIs programmatically at the application logic level. Appropriate API permissions and rules should be in place to ensure that only the desired audience consumes the right kind of permissible APIs. Why Is API Security Important? APIs are the backbone of today’s digital ecosystems. They are deeply integrated into software systems and are a significant driving force behind successful application execution. Since the software industry is widely dependent on APIs, it becomes a necessity for organizations that provide access to APIs to make them more secure and trustworthy. Nowadays, typical client-server applications exchange information using APIs. Moreover, third-party API consumption is also a very popular model of integrating APIs with existing systems. At the end of the day, it all boils down to how we can securely manage such processes and integrations to provide a smooth, transparent, and trustful user experience. Apart from the conventional client-server or third-party communications, APIs are also the key stakeholders in microservices which is the most disruptive and frequently used application architecture model these days. Hence, securing the APIs to reduce their chances of being attacked and contributing to a transparent API economy becomes a responsibility that businesses simply can’t avoid. Differences Between APIs and Web Interfaces When it comes to matters of security, APIs and web applications have a few differences that must be addressed. For instance, for web interfaces, the security parameters revolve around the phenomenon of downloading and displaying the entire web page as a single unit. As a consequence, the tools designed for such applications are optimized to serve the purpose of securing these types of models. On the other hand, the revolution of client-server communication with APIs brought its own challenges. The tools built for securing web interfaces can’t be directly used to secure APIs because of the basic underlying infrastructural change. APIs are more programmatic, making them a lot more exposed to hacker intervention and automation. Here’s a handy table that compares both: ‍Web ServicesWeb APIsBandwidth usageUsers more bandwidth over the internetUses less bandwidthClient-server couplingTighter server-client couplingLooser client-server couplingData formatsXML onlySupports multiple formatsSecurity optionsNumerous security optionsLess but more mature security optionsBest suited forSystem-to-system communicationUser interface to system communication Common API Security Mistakes Most APIs are made available to the public for consumption. However, when providing access to APIs, businesses must be wary of these common security mistakes: Logic Flaws A significant portion of the API security breaches in many instances is caused by logic flaws and vulnerabilities. Development and operations teams often ignore the impact of logic flaws and use the tools for security that only test the infrastructural layer and protect it. However, the business logic layer is even more susceptible to security vulnerabilities and the main target for hackers nowadays. Too Much Reliance On Specifications A common mistake while securing APIs is to rely on specification-based automation tools. These tools rely on exact specifications, which isn’t applicable to logic flaws. Inline Security Solutions Relying on inline security solutions also does not prevent logic vulnerabilities from being exposed before deploying to production. Delaying Automation While manual pen-testing is often used by organizations to protect their APIs, it can be time-consuming and also doesn’t occur often enough, leaving organizations susceptible to vulnerabilities. How to Tackle API Breaches Knowing about API security and figuring out the potential security mistakes is not enough. Whether you are a small company or a large enterprise, finding ways to effectively manage the security of your APIs is the most important part of this discussion. As we advance towards more and more digital involvement and infrastructure improvements, preventing API security breaches using automated and reliable in-house or third-party tools must be your utmost priority. The most important aspect of securing an API from a cyberattack is to protect the logic written inside the APIs. It is extremely important to expose the logic flaws and vulnerabilities before deploying the system to production. As soon as the system is deployed and is made available over the network, there are millions of hackers out there looking for opportunities to intervene in your system, steal important information, and break the system. While common vulnerabilities such as SQL injections or XSS attacks can be prevented using firewalls and occasional pen-testing, attacks that target APIs specifically are growing in frequency. Therefore, enterprises need to rely on tools that help them test the application and figure out potential logic vulnerabilities before even shipping to production. Strengthen Your API Security With APIsec If you have understood the importance of API security and are concerned about API breaches and want to prevent them, APIsec is the tool you should be looking for. With APIsec, you can find critical API logic flaws with automated testing before even deploying the system to production. Apart from automating the manual pen-testing and static and dynamic AppSec testing, APIsec is the finest solution to find data logic vulnerabilities with continuous and automated testing with zero human involvement. The best part about APIsec is that it does not require access to your code in any manner yet allows you to find logic flaws in efficient ways. To know more about APIsec and how you can use it for securing your API logic layer, please download our Best Practices guide.

In DevSecOps, everyone is responsible for software quality. Having a methodology for security mitigates risks and serves both business stakeholders and software developers by adding an extra layer of protection to the development process. APIs make computer to computer communication possible, which means that they present an avenue cyber attackers could use to access your or your clients’ data. For DevSecOps professionals, securing APIs is paramount to a healthy software development lifecycle. Plus, given the rapid pace of development with APIs, it is critical to ensure security is integrated into the CI/CD process. This article talks about what is DevSecOps and how it makes API security possible. We will also talk about how to secure APIs and build a plan for API security across the development lifecycle. What is DevSecOps? Coined in 2013 at the OWASP App Sec Conference, DevOps methodology combines agile software development, security, and operations. It’s about integrating security best practices into the development cycle to mitigate cyber threats. According to Gartner, “DevSecOps is the integration of security into emerging agile IT and DevOps development as seamlessly and as transparently as possible.” DevSecOps aims both at creating processes around security and, at the same time, builds security culture and practices in every organization to enhance the agility and security of the development process. DevSecOps rests on four pillars: Governance: Establishes security guardrails and monitors results. People: Breaks down silos between security and the DevOps team and instills cyber awareness. Processes: Orchestrates an integrated process flow and drives feedback Technology: Automate recurring security tasks and harden the development pipeline. Why Integrate DevSecOps and Security Into Your Application Lifecycle? While software developers’ ability to deploy applications has improved in both scale and speed, security considerations have been overlooked in favor of meeting the ever-increasing business demands. This preference for improved business outcomes at a greater speed results in security vulnerabilities in the development process representing entry points for cyber attackers. This is where DevSecOps comes to the table, enhancing application security to keep pace with operations. DevSecOps helps to create an ecosystem that aligns business goals with proper execution on the technology side. However, to stay true to release dates, software developers often realize that there’s not much time left for proper security practices and security testing, which is when security concerns start appearing. Remediating vulnerabilities that weren’t identified during the early stage of your apps’ lifecycle can cause release delays, issues with your development team, and disgruntled users and business stakeholders due to the potential monetary losses delays in the release date can incur. Even worse, sometimes development teams circumvent DevSecOps best practices and ship code to production without testing and security scans, regardless of the results. The truth is that no business can afford for software security checks to be the final piece of an app’s lifecycle; especially when it’s straightforward for cybercriminals to find an exposed API endpoint that can be exploited, causing reputation and financial damages to a business. The Importance of API Security in DevSecOps Security is not just making sure that you are doing what the regulator’s asking you to do. It means making sure that you’re doing everything to protect the information of your company. APIs are an often overlooked part of that security process, which can be especially costly because APIs are everywhere. According to Akamai, 83% of internet traffic is API-based. This tremendous adoption of APIs as the vehicle for internet traffic has led to an increase in attacks on API endpoints. In fact, research by Gartner shows that by 2022, 90% of cyber attacks will target APIs. While it’s possible to secure APIs on the client end, and there are indeed plenty of security technologies to scan, firewall, and protect web apps and APIs, the thing is that APIs aren’t just powering our web and mobile interfaces. They’re also exposed as public APIs or externally visible APIs that customers and partners can integrate with. While they enable an unparalleled level of connectivity, they also present a backdoor for attackers. APIs offer direct access to the most sensitive backend data, so if a cyber attacker has been able to gain access to the API layer, it has bypassed a lot of the security controls and now has access to sensitive data. However, APIs cannot be secured in the same way as other applications. Standard security prevention methods that protect against other vulnerabilities like SQL injections or cross-site scripting don’t hold up against threats that attack API logic. When hackers search for flaws in application logic, they don’t rely on basic injection attacks. These logic flaws can be damaging to APIs and lead to massive amounts of personally identifiable information (PII) data being lost. DevSecOps ensures that security is integrated into every stage of the development journey and the app’s lifecycle, bolstering security across the development process, keeping APIs, the most sensitive point of entry, safe. Learn about other API Security Best Practices by downloading our whitepaper. Securing The API Lifecycle You can secure your APIs at three points of their lifecycle: at design time, test time, and run time. We will cover two categories: security vulnerabilities and business logic flaws. Design time At design time, it is possible to run StaticAppSec testing to uncover code vulnerabilities, but you will get plenty of false positives because the app isn’t running yet. Test time You can run DynamicAppSec testing at test time, which is great for finding SQL injection vulnerabilities, cross-site, Denial of Service, and similar vulnerabilities. At test time, it is possible to run manual testing such as penetration tests. Run time At run time, it is possible to secure APIs by looking at their gateways and firewalls. By running these tests, you can find unknown APIs and anomalies. For example, by looking at normal traffic, it’s possible to find DDoS attacks and abnormal bot traffic, but this can introduce latency to the server. Building a Plan for API Security Automation API security automation takes a different approach to traditional security solutions. Here are some requirements: Make It an Ongoing Process First of all, API testing must be continuous and run all the time, against every build, not every few months by pen-testers. When testing is done so infrequently, it can leave gaps that hackers can exploit at any time. Ensure Comprehensive Testing Testing must be comprehensive and not simply include testing of a few critical endpoints as hackers can choose to attack at any instance. Therefore, you have to get full coverage of the API, including every endpoint, attack method, variable, and attack vector. Identify Logic Flaws While standard security vulnerabilities are necessary, these can’t be the only thing that an API security automation tool identifies. Today, hackers choose to focus on flaws in the data logic and exploit those to breach APIs. Consequently, data logic flaws need to be identified when conducting API security automation. Begin Pre-production Waiting until production to discover API threats, whether data logic flaws or otherwise, can create bottlenecks that negatively impact how quickly organizations can roll out new applications. By beginning the API security automation process during pre-production, you can avoid these bottlenecks and maintain the pace of application deployment. Planning API Security with APIsec To start planning your API security with APIsec, you need to do four things: Register your APIs This means you simply have to point us at your gateway and hand over a definition file, whether it’s Open API, Swagger, Postman, or any other. What we need is a glossary of your API endpoints and the methods they support. With that, we will analyze your entire API and build a roadmap for your APIs’ functionalities and capabilities. Create API Attack Playbooks We auto-create thousands of tech playbooks mapped to the OWASP API Security Top 10, exercising every single one of the endpoints and every method during the second step. Run Attacks to Find Vulnerabilities Then we run those attacks. The goal is to pressure test the API in every possible way to find ways to get it to leak data or provide unauthorized access and functionalities. Integrate With Continuous Integration/Continuous Delivery As we discover vulnerabilities, we auto-create tickets to push into JIRA, GitHub, or ServiceNow to push this API vulnerability and logic flood detection into the developer cycle so that they don’t ever make it into production. And all of that in a zero-touch environment, as we don’t need access to your API endpoints. We combine these four categories with our knowledge of your API to auto-fabricate thousands of unique, custom-made attacks to your APIs. With APIsec, you can come in and view and modify every one of those attacks and integrate them into your ticketing and orchestration systems. Read More: API Security 101: Establishing and Managing a Secure API Program Seismic: Building API Security Into The Dev Pipeline Seismic is a cloud-based sales and marketing automation and enablement tool. Seismic’s customers trust the company with very sensitive, confidential data; thus, they need to make sure that data is not accessible to anyone else. Seismic has built its service around APIs and exposes them to customers to integrate with the tool and enable their own workflows. To help the company’s data stay secure, we deployed APIsec into their staging environment. So whenever new code pushes into staging, they’re automatically pushing that code into those APIs into APIsec. Then, we build and execute those new playbooks, find vulnerabilities, and then integrate the results back into the development toolchain, which has enabled Seismic to eliminate a lot of their manual pen testing efforts and get a full ROI in just three months. If you want to read more about APIs and how DevSecOps reduces your API infrastructure’s vulnerabilities, read our white paper on API Security Best Practices or watch our recorded webinar on Best practices for building security into your APIs.

With data breaches and cyber-attacks occurring more frequently, the need for regular, intelligent, and thorough penetration testing is at an all-time high. Industry experts agree that 2020 saw a noticeable shift in cyber-attack methodologies and tactics, with APIs now accounting for 40% of the attack surface for all web-enabled apps. Global brands and United States government agencies such as the US Postal Service and IRS have all suffered API-related breaches in recent years. Current prevention mechanisms have struggled to keep up. API-related attack mitigation techniques are possible and strongly encouraged by practitioners closely aligned with OWASP. To prevent further API-related breaches and replace inefficient manual pen-testing, APIsec has launched its Automated Penetration Testing capability. Automated Pen-Testing automatically learns about an application's APIs, detects changes, and continually mounts attacks, mimicking tactics deployed by red teams and hackers. What is Penetration Testing (And Why Does it Need Automating?) Penetration testing, or pen-testing, is an authorized and simulated cyberattack on a website, an application, APIs, or any other system. The system owner authorizes the "attack" to test the security measures in place and discover hidden security flaws. Increasingly, organizations have prioritized attacking the API layer that connects Web, mobile, and machine-to-machine interfaces. In the on-premises software era, software vendors deployed, secured, and upgraded their applications within their corporate networks. Vendors released software annually and aligned manual penetration testing to those schedules. Those tests were subsequently scheduled to repeat on an annual or bi-annual basis. This changed with the advent of the cloud and SaaS products. Software is no longer on-premise with a tightly coupled frontend and backend. Instead, most modern applications are cloud-based, fundamentally relying on APIs to communicate with various backends, databases, and subsystems. Furthermore, Web and Mobile applications are leveraging a common API layer. As a result, unsurprisingly, hackers, red teams, and penetration testers have shifted their focus and TTPs to the API layer, while software developers have been slow to expand their defenses to APIs. Manual pen-testing is typically an infrequent monitoring methodology that leaves a large window of opportunity open to cyber-attackers, leading to potential data loss and breach. After all, manual pen-testing that takes place annually, or even quarterly, simply cannot keep up with the pace of software releases or even the pace of cyber-attack evolutions. By the time a pen test is run, the software in question has already been in production for months and has changed numerous times. As a result of these outdated pen-testing protocols, notable breaches have occurred: Venmo: Hackers scraped millions of Venmo payment data via an unsecured API endpoint that was leaking data. Bumble: An insecure API was allowing malicious hackers to download Bumble’s entire user base. Hackers were also able to bypass paying for premium features. USPS: An informed delivery API exposed the data of over 60 million users through broken access controls. Automated Pen-Testing: The Final API Security Solution for SaaS APIsec’s Automated Pen-Testing solution is an alternative pen-testing strategy that is aligned with contemporary web development practices. It ensures vulnerabilities are detected and fixed before they get to production. APIsec’s Automated Penetration Testing feature automatically and instantly: Learns each application’s APIs and creates thousands of custom attack scenarios Discovers and prioritizes API vulnerabilities based on their severity Performs continuous pen-testing based on automatically created playbooks Detects new API changes and creates missing tests Opens tickets, verifies fixes, and closes tickets Generates a compound Pen-Test Report PDF, detailing new, existing, and closed security issues The above benefits are possible thanks to APIsec’s machine-learning engine, which can automatically analyze and understand any modern API and execute bespoke pen-tests as a result. APIsec also brings about tangible business value in three parts: Reduced manual pen testing costs Simplified security compliance Enablement of frequent releases with automated security working in the background of your CI/CD operations, speeding up agile development processes APIsec doesn’t stop there, though. When vulnerabilities are uncovered, APIsec automatically provides a detailed description of the attack playbook used, giving the client an actual “recording” or wire logs of the successful attack, along with remediation recommendations. Engineers never have to waste time investigating issues; instead, they can focus on remediation of the underlying problem. Modern Software Requires Modern Security Cutting-edge software relies heavily on API calls for basic functions, data delivery, integrations, and more. That growing reliance on APIs is precisely why hackers are targeting the API layer more and the frontend presentation layer less. By continuously testing and reporting on the health of your API layer, an area often neglected by software developers, you can mitigate risk minute by minute, not year to year. Learn more about securing your APIs against malicious attacks by reading our white paper, “Best Practices for API Security”.

Technology has been changing rapidly and providing organizations with an unprecedented level of speed and benefits. As organizations embark on their digital transformation journeys, APIs are being leveraged in several different ways, becoming increasingly to the overall customer experience. However, many enterprises have become accustomed to the security provided for them through their legacy applications. They are searching for a way to achieve the level of protection needed even as technology continues to advance rapidly. In a recent webinar, API experts from Google Cloud, Allstate, APIsec, and Achieve Internet sat down to discuss how to integrate API security testing into the CI/CD pipeline and gain real-time visibility into API security issues. This article will summarize that webinar which also provided a review of the most common API vulnerabilities, including business logic faults, role-configuration issues and other non-conventional flaws. The Current State of APIs and API Security Historical Shifts There has been a dramatic shift in the API landscape of how organizations view APIs. As Shawn Smiley, CTO at Achieve Internet pointed out, APIs were only used by development teams to facilitate their internal processes. As a result, there wasn’t much consideration as to the ramifications of those APIs getting exposed. However, as the internet has grown and organizations have found new ways to leverage their APIs, things have become siloed, providing more opportunities for hackers to exploit vulnerabilities. Now, organizations are becoming more proactive, trying to find ways to thwart attacks before they happen. The OWASP API Security Top 10 and various other organizational and federal mandates around security have changed the focus of the API security landscape and dedicated businesses expand their API ecosystems outside of development teams. Ongoing Journey For Byron Williams, Principal Engineer and API Evangelist at Allstate, there is a need to develop best practices across enterprises to provide a consistent way of doing things. APIs should have a standard way of being delivered, a consistent look and feel, and ease of use. At Allstate, their journey involves setting up an API center for enablement that brings everyone within the organization together from the bottom up instead of the top-down. This creates an open-source environment where all learning and best practices can be established to deliver consistent APIs throughout the industry. As a legacy insurance company, they’ve been able to use APIs to provide roadside assistance to customers through a connected car app, removing the need for calls to go through a call center. Eventually, this will open up the opportunity for Insurance as a Service, enabling them to bring all APIs into one ecosystem, making them scalable, robust and secure. Part of the Customer Experience Sachin Kalra, Solutions Architect at Google, working on Google’s APIgee API management platform, explains that APIs have become part of the customer experience. As the connected experience continues to proliferate across different devices and various touchpoints, organizations are looking for a platform to help make the digital transformation journey. Legacy Becoming Microservices Brick and mortar companies have been embracing APIs as part of their modernization efforts, turning monolithic applications into microservices and containers. Dan Barahona, CMO and VP of Business Development at APIsec, points out that this is all driven by APIs. These organizations now recognize that security needs to be prioritized, as APIs form part of IT operations’ mission-critical aspects, including how the backend is being run, how sensitive data is stored, and how transactions are managed. API Security Concerns So what are the common API security concerns organizations need to be aware of? What keeps the experts up at night? Overall Security Data needs to be secured in all instances. Whether internally or externally, organizations need to take a proactive approach to monitor analytics to uphold their APIs’ integrity and confidentiality, whether they are in use or not. Personal Security and Government Breaches Are we as secure as we need to be? Many organizations have a ton of personal identification information, including social security numbers and other details about their customers. If that data is breached, it can be detrimental to a brand. Therefore, brands need the appropriate logging and monitoring systems to determine if a hacker has access to API keys. They need the ability to protect these keys, authenticate and monitor activity to know about breaches before they happen. How Attacks Are Being Carried Out API attacks and breaches are becoming more publicized, with hundreds of millions of records being exposed and harvested each time. However, the successful breaches are now different to what many security experts are accustomed to. Classic vulnerability breaches such as SQL injections and cross-site scripting are being left behind for logic flaws and loopholes. These types of attacks are harder to discover by a researcher or be found on a CVE list. In a rush to push functionality and code, security doesn’t always keep up. These loopholes are also tricky to find with standard firewall or code scanning types of approaches. Embracing Organization-Wide Security Coordinating an API security program development teams to various businesses and sub-organizations can be a challenging undertaking. However, there are some ways to create general security practices and maintain consistency throughout the organization. Creating a Center for Enablement By putting together a central source of best practices, authentication methods are fed from the bottom up, enabling organizations to gather information from those persons writing APIs. These API producers are involved in creating the best practices and can identify security issues that can come up to keep everything as secure as can be. Privileges and Accessibility When an application or service with multiple users and others with lesser privileges begins to access a service, organizations need a management solution to provide capabilities that enable them to mitigate risks and provide strong authentication and session management. Just implementing API key validation isn’t enough. There needs to be a layered approach where key validations are complemented with OAuth or JSON web tokens to protect against internal and external issues. Setting Rules and Guidelines Each API has a unique purpose, audience and objective security requirements. Organizations need to have a way to manage these APIs and create a central repository. For security, however, the manual approaches for finding vulnerabilities such as pen testing need to be augmented with tests that find leakages in other areas. Best Practices for API Security Single Source of Truth Organizations need to incorporate into their CI/CD processes ways of publishing API documentation into a central portal. This way, there is a single source of truth of what APIs are available, where they’re located and who is responsible for them. Commonly, this includes setting up a governance layer at an API layer and abstracting your API infrastructure from your back end systems and from the front end system so that it acts as a glue between your clients and your target back end systems. This provides you with the capability to do centralized governance at an API infrastructure or API platform layer. This enables you to onboard your API and application developers, internal and external partners and provides them with a standardized approach for onboarding and API documentation. Version management and revision control also allow you to handle things as APIs change regularly. Prioritize API Governance For many organizations, governance only becomes a concern after APIs are published. This approach returning to fix things later doesn’t work as if there is inadequate documentation, potential customers will go elsewhere to find APIs with better documentation. Governance needs to be built in from the beginning and enforced into the development pipeline. Taking a bottom-up approach to governance can create subjectivity and avoid limitations due to a sub-committee of only a few people who don’t understand every aspect of the APIs. Risk Assessment Many organizations without this governance have published and unpublished APIs, which can create vulnerabilities. These APIs need to be audited to document each API’s type of risks and how to mitigate these risks. IP Whitelisting The use of IP whitelisting as a security measure on your API provides a good base for API security but should be complemented with additional security measures. Smaller organizations with minimal APIs may consider this an option, but it should still include a zero trust model. They should be combining IP whitelisting with other things such as layered security, geofencing and more to avoid relying on one form of protection. Avoiding Security Breaches Monitoring Monitoring is critical to avoid breaches, as, without it, you won’t know if you’ve been breached. Every company suffers attacks daily, but the level of the breach may be unknown without proper monitoring. Leveraging DevOps APIs have fundamentally changed how often code is pushed to production. Classic security testing doesn’t necessarily operate at the speed of DevOps. Therefore tools and technologies that automate the process and are baked into the development cycle help organizations stop relying on reactive methods to circumvent attacks. Software configuration analysis tests need to be included in the process to avoid security misconfigurations. With the help of API management solutions, organizations can achieve granular control to monitor and mitigate risks continuously. Resources Finally, the experts pointed out that training to learn about API security through resources such as Cisco, API Academy, and other resources can arm companies with what they need to remain aware of additional best practices and educate others within their organization. Maintaining API Security with APIsec Testing and securing APIs is an ongoing process and needs to be incorporated throughout the development lifecycle. However, organizations need their API security to operate at the pace of DevOps and match how quickly new code gets pushed to production. With APIsec, you can locate API logic flaws before production with automated testing. Watch the on-demand recording of the webinar here to get more insights from the panel of experts on API security, or read our white paper to learn more about the cost of manual-based API testing.

Automated reports used to satisfy compliance requirements for APIsec SOC 2 certification SAN FRANCISCO, Oct. 5, 2020 /PRNewswire/ — APIsec, Inc. introduced today an update to its API security platform allowing enterprise security and compliance groups to obtain certified, compliant API penetration testing reports on-demand. APIsec now provides detailed pen-test reports that can be automated and published automatically after every code release.Enterprise security and compliance groups are mandated to perform periodic penetration testing of their applications as required by industry standards like SOC, HIPAA, PCI, NIST, GDPR, CCPA, and FedRAMP. Such penetration tests typically take months to complete and is a highly manual and expensive process. As a result, organizations generally prioritize pen-tests on the most critical applications, against the most common attack vectors. APIsec provides the industry’s only 100% automated and continuous API security testing platform that eliminates the need for expensive, infrequent, manual pen-testing. With this latest release, APIsec now produces certified and on-demand penetration testing reports required by the compliance standards, enabling enterprises to stay compliant at all times at a fraction of cost. “At Hastee, we take security very seriously, and we adopted a continuous approach to our API security testing efforts. The majority of Penetration Tests are quarterly and therefore outdated as soon as they are published. APIsec certified API penetration testing reports would help us address our compliance needs and also help us communicate security at the board level. APIsec keeps us honest,” said Peter Ingram, Chief Technology Officer of Hastee. “Our customers love the comprehensive security test coverage APIsec provides out of the box, and they wanted to stop hiring expensive, time-consuming outside firms for penetration testing reports,” said Intesar Shannan Mohammed, Founder and Chief Technology Officer of APIsec. “Compliance mandates proof of security for APIs, which traditionally is done manually, infrequently, and is very costly. With this release, APIsec now delivers automated API penetration test certification in minutes that provides 10 times the coverage at 1/10th the price.” APIsec leveraged the automated penetration test reports capability as part of its own SOC 2 certification. The SOC 2 auditors accepted the automated penetration reports and noted the breadth and completeness of the security test. This feature is now available for all APIsec customers. Visit www.apisec.ai to learn more and register for a free API security test. About APIsec, Inc: APIsec brings comprehensive security to any API, automatically discovering security zero-day vulnerabilities, business logic faults, and RBAC issues. With no tuning or training, APIsec automatically creates and runs thousands of attack scenarios against APIs, filing issues with ticketing systems, and producing compliance-ready pen-test reports. APIsec integrates with API gateways and platforms, and with CI/CD frameworks to automatically test new code in real-time. APIsec makes pen-testing automated, continuous, and comprehensive, providing critical visibility into application vulnerabilities before production.

The growth of the API Market in the US continues to climb year over year, with an expected increase of 34% - totaling a projected $7.5B market size in 2026. From massive global corporations to local businesses, the widespread use of APIs has permanently changed the face of all major industries. With REST APIs being the most commonly used APIs on the Web, it’s essential to understand what separates them from other types of APIs. In this article, you will learn everything you need to know about REST APIs to better understand how you can leverage their potential to reach your goals. What Is a REST API? A REST API is a standardized approach to building APIs that entails using the representational state transfer (REST) architectural style to communicate with servers. Designed in 2000, it’s been widely recognized as the go-to API development framework for creating web applications, SaaS products, and other web-based software products. REST APIs can be built with almost any programming language and support different data formats. For an API to be deemed as REST, it has to meet the following seven architectural constraints outlined in the original dissertation written by the creator of REST. Roy Fielding: Null style: the term refers to the architecture style where you start with no constraints and then start layering constraints on top of each other in a controlled and logical way. Client-server: In REST APIs, the client and server are completely separated and can’t interact with one another in any other way except through an API, allowing them to evolve independently. Uniform interface: Regardless of where API requests may come from, all of them should be identical when they try to gain access to the same resource. Statelessness: All API calls must contain all the information needed for processing a request without any stored context on the server. Cache: If applicable, reusable resources should be stored on the client or server to optimize the performance, making REST APIs a scalable solution. Layered System: A REST API is a system composed of multiple layers, each of which has a single purpose. One of the most common examples is a three-tier system made up of three layers: data access, business logic, and presentation. Code on Demand: REST APIs make it possible to dramatically extend their functionality by allowing them to send executable code - that should only run on-demand. How Does a REST API Work? In this section, we will take a deep dive into how REST APIs work from within. To start with, we are going to break down how a REST API fits into the client/server ecosystem for you to see the big picture: The user sends an API request through the client (the app or the frontend part). The API processes the request and queries the database (the backend part) to execute it on the backend side. The API sends a response to the client when the request has been executed. This is the natural order of things when it comes to any APIs. In order to communicate, REST APIs use all possible CRUD (create, read, update, delete) operations, the industry-standard HTTP verbs, that describe the things you want to do when interacting with your client and server. In REST APIs, HTTP methods, the equivalent of CRUD, are used to communicate both with the client and the server: CRUD OperationHTTP MethodCreatePOSTReadGETUpdatePUTDeleteDELETE Additionally, you can use the PATCH method to update your data partially. When it comes to API requests, it contains multiple building blocks: The Operation: the HTTP method that is being applied. The Endpoint is the point of entry in a communication channel when two systems interact, allowing the API to perform a specific task. The Body: this API term characterizes the data that you want to send in the API request. The Headers: a particular part of a REST API request which contains the meta-data related to the request - be it an API key or authentication data. The response is typically processed and stored in JSON or XML formats to deliver it back to the client. Other formats may include XLT, HTML, PHP, Python, or a simple text string. The Pros and Cons of REST APIs The flexible design principles of REST helped this type of API quickly become the most widely used framework today. To help you make an informed decision, in this section, we will cover the unique benefits and challenges of using REST APIs for your development project: Simplicity: REST APIs are relatively easy to master for any developer if you compare them to SOAP or other competitors, significantly shortening the learning curve and promoting ease of use. Standardization & Uniformity: Thanks to the uniform way of communication, you don’t need to worry about the format of your data and requests each time. High Scalability: As your service grows, you can easily modify the architecture without major structural overhauls. Statelessness: The fact that REST APIs are stateless means that you don’t have to worry about data state or track that across the client and server. High Performance: Thanks to the fact that REST APIs support caching, this preserves a significant amount of resources, ensuring high performance even as the service gets more sophisticated over time. However, the very same principles that result in an extensive range of benefits bring with them a few drawbacks that you need to consider during the development process: Negligible Latency: REST APIs are a great way to run your web service. However, you need to consider that some of the architectural constraints may lead to higher latency if left unaddressed. As an example, since RESTful APIs are based on the layered system, the more layers you stack on top of each other - be it for caching or load balancing purposes - the more latency these layers have. Higher Bandwidth Usage: High performance at scale can come at the cost of higher bandwidth usage if developers fail to optimize your API correctly. For instance, the stateless nature of REST APIs may lead to the client sending responses with redundant information, leading to higher resource consumption. REST API Versioning: APIs are regularly versioned to sidestep any potential compatibility issues. When that happens, multiple endpoints can remain active, effectively resulting in multiple APIs being used simultaneously. However, the biggest challenge is not resource consumption or versioning - it’s making your REST API safe for your users. Why Security Is the Biggest Concern for REST APIs According to a report from IBM Security X-Force, two-thirds of cloud breaches can be attributed to misconfigured APIs. A long list of recent API security incidents shows that APIs are increasingly targeted for data theft due to security gaps like weak authentication or business logic errors. While tech companies were the most frequent target of successful API breaches (58 percent), regulated organizations and industries were frequent targets as well: government (10 percent), healthcare (4.5 percent), financial (6 percent), and telcos (3 percent) were common successful targets of data breach attacks. Given the frequency of these breaches and that REST APIs dominate the scene across all major industries, companies need to be aware of what poses the biggest risks and how to mitigate them. REST API Security: Best Practices There are a myriad of ways to break into your API and cause significant damage to your company. The average cost of a data breach is estimated to be $8.64 million for US-based companies. Considering that 83 percent of consumers will stop the relationship with a company that became a victim of a successful cyberattack, securing API has never been more critical. To help you get started, these are the essentials that should help you protect your API against simple cyberattacks: Always use HTTPS: You should always use SSL to ensure higher security standards. Use password hashing: Password hashes add another layer of security, protecting the integrity of sensitive data even if a password was compromised. Avoid exposing sensitive data in URL strings: Any data that hackers can potentially use to break into your system, from usernames to session tokens, must not be included in the URL string. Implement OAuth: OAuth is a widely recognized authorization framework allowing data exchange without exposing sensitive information. However, since the techniques and methods used by hackers have constantly been evolving, continuous, comprehensive, and automated API testing is how some of the world’s largest companies keep their APIs safe. Meet Your Reliable API Testing Partner APIsec provides an enterprise-grade, automated, continuous API security platform that instantly detects top vulnerabilities, including the OWASP Top 10, business-logic, role-configuration, and access-control flaws, otherwise impossible to find using manual security tests. The platform executes a strict assessment of your REST API and targets your API vulnerabilities that security attackers can use to steal sensitive data - all for a fraction of the cost of professional manual penetration testing. If you’re looking for a way to keep your API safe from hackers by leveraging cutting-edge technology, reach out to us today to get a free penetration test of your API.

Step 1: Provide a curl for generating token Sample command: curl -s -d ‘{“username”:”admin”, “password”:”secret”}’ -H “Content-Type: application/json” -H “Accept: application/json” -X POST https://ip/user/login Step 2: Provide Token extraction logic using grep/jq If the Step 1 response look like this {“time”: “1594073751605”, “info”: {“token”: “val”}}. and your token path is “info.token” you can use json parser (jq) to extract the token. Alternatively, you can also use “grep” to extract the value. For example: curl -s -d ‘{“username”:”admin”, “password”:”secret”}’ -H “Content-Type: application/json” -H “Accept: application/json” -X POST https://ip/user/login | jq –raw-output “.info.token” Step 3: Provide a token usage example. curl –location –request GET ‘https://ip/api/users’ -H ‘X-API-KEY: <>’ Step 4: Wrapping your logic in @Cmd You can wrap your entire Step 2 content using the @Cmd syntax. And it will be evaluated at runtime before running the Playbooks. Usage: X-API-KEY: {{@Cmd | Step-2-content }} or Authorization: Bearer {{@Cmd | Step-2-content }} Sample code: Authorization: Bearer {{@Cmd | curl -s -d ‘{“username”:”admin”,”password”:”secret”}’ -H “Content-Type: application/json” -H “Accept: application/json” -X POST https://ip/user/login | jq –raw-output “.info.token” }} Step 5: Using @CmdCache @CmdCache is similar to @Cmd, but it caches the token for 5 minutes and reuses it across multiple Playbooks. Usage: X-API-KEY: {{@Cmd | Step-2-content }} or Authorization: Bearer {{@Cmd | Step-2-content }} Sample code: Authorization: Bearer {{@CmdCache | curl -s -d ‘{“username”:”admin”,”password”:”secret”}’ -H “Content-Type: application/json” -H “Accept: application/json” -X POST https://ip/user/login | jq –raw-output “.info.token” }} Step 6: Using @Vault for secure password usage. Create a key-value pair in Vault and inject it using this syntax. Usage: [[@Vault.ORG-NAME/KEY-NAME]] e.g. Authorization: Bearer {{@CmdCache | curl -s -d ‘{“username”:”admin”,”password”:”[[@Vault.ORG-NAME/KEY-NAME]]”}’ -H “Content-Type: application/json” -H “Accept: application/json” -X POST https://ip/user/login | jq –raw-output “.info.token” }} Note: If the request body contains 2 or more opening/closing curly brackets together. Make sure to escape them using spaces e.g. {{ -> { {.

APIs are the heart of the modern Web, Mobile, & Data integration architecture. As per OWASP, top API vulnerabilities come from business-logic, role-configuration, and access-control flaws. Making web security, pen-testing, and WAF approaches obsolete against the top API exploits. APIsec is the cloud-native continuous API security platform, instantly detect and fix OWASP API Security Top 10, Business-Logic, Role-Configuration & Access-Control vulnerabilities in the API layer. OWASP API Security Top 10: Command & Injection Categories Penetration Testing Use-Cases & Compliance AI-Powered: APIsec bot instantly writes custom validations as playbooks for your APIs, giving you full control and visibility of your security coverage. And it automatically detects, prioritizes, and helps you fix vulnerabilities. No Business Shutdowns: Never lose a Single Record! Never Pay Business-Breaking Fines for Compliance, Legal, or Brand Damage. Continuous & Automatic: APIsec integrates with all major CI/CD tools. And it automatically manages vulnerabilities across all major engineering issue-trackers and IT ticketing systems. Not only does automation helps you save time and money, but it also enables you to share and resolve issues a lot faster. Zero Risk: APIs can Go-Live with Zero Business Risk Zero Business Loses: Never Lose a Single Customer Record! Never pay Business-Breaking Fines for Compliance, Legal, & Customer Damages. Comprehensive Coverage: Covers Dozens of Modern Exploits in Business-Logic, Roles Assignment, Access-Controls, Multi-Tenancy, & Injection Flaws. Conclusion: APIsec provide API Security and Automatically Discover, Prioritizes, and help you Remediate all API Vulnerabilities.Covers Thousands of Flaws in Business-Logic, Roles Assignment, Access-Controls, Multi-Tenancy, & Command Injections. Web security covers only injection categories and doesn’t support APIs. Penetration testing cover features but is expensive and manual. APIsec is the only security platform that instantly covers

Scan local APIs to find vulnerabilities with APIsec CLI 1. Installation To download and run apisec-cli, please run the following git clone https://github.com/intesar/apisec-clicd apisec-clijava -jar apisec-cli.jar 2. Signup with APIsec For the new users, you need to sign-up with APIsec. It creates a new tenant for you in the APIsec SaaS Platform. Command: Signup –c -e apisec> signup -c mycompany -e john@mycompany.com It returns the login credentials, i.e., the user name and an auto generated password. Save these in a file called fx.properties at the location specified. Upon next execution, you’ll be automatically logged-in to your tenant. Alternatively, you can keep the password with you, and when you execute the script next time you need to manually login using the below command. Command: login –u -p apisec> login –u john@mycompany.com -p DBhk20Al 3. Register APIs Register the API that you wish to scan by providing its publicly available Open API Spec URL i.e., swagger url for e.g., http://mycompany.com/application/v2/api-docs Command: register –n -o apisec> register –n orders -o http://mycompany.com/orders/v2/api/docs APIsec parses the specs and generates the security playbooks for scanning. This might take a few seconds depending on the number of endpoints in the API. If your application is hosted internally and the OAS Url is not available publicly, APIsec recommends you to upload the OAS file in json/yaml format to any public location like github and provide its direct url. Note: You can register multiple APIs in the same tenant by repeating the above step. Use ‘ls’ command to view the list of all the registered APIs with APIsec Command: ls apisec> ls 4. Scan the API To scan the API for vulnerabilities, use the scan command as below. Command: scan –n < api name> apisec> scan –n orders It runs all the playbooks generated in the above step, which invokes the endpoints at the application hosted (the host url and the basepath provided in the OAS Specs). If the application is hosted internally and no public IP is available, you need to scan using your local scanner. The steps to create a local scanner are available in the next section. 5. Create a local scanner If the application is hosted internally and no public IP is available, you need to deploy a local scanner to invoke. Command: scanner create –n apisec> scanner create –n MyLocalScanner Command: scan –n -s apisec> scan –n orders –s MyLocalScanner This command returns the docker and kubernetes scripts to deploy the scanner. Run the docker or kubernetes script as per your environment setup on the same machine where the API is hosted or any other machine in the network which can access the APIs. The script It will deploy the scanner in that machine. Use the below commands to view the list of all local scanners created in your tenant. Command: scanner ls apisec> scanner ls Use the below commands to remove the local scanner in your tenant. Command: scanner rm -n apisec> scanner rm -n MyLocalScanner

Step 1: Register A New User Account Note: Don’t use personal credentials when accessing APIsec APIs. Instead, register a new user with the role “USER” in Apisec™ UI and entitled this account to required projects. Step 2: Authenticating and Generating A JWT Token curl -s -X POST https://cloud.fxlabs.io/auth/login -H 'Accept: application/json' -H 'Content-Type: application/json' -d '{"username": "", "password": ""}' You should receive a token back. {"token":"eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJOZXRCYW5raW5nLy9pbnRlc2FyQGZ4bGFicy5pbyIsInNjb3BlcyI6IlJPTEVfVVNFUixST0xFX1BST0pFQ1RfTUFOQUdFUixST0xFX0FETUlOLFJPTEVfRU5URVJQUklTRV9BRE1JTiIsImlhdCI6MTYwOTg4NzQ5NywiZXhwIjoxNjA5OTA1NDk3fQ.8kkPdbacGy6BDfzqnTM6EiUi6aHS_mWDHCfWirvma_s"} Note: The token is valid for 5 hours. Step 3: Get Entitled Projects Note: Use the token from the previous call as part of the header value in “Authorization: Bearer ” curl -s -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJOZXRCYW5raW5nLy9pbnRlc2FyQGZ4bGFicy5pbyIsInNjb3BlcyI6IlJPTEVfVVNFUixST0xFX1BST0pFQ1RfTUFOQUdFUixST0xFX0FETUlOLFJPTEVfRU5URVJQUklTRV9BRE1JTiIsImlhdCI6MTYwOTg4NzQ5NywiZXhwIjoxNjA5OTA1NDk3fQ.8kkPdbacGy6BDfzqnTM6EiUi6aHS_mWDHCfWirvma_s" -H "Content-Type: application/json" -H "Accept: application/json" -X GET https://cloud.fxlabs.io/api/v1/projects Response structure Step 4: Get Project Vulnerabilities Using the response from Step 3, make individual calls to retrieve project-specific vulnerabilities. Note: This call returns Critical and High vulnerabilities only from the master environment. curl -s -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJOZXRCYW5raW5nLy9pbnRlc2FyQGZ4bGFicy5pbyIsInNjb3BlcyI6IlJPTEVfVVNFUixST0xFX1BST0pFQ1RfTUFOQUdFUixST0xFX0FETUlOLFJPTEVfRU5URVJQUklTRV9BRE1JTiIsImlhdCI6MTYwOTg4NzQ5NywiZXhwIjoxNjA5OTA1NDk3fQ.8kkPdbacGy6BDfzqnTM6EiUi6aHS_mWDHCfWirvma_s" -H "Content-Type: application/json" -H "Accept: application/json" -X GET https://cloud.fxlabs.io/api/v1/projects/{projectId}/vulnerabilities Here are a few important attributes of the vulnerability entity: id status environment.baseURL issueDesc label description category cvss severity rank suggestion createdDate method path

Note: This series aims to analyze and simplify breach and vulnerability reports that are usually cryptic and mostly written by legal. The simplified version hopes to educate and help security and engineering leadership avoid the same mistakes. Company: First American Financial Report Date: May 24, 2019 Vulnerable Data: 885M customer records The complexity of hack: Medium Vulnerability Type: Zero-Day Exploit. A common vulnerability that can existacross multiple endpoints. Vulnerable Data Social Security Numbers Drivers licenses Account statements Corporate documents, etc. Sample vulnerable endpoint/URLs https://../documents?id=1001https://../documents?id=1002https://../documents?id=1003 Exploit Rule #1: Hackers are looking for monetizable data like customer names, emails, addresses, company names, credit cards, transactions, orders, financial records, etc unless if the intention is to disrupt your business. The flaw in the URL: The above URL suggests that it’s a document endpoint. It may contain sensitive and financial information since the First American Financial is a financial company. This endpoint is more important to hackers than let’s say “/locations”, or “/products” endpoints which are mostly public information and exploiting or accessing this data will have very little financial gains. Once the hackers identify endpoints with critical data, the next steps are to look for the exploits. Exploit Techniques Insecure Direct Object Reference (IDOR) Parameter Tampering The IDOR is a common design practice across the industry to solve some common problems, for example, Google Docs, Dropbox they all use this design to allow users to share private documents by just sharing the auto-generated non-guessable document URLs. The only time this design becomes an easy pray is if the URLs are guessable or predictable and in First American Financial’s case, it seems the product had sequential or number-based document ids. That means it was easy to guess document Ids for the entire 885 million records. If the above URL were public or non-protected, which means it doesn’t require any authentication, then this would have allowed hackers to download all the data without leaving any digital fingerprints. Also, it requires much less work on their part, as they don’t have to sign-up for the service or steal a customer or employee credentials to perpetuate the breach. Sequential Identifiers id=emp-1001id=customer-1001 Never ever use sequential numbers and weak random string generators. These are easy to predict or reverse generate. Example of good ID design: Google’s private doc’s public URL (The highlighted ID is tough to guess or predict). Anybody with the URL can access the document. https://docs.google.com/spreadsheets/d/1mCPqlQSTI3K4YzJqbW8peTQ3zBF7tlNptmOEuLybvXI/edit?usp=sharing The next step would have been to use parameter tampering technique along with a script to download all the documents. Example shell script #!/bin/bashfor i in {1..1000000000}do wget "https://../documents?id="$idone Solution: Tactically secure and validate the most critical data endpoints first. Attackers are consistently going after three critical pieces of information if monetary benefits drive them. e.g., customer information, customer financial data, credit cards, bank accounts, transfers, transactions, orders, etc. Financial Repercussions: Even though there was no reported breach but the First American Financial stock still shed $110M or 2% of the $5.7B market cap. Have to go through expensive third-party forensics and audits. What won’t work in thwarting these kinds of attacks Web scanners may not detect these exploits, as they focus more on injection and on fuzzing attacks than on tailored scenarios like these. How to protect your Apps and APIs against these attacks? Design best practice: never use Incremental IDs for record identifications in your database. Instead, use random UID’s and in addition, do salting of IDs. It will slow down the attack as it will be much harder to guess and fish ID. Proper Access-Controls checks in the business logic to validate caller against the requesting data. Continuously scan & validate access-controls logic on all endpoints. As the product grows these vulnerabilities becomes very common. A Type-2 Scanner that looks in addition to injection attacks and looks for business logic vulnerabilities including RBAC, ABAC, Hijack, Sensitive Data Exposure attacks, etc.

Note: This series simplifies and analyze breach/exploit details which are usually cryptic and legal led and to help other enterprises avoid the same mistake. Company: HealthEngine App: Feedback System Data Leaked: 59,000+ patient’s personally identifiable information. The complexity of hack: Low Vulnerability Type: Day-0 Common Vulnerability: Yes and can exist on multiple endpoints. What was exposed? Personally identifiable information – We don’t know what exact information was leaked. How was this hack perpetrated? This hacked required no special tools or exploits or account hijacking of any sorts etc. Simply a web browser would do the job or an API call. The feedback system’s backend/API was sending feedback information along with the patient information who submitted the feedback. The feedback page would only show the feedback text and would skip/hide the rest of the sensitive patient information on the UI page. This information was right there in the network call or in the hidden section of the pages. All hackers had to do was to analyze the chrome or firefox’s network calls and extract sensitive patient information. It’s a Day-0 vulnerability. What it means is, APIs with these vulnerabilities will expose sensitive information to any other third-party integrators on the first automated call itself. Most countries like in Europe and the USA have rules that require reporting these violations when companies expose just over 500 customer records. And are dealt with punitive damages, stringent audits and legal, etc. How does this exploit works? For example, let’s take this simple scenario. Let’s assume the vulnerable app had these endpoints. GET: /feedback // return list of feedback dataGET: /feedback/{feedback-number} // returns feedback details Note: The {feedback-number} param can be a path param like the above one or could have been a query or body params. This exploit will still work across all the scenarios. Here is an example response from the backend API. As you can clearly see the API returns the sensitive patient information as part of the “created_by” attribute. The UI page may be only interested in the other parts i.e. text and rating attributes etc. This extra information is easily accessible to the hackers and it’s right there in the browsers network call. {“event_type”:”feedback.updated”,“created_at”:”SatDec1517:58:22+00002015″,“feedback”:{“created_at”:”SatDec1517:58:20+00002015″,“updated_at”:”SatDec1517:59:22+00002015″,“id”:”123456789″,“text”: “text…”,“ratings”: “4”},“created_by”: {“name”: “Foo Bar”,“age”: 25,“favorite_color”: “#ffa500”,“gender”: “male”,“location”: {“city”: “Seattle”,“state”: “WA”,“citystate”: “Seattle, WA”}}} How common is this vulnerability? It’s a common scenario. Most modern apps without realizing would end-up exposing some sort of sensitive information via the APIs if they’re using ORM frameworks. ORM framework manages relation data as large navigable objects trees or nested JSON objects when exchanged in & out of the system. This problem can become even worse if other third-party systems are consuming your APIs. Because the leak can happen on first on a regular request because there is no hiding possible on an API call. What kind of systems have these vulnerabilities? The industries that use customer submitted data like feedback, ratings, products, etc. E.g., E-commerce, Rating Sytems, or ORM enabled apps, etc. What kind of systems have these vulnerabilities? Any industry that uses customer submitted data like feedback, ratings, products, etc. E.g. E-commerce, Ratings Sytems, or ORM enabled apps, etc. What won’t work in thwarting these kinds of attacks Typical scanners and static code analyzers won’t help detect these exploits, they focus more on injection and on fuzzing attacks rather on sensitive data exposure scenarios. How to protect your Apps and APIs against these attacks? GraphQL can solve not having to send large JSON objects in/out of the system issues but it’s not going to help with actual access-control logic. A Type-2 Scanner can be helpful which looks in addition to injection attacks and looks for business logic vulnerabilities including RBAC, ABAC, Hijack, Sensitive Data Exposure attacks, etc.

Note: This series simplifies and analyze breach/exploit reports which are usually cryptic and legal led and to help other enterprises avoid the same mistake. Hackers were able to acquire over 350K customer’s personal data from Citi’s web application. Citi managed over 21M customers when the breach happened. This breach exposed just over 1% of the customer data. What was exposed? Customer names Account numbers Contact information How was this hack perpetrated? Through an exploit known as parameter tampering for web applications and APIs. How does the parameter tampering works? For example, let’s take this simple scenario. Let’s assume the vulnerable app had these endpoints. GET: /customers/{account-number} // return customer info e.g. name etcGET: /customers/{account-number}/accounts // returns customer account info etcGET: /customers/{account-number}/contacts // returns customer contact info etc Note: The {account-number} param can be a path param like the above one or could have been a query or body params like the example below. This exploit will still works across all the scanarios. GET: /customers?account-number=val // return customer info e.g. name etc Criteria for a successful attack? This exploit will work if there is a flaw in the app’s business logic. A missing validation or a missing role assignment can allow any user in the app to request information belonging to any other user/customer just by knowing the other customer’s account numbers. What made it much worse? Predictable account numbers e.g. incremental numbers 100034567, 100034568, etc. This will allow an attacker to automate and steal large continuous numbers without having to fish specific numbers on the web. What won’t work in thwarting these kinds of attacks It doesn’t matter if these endpoints were secured. Attackers will usually use stolen credentials to access these paths. It doesn’t matter if these endpoints were not disclosed on the customer web apps. There are several ways to identify non-disclosed endpoints. Fuzz testing doesn’t detect these exploits. Web scanners won’t help detect these exploits either, they focus more on injection and on fuzzing attacks rather than tailored scenarios like these. Static code analysis won’t help either. These scenarios require live testing. How to protect your Apps and APIs against these attacks? Design best practice: never use Incremental IDs for record identifications in your database. Instead, use random UID’s. This will slow down the attack as it will be much harder to guess and fish UID’s. Continuously scan & validate access-controls logic on all endpoints. As the product grows these vulnerabilities become a commonplace. A Type-2 Scanner which looks in addition to injection attacks and looks for business logic vulnerabilities including RBAC, ABAC, Hijack, Sensitive Data Exposure attacks, etc.