Top 6 API Security Questions Answered
APIs power today’s connected world. They enable organizations to supply the digital services that support everyday activities like shopping online, booking a holiday or using a banking app. The unprecedented growth of API usage across all industries in recent years has accelerated digital transformation and brought new API security challenges to light.
According to the State of API Security report Q3 2022, API traffic has grown 168% in the past year, with 94% of companies reporting they have suffered an API security problem in production in the same period. The vital role that APIs play in fueling business innovation and enabling digital services hasn’t gone unnoticed by cybercriminals.
With API attacks on the rise and growing in sophistication, how do you know if your approach to API security will provide sufficient protection? Below are key questions that today’s organizations must ask as they begin to develop an API security strategy:
Question 1: Do We Have Full Visibility Over Our APIs?
With the API ecosystem exploding in recent years, many organizations have found themselves in a position where it’s hard to keep track of all their APIs as their environment evolves. With APIs changing at a quicker pace than ever before, developers often don’t keep documentation up to date and keeping an accurate API inventory becomes challenging and often frustrating.
In order to understand the attack surface and level of risk in your environment, you must be able to see all internal, external and third-party APIs, including APIs that are not noted in the documentation, known as shadow APIs, and deprecated APIs that have not yet been disabled, known as zombie APIs.
These uncatalogued APIs may expose sensitive data, including personal identifiable information (PII), meaning they present a high level of risk. Ensuring your API security strategy includes a comprehensive and up-to-date API inventory is key, as you can’t protect what you can’t see.
Question 2: Can WAFs and API Gateways Protect Our APIs?
Traditional API management tools that include some security capabilities, such as web application firewalls (WAFs) and API gateways, understandably play an important part in today’s security stacks.
WAFs can help detect exploitation of web application traffic and API gateways give you observability over your API usage and the ability to enforce access controls.
- However, neither of these solutions provide the level of visibility and security required to protect your changing environment from today’s API attacks. WAFs and API gateways rely on signatures and known patterns: WAFs and gateways can’t detect unique API vulnerabilities such as business logic abuse and authorization exploits because they rely on signatures and well-known attack patterns for detection. The most glaring example of this limitation is the fact that neither WAFs nor API gateways can detect today’s most common type of attacks, which target broken object level authorization (BOLA).
- API management components are vulnerable: self-service portals and data stores that are often included in these API management tools have been known to be exploitable by attackers, expanding the attack surface available within an organization.
- Proxies don’t agree with APIs: both APIs gateways and WAFs depend on proxying which is known to slow down API communications. To protect performance, organizations often don’t mediate every single API with a gateway or WAF, meaning there is no visibility into potential abuses of these APIs.
Question 3: Can Shift Left Practices Secure Our APIs?
Shift left practices aim to improve security practices in organizations by pushing more security processes into the design and development phases. Although detecting and fixing API security issues early in the development lifecycle is undoubtedly valuable, traditional testing tools often rely on well-defined patterns and weren’t built specifically with APIs in mind.
With API designs varying greatly between organizations, there are several types of security issues that can’t be detected by commonly used design and developer testing tools, and end up being deployed into production. It’s important that organizations recognize the limits of shift left when it comes to API security and don’t assume that security will be baked into every API during the development phase.
While shift left practices certainly have merit, the business logic flaws that are commonly behind today’s API attacks can only be spotted through continuous, automated runtime analysis. An API security solution needs to provide protection across the entire API lifecycle.
Learn what it takes to secure APIs, how to evaluate API security offerings, and the capabilities needed to protect your business.
Download NowQuestion 4: Can Zero Trust Architecture Ensure API Protection?
Zero trust architecture came as a welcome development to replace outdated security models that were ineffective in securing today’s application environments which comprise private and public cloud and on-premises data centers. However, its ability to protect APIs is limited due to one key aspect: the primary goal of zero trust is access restriction and APIs need access to function.
Because today’s APIs sit within inner architecture, IP address-based access control methods used in zero trust architecture don’t work when applied to API security. Here’s where zero trust architecture falls short:
- The problem with public or open APIs: many APIs are designed to be consumed by a broad consumer base, making the IP address space of API consumers relatively unknown. It’s also difficult to rely on traditional controls like rate limiting since there may be periodic traffic spikes that are perfectly normal. Public or open APIs are common in many industries that rely heavily on APIs, such as retail, eCommerce and financial services.
- Authenticated sessions and trusted networks can be attacked: today’s attackers can breach trusted channels and authenticated APIs by hijacking authentication materials such as session cookies, authentication tokens or API keys. They can also attack by compromising protocols, endpoint devices and network elements, making zero trust practices insufficient to stop attacks.
- Prompting is a deal breaker in machine communication: zero trust network access (ZTNA) solutions and two-factor authentication (2FA) can’t be used in machine-to-machine or direct API communication, which are commonly used. The need for manual intervention in these instances creates security difficulties in cloud-native design and DevOps initiatives.
- Metadata isn’t always a given: using metadata about a machine identity is needed to inform access controls, but its existence is dependent on appropriate tagging and labeling, which may not always be performed or kept up to date by owning teams. This is even more problematic when machines run within containers, serverless technologies or other ephemeral resources.
Question 5: Who is Accountable for API Security?
API security will inevitably touch several teams within your organization, making it hard to decide who needs to be ultimately responsible for it.
Ideally, you need dedicated API security leads within your organization who understand its complexity and are able to take ownership of it, so identifying your API security experts would be step number one.
You may be able to find people who are knowledgeable in API security in your development, application, security or product teams, so the end goal would be to end up with a multidisciplinary team of API security leads who can drive collaboration across all relevant teams and ensure your API security strategy addresses threats across the full API lifecycle — from discovery and deployment to runtime detection and response.
Question 6: What’s Needed to Protect APIs?
Today’s attackers use reconnaissance techniques to reverse engineer APIs and understand their structure and unique business logic. These attacks take time and rely on low and slow activity to look for vulnerabilities and exploit them.
Since attacker reconnaissance activity looks like normal API traffic to traditional tools such as WAFs, API gateways, and other proxy-based solutions, they inevitably miss the attacks that target unique API vulnerabilities. These traditional tools leave significant gaps and are not enough to protect APIs.
API security solutions must automatically and continuously analyze API traffic to learn normal behaviors for each unique API and gain the context needed to identify anomalies, pinpoint attackers and protect APIs. Dedicated API security requires three core capabilities:
Discovering New and Modified APIs: an API security solution must have the capability to discover all APIs, including shadow APIs and zombie APIs. To keep up with the ongoing release of new and updated APIs, discovery must happen automatically and continuously and must cover all partner-facing, internal, and customer-facing APIs.
Ideally, a dedicated API solution should also be able to identify sensitive data exposure to help your organization understand risk and remain compliant.
Detecting and Stopping API Attacks in Runtime: in order to detect and stop modern API attacks, an API security solution needs to analyze and correlate API activity to create a baseline of normal behavior and identify activity that falls outside of that baseline. This will allow you to tell the difference between normal changes in API traffic caused by API changes or user behavior, and malicious traffic stemming from attacker activity, enabling you to detect and stop attacks early during the reconnaissance stage.
Traditional security tools can only inspect each transaction in isolation and identify known malicious traffic and are unable to use context and correlation to identify and stop malicious activity.
Stopping today's sophisticated API attacks requires a breadth of context that can only be gained by using cloud-scale big data and leveraging AI and ML technology to correlate millions of API calls over time.
Shift Left Practices to Eliminate Vulnerabilities in Development: any software will be deployed into production with gaps, even if DevOps teams follow development best practices and make use of scanning tools. APIs are no exception.
You can only prevent the exploitation of any API vulnerability that makes it into production using runtime protection, but flaws must be identified and eliminated in development to improve your overall API security practices.
An API security solution needs to detect potential issues and feed them back to developers early in the development cycle, to help them eliminate vulnerabilities before APIs are deployed into production.
Providing DevOps teams with insights on vulnerabilities found both in development and in runtime can help teams prioritize remediation efforts and eliminate weaknesses and continuously enhance your organization’s security posture.
Ask the Right API Security Questions to Strengthen Your API Strategy
By asking the above API security questions, organizations can prepare a more comprehensive API security strategy.
APIs keep us all connected to critical data and enable digital innovation in today’s connected world. Acknowledging the need for dedicated API security solutions, market research firm Gartner added API Security as a distinct tier in their updated Security Reference Architecture. With this new architecture, Gartner recognizes that these traditional tools leave gaps and are not enough to protect APIs.
Organizations need to develop a robust API security strategy that goes beyond traditional security solutions and provides full visibility, rich context into API behavior over time, and shift left capabilities to improve overall security. Only cloud-scale big data, combined with ML and AI, has the ability to provide the depth of context required for today’s API security needs.
If you would like to learn about the Salt Security API Protection Platform, please feel free to contact us or request a customized demo.
