In one form or another, APIs have been around for years, bringing the benefits of ease of use, efficiency and flexibility to the developer community. The advantage of using APIs for mobile and web apps is that developers can build and deploy functionality and data integrations quickly.
API security posture
But there is a huge downside to this approach. Undermining the power of an API-driven development methodology are shadow, deprecated and non-conforming APIs that, when exposed to the public, introduce the risk of data loss, compromise or automated fraud.
The stateless nature of APIs and their ubiquity makes protecting them increasingly difficult, largely because malicious actors can leverage the same developer benefits – ease of use and flexibility – to easily execute account takeovers, credential stuffing, fake account creation or content scraping. It’s no wonder that Gartner identified API security as a top concern for 50% of businesses.
Thankfully, it’s never too late to get your API footprint in order to better protect your organization’s critical data. Here are a few easy steps you can follow to mitigate API security risks immediately:
1. Start an organization-wide conversation
If your company is having conversations around API security at all, it’s likely that they are happening in a fractured manner. If there’s no larger, cohesive conversation, then various development and operational teams could be taking conflicting approaches to mitigating API security risks.
For this reason, teams should discuss how they can best work together to support API security initiatives. As a basis for these meetings, teams should refer to the NIST Cybersecurity Framework, as it’s a great way to develop a shared understanding of organization-wide cybersecurity risks. The NIST CSF will help the collective team to gain a baseline awareness about the APIs used across the organization to pinpoint the potential gaps in the operational processes that support them, so that companies can work towards improving their API strategy immediately.
2. Ask (& answer) any outstanding questions as a team
To improve an organization’s API security posture, it’s critical that outstanding questions are asked and answered immediately so that gaps in security are reduced and closed. When posing these questions to the group, consider the API assets you have overall, the business environment, governance, risk assessment, risk management strategy, access control, awareness and training, anomalies and events, continuous security monitoring, detection processes, etc. Leave no stone unturned. Here are a few suggested questions to use as a starting point as you work on the next step in this process towards getting your API security house in order:
- How many APIs do we have?
- How were they developed? Which are open-source, custom built or third-party?
- Which APIs are subject to legal or regulatory compliance?
- How do we monitor for vulnerabilities in our APIs?
- How do we protect our APIs from malicious traffic?
- Are there APIs with vulnerabilities?
- What is the business impact if the APIs are compromised or abused?
- Is API security a part of our on-going developer training and security evangelism?
Once any security holes have been identified through a shared understanding, the team then can collectively work together to fill those gaps.
3. Strive for complete and continuous API security and visibility
Visibility is critical to immediate and continuous API security. By going through step one and two, organizations are working towards more secure APIs today – but what about tomorrow and in the years to come as your API footprint expands exponentially?
Consider implementing a visibility and monitoring solution to help you oversee this security program on an ongoing basis, so that your organization can feel confident in having a strong and comprehensive API security posture that grows and adapts as your number of APIs expand and shift. The key components to visibility and monitoring?
Centralized visibility and inventory of all APIs, a detailed view of API traffic patterns, discovery of APIs transmitting sensitive data, continuous API specification conformance assessment, having validated authentication and access control programs in place and running automatic risk analysis based on predefined criteria. Continuous, runtime visibility into how many APIs an organization has, who is accessing them, where they are located and how they are being used, is key to API security.
As organizations continue to expand their use of APIs to drive their business, it’s crucial that companies consider every path malicious actors might take to attack their organization’s critical data.
Cequence API Sentinel: Discovering and analyzing all org’s APIs to detect and mitigate security risks
Cequence Security announced the general availability of Cequence API Sentinel, a runtime API security solution that delivers continuous run-time API visibility, shadow API discovery, risk analysis, and conformance assessment.
With the addition of API Sentinel, Cequence delivers the industry’s only multi-threat API security solution that unifies visibility, vulnerability protection, bot mitigation, and business logic abuse prevention into a single platform.
“API security is the fastest growing segment of the security market today, but has been largely underserved by siloed point products that only address a part of problem.
“The addition of API Sentinel to the Cequence Application Security Platform extends our API protection beyond automated bot attacks and API abuse to include discovery of API risks introduced by shadow publication, coding or non-conformance errors,” said Ameya Talwalkar, co-founder and chief product officer of Cequence Security.
“Our end-to-end approach ensures that API security can be clearly understood and actioned across development, security, operations, and compliance teams.”
By integrating rapidly with existing API management tools like gateways and proxies, API Sentinel provides insights into the usage of each API needed to mitigate security vulnerabilities. Key capabilities include:
- Continuous risk scoring: Assesses and assigns a numeric risk factor for each API based on strength of authentication used, presence of PII, PCI or other sensitive data, detection of unencrypted communication, and non-conformance to the OpenAPI specification.
- Runtime API catalog and usage analysis: Automatically discovers all APIs, including managed and shadow APIs. Analyzes API usage and access, including geo-location, IP addresses and organizations. Provides a view into headers, parameters, and response codes with flexible time-based filtering.
- Schema non-conformance detection: Performs a runtime comparison of your inventoried APIs against an OpenAPI specification to uncover and flag API endpoints, headers, parameters and response codes as non-conformant. Discovered out-of-spec elements can be addressed by development, effectively mitigating security risks before they reach production.
Built to help organizations understand the risk posture of all their APIs so they can avoid costly data loss, fraud, and API abuse, API Sentinel answers critical questions that most organizations can’t answer, including:
- What are all the published APIs –sanctioned and shadow? How are they used across each team, department, product line, geography?
- What is our overall API risk exposure? Do we have API vulnerabilities that are being leveraged by attackers?
- Are APIs exposing sensitive data or PII which could put us out of compliance?
“Organizations typically spend more time focused on active attacks and breaches than they do assessing their code and environments for vulnerabilities and security gaps which are often hiding in plain sight. In most cases, they simply lack tools that can provide that level of visibility for APIs,” said Ed Amoroso, chief executive officer of TAG Cyber.
“API Sentinel fills a critical need so that security and development can collaborate to secure and protect today’s API-driven applications.”
“The Cequence team is committed to helping us enhance API security to protect our environments from potential bad actors,” said Ram Ravichadran, CTO of Narvar. “They helped bolster and protect our API security from all forms of risk. As a platform designed to drive long-term customer loyalty, we appreciate their dedication to help further protect the brands we serve.”
API Sentinel joins the industry leading, ML-based Cequence Bot Defense and Cequence App Firewall in the Application Security Platform that are currently protecting APIs and web apps with a near zero-impact on the development workflow, allowing development teams to maintain or even increase productivity.
Available as a modern Kubernetes application, API Sentinel integrates natively with popular API Gateways, like Amazon API Gateway, Apigee and MuleSoft, and proxies like NGINX, HAProxy, and Envoy.
Security issues for APIs
The many benefits that APIs bring to the software and application development communities – namely, that they are well documented, publicly available, standard, ubiquitous, efficient, and easy to use – are now being leveraged by bad actors to execute high profile attacks against public-facing applications. For example, we know that developers can use APIs to connect resources like web registration forms to many different backend systems. The resultant flexibility for tasks like backend update also provide support for automated attacks.
The security conundrum for APIs is that whereas most practitioners would recommend design decisions that make resources more hidden and less available, successful deployment of APIs demands willingness to focus on making resources open and available. This helps explain the attention on this aspect of modern computing, and why it is so important for security teams to identify good risk mitigation strategies for API usage.
Security threats to APIs
OWASP risks to APIs
In addition to its focus on risks to general software applications, OWASP has also provided useful guidance for API developers to reduce security risk in their implementations. Given the prominence of the OWASP organization in the software community, it is worth reviewing the 2019 Top 10 API Security Risks (with wording taken from the OWASP website):
1. Broken Object Level Authorization. APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface level access control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.
2. Broken User Authentication. Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently. Compromising a system’s ability to identify the client/user compromises API security overall.
3. Excessive Data Exposure. Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.
4. Lack of Resources & Rate Limiting. Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.
5. Broken Function Level Authorization. Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.
6. Mass Assignment. Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to mass assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.
7. Security Misconfiguration. Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.
8. Injection. Injection flaws, such as SQL, NoSQL, command injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
9. Improper Assets Management. APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.
10. Insufficient Logging & Monitoring. Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
API security requirements
As exemplified by the OWASP list, the cyber security community is beginning to identify many familiar, canonical issues that emerge in the use of APIs for public-facing applications. Below are five generalized cyber security requirements for APIs that come up in design and development context frequently for both legacy and new Internet applications:
The adage that knowledge-is-power seems appropriate when it comes to API visibility. Application developers and users need to know which APIs are being published, how and when they are updated, who is accessing them, and how are they being accessed. Understanding the scope of one’s API usage is the first step toward securing them.
API access is often loosely-controlled, which can lead to undesired exposure. Ensuring that the correct set of users has appropriate access permissions for each API is a critical security requirement that must be coordinated with enterprise identity and access management (IAM) systems.
In some environments, as much as 90% of the respective application traffic (e.g., account login or registration, shopping cart checkout) is generated by automated bots. Understanding and managing traffic profiles, including differentiating good bots from bad ones, is necessary to prevent automated attacks without blocking legitimate traffic. Effective complementary measures include implementing whitelist, blacklist, and rate-limiting policies, as well as geo-fencing specific to use-cases and corresponding API endpoints.
Vulnerability exploit prevention
APIs simplify attack processes by eliminating the web form or the mobile app, thus allowing a bad actor to more easily exploit a targeted vulnerability. Protecting API endpoints from business logic abuse and other vulnerability exploits is thus a key API security mitigation requirement.
Data loss prevention
Preventing data loss over exposed APIs for appropriately privileged users or otherwise, either due to programming errors or security control gaps, is also a critical security requirement. Many API attacks are designed specifically to gain access to critical data made available from back-end servers and systems.
The API community continues to drive toward more standardized agreement on the optimal approach to security. To this end, industry groups such as OAUTH, for example, have proposed criteria requirements for API security that are quite useful. The most likely progression is that the software security community will continue to refine its understanding and insight into the full range of API security requirements in the coming years. Observers should thus expect to see continued evolution in this area.
API security methods
API abuse in action
By design, APIs are stateless, assuming that the initial request and response are self-contained, holding all the information needed to complete the transaction. Making program calls to an API directly, or as part of a mobile or web application improves user experience and overall performance. This makes it very easy for a bad actor to script and automate their attack as highlighted in two examples below
Account takeover and romance fraud: Zoosk is a well-known dating application. Bad actors decompiled the Zoosk app to uncover account login APIs. Using automation and attack toolkits, they then executed account takeover attacks. In some cases, compromised accounts were used to establish a personal relationship with another Zoosk user and, as the relationship blossomed, the bad actor requested money due to a sudden death or illness in the family. The unsuspecting user gave the money to the bad actor, who was never to be heard from again. Prior to implementing Cequence, romance scams at Zoosk averaged $12,000 with each occurrence. Now, they are virtually eliminated, resulting in increased user confidence and strengthened brand awareness.
Account takeover and financial fraud: Another example of APIs being targeted with an automated attack involves a large financial services customer finding that attackers had targeted its mobile application login API to execute account takeovers. If successful, the bad actors could attempt to commit financial fraud by transferring funds across the Open Funds Transfer (OFX) API. OFX, of course, is the industry standard API for funds transfer within the financial services community, and as such the APIs are publicly-available and well-documented to facilitate use.
Contributing author: Matthew Keil, Director of Product Marketing, Cequence.
This is third in a series of articles that introduces and explains application programming interfaces (API) security threats, challenges, and solutions for participants in software development, operations, and protection. Explosion of APIs The API explosion is also driven by several business-oriented factors. First, enterprises are moving away from large monolithic applications that are updated annually at best. Instead, legacy and new applications are being broken into small, independently functional components, often rolled out as container-based … More
This is the first of a series of articles that introduces and explains application programming interfaces (API) security threats, challenges, and solutions for participants in software development, operations, and protection.
Purpose of article series
Researching the wide range of API security alternatives can be confusing – even to seasoned experts. This article series is written with the goal of helping all types of readers better understand the pros and cons of the various modern approaches to protecting APIs from cyber security risks. The material is intended to help enterprise security and software development teams develop and maintain a consistent protection philosophy.
The target reader includes software developers who depend on and use APIs every day, as well as technical managers who might have responsibility for API security in their organization. The target reader also includes, however, technical-minded individuals possessing little experience with APIs, but who are nevertheless interested in the security aspects of this important issue. We try to describe the API security concepts in a manner accessible to each type of reader.
Introduction to APIs
The typical user of network and Internet services tends to think of computer interfaces in terms of screens, keyboards, monitors, and the like. These interfaces are the visible means by which systems exchange information with human users, and they have advanced rapidly in recent years. The touch screen from Apple, for example, emerged only a decade ago, and a generation of youngsters barely remembers what the world was like before such useful capability existed.
But there is another type of interface that exists in computing, perhaps more hidden to the everyday user. This other type of interface is how software programs communicate with one another. For many years, this process was poorly specified, with programmers inventing protocols for something called inter-process communication (IPC). An early operating system from Bell Laboratories called Unix, which now serves as the base of both Apple iOS and Android, made IPC designs easier, but they were non-standard.
By 2000, the industry decided that these software-to-software interfaces needed to become more open and standard. Such technical decision became the genesis of what we now refer to as an application programming interface or more commonly – API. Recognize that an API provides a standard interface through which two software programs, also referred to commonly as processes, can communicate, share messages, or managed shared memory.
More specifically, an API is an interface which makes software services available to workloads or applications for bidirectional communication and message sharing. APIs are also commonly used to share memory between different processes. An API is stateless in nature, and will commonly include all the information needed to complete a transaction, unlike a web form that may require multiple transactions for processes like user registration.
Figure 1. General API model
Unix Operating System IPC
Roughly half a century ago, researchers Ken Thomson and Dennis Ritchie of Bell Laboratories initiated a project to build a multitasking operating system for use inside AT&T. Despite such relatively modest original goals, the so-named Unix software and associated design philosophy that they produced have served as the technical base for virtually every successful commercial operating system since. Linux and Android are direct derivatives, whereas iOS and Windows are massively influenced by Unix.
An important design consideration for the Unix operating system involved the need to create an IPC mechanism that would allow for data sharing and message passing between computer programs. Thompson and Ritchie were influenced by many rapidly evolving technical concepts being designed at the time in the computer science community. This included the emergence of producer-consumer models, as well as new methods for distributed computing.
The Unix IPC approach can be viewed as an early attempt to address many of the issues now covered by APIs. Both are concerned with the need to modularize, standardize, and simplify the manner in which data or messages are shared between cooperating processes. The big difference, obviously, is that modern APIs benefit from the massive scale that comes with the Internet. Original Unix efforts were local and operating system-specific.
Contributing author: Matthew Keil, Director of Product Marketing, Cequence.
The solution allows customers to protect public-facing applications from online fraud caused by automated attacks such as account takeovers and API business logic abuse.
The new SaaS offering complements existing on-premises or cloud deployment options, delivering the same security functionality while reducing the operational effort required to protect public-facing applications from automated attacks.
Following a shared responsibility model, Cequence Security deploys and manages the underlying SaaS infrastructure, ensuring continuous uptime and updates for the platform software. Meanwhile, all security policies, data and system configuration elements are managed and owned by the customer.
“Enterprise digital transformation typically combines cloud-first initiatives with the adoption of more iterative, microservices-based application development methodologies with the goal of being more efficient while increasing competitiveness,” said Ameya Talwalkar, co-founder and Chief Product Officer at Cequence Security.
“CQ botDefense SaaS complements our existing on-prem and cloud deployments, allowing customers to reduce the operational burden associated with protecting their digital transformation initiatives from automated bot attacks.”
CQ botDefense SaaS has been certified as PCI DSS 3.2 Level 2 for Service Providers compliant and is in process for SOC II Level I certification. Both are critical SaaS selection criteria for enterprise customers, providing assurance that the Cequence Operations Team adheres to strict guidelines for protecting customer data.
Deployed as a secure, single tenant service on AWS, CQ botDefense SaaS delivers three important features that can help customers save time and strengthen their application security posture:
- Discover – Once CQ botDefense SaaS is deployed, the CQAI analytics engine automatically discovers all web, mobile, and API-based endpoints targeted by malicious bot attacks.
- Detect – CQAI uses Machine Learning and threat intelligence to determine the underlying intent and behavior of each transaction to identify malicious bot traffic in near real time.
- Defend – CQ botDefense SaaS can automatically take action and block bad traffic, or it can work with a customer’s existing security tools to block malicious bot attacks.
CQ botDefense SaaS complements native AWS services, integrating seamlessly with commonly used CDNs including Amazon CloudFront to block bot attacks at the edge. Alternatively, it can be deployed closer to the application infrastructure with load balancer integration, requiring no changes to CDNs or DNS settings.