What is API Security? Your complete guide

What is API Security?

Application programming interfaces (APIs) are the building blocks of modern applications. Think of them as the on-ramps to the digital world. They keep everyone connected to vital data and services, enable all sorts of critical business operations, and make digital transformation possible.

The number of APIs is growing quickly. Our recent survey shows that 26% of businesses use at least twice as many APIs now as a year ago.

All the good things about APIs are also what make them prime targets for attackers. And that’s why companies need to secure their APIs.

The Open Web Application Security Project (OWASP) defines API security as focusing on strategies and solutions to understand and mitigate the unique vulnerabilities and security risks of APIs.

The most important aspect to understand is that API security is not the same as application security. Read on to find out why.  

Why is API Security Important?

APIs are a preferred attack vector for cyber criminals. And the attack surface continues to grow. The average number of APIs per company increased by 221% in 12 months.

As the attack surface has grown, and as more bad actors have realized how lucrative it is to target APIs, the number of API attacks has skyrocketed. That same research report shows that 95% of companies had an API security incident in the last 12 months, API attack traffic grew by 681% while overall API traffic grew 321%.

The bottom line is that existing security measures aren’t working for APIs. They’re not keeping attackers from stealing sensitive data, affecting the user experience, or causing other damage.

To stop attacks, you need a security strategy and technology purpose built for APIs.

Why Is API Security Different?

Security solutions including web application firewalls, API gateways, API management tools, and identity and access management (IAM) tools weren’t designed to prevent attacks on APIs. That’s because securing APIs offers unique challenges:    

• A constantly changing landscape: Given the pace of development, it’s nearly impossible to stay up to date on new and changed APIs. Documentation is always incomplete and often out of date.
• Low-and-slow attacks: Traditional attacks, like SQL injections or cross-site scripting, still happen, but the successful API attacks don’t follow those kinds of “one-and-done” mechanisms that leverage known vulnerabilities. Every API is unique, so every attack has to be unique, as bad actors probe the APIs for business logic gaps they can exploit.
• The shortcomings of shift-left tactics: Standard pre-production testing can find some gaps in API security best practices, but they won’t uncover vulnerabilities rooted in API business logic gaps. And no developer writes fully secure code every time.

What Are the Common Types of Attacks on APIs?

OWASP published the API Security Top 10 to describe the ten most common API flaws. This list is a good starting point for understanding common weaknesses and security vulnerabilities in APIs. Of these, the most common are: 

• BOLA (Broken Object Level Authorization)
• Broken User Authentication
• Excessive Data Exposure
• Security Misconfiguration

BOLA

Broken object level authorization is the most common API threat, accounting for about 40% of all API attacks. Attackers can easily exploit API endpoints that are vulnerable to BOLA by manipulating the ID of an object sent within an API request. Because the server component typically does not fully track the client’s state, these vulnerabilities are extremely common in API-based applications. Automatic static or dynamic testing cannot easily detect BOLA authorization flaws. BOLA authorization flaws can lead to data exfiltration as well as unauthorized viewing, modification, or destruction of data. BOLA can also lead to full account takeover (ATO).

Traditional security controls, such as WAFs and API gateways, miss these types of attacks because they have no ability to understand API context and so cannot baseline normal API behavior. To prevent BOLA attacks, you must be able to spot when an authenticated user is trying to gain unauthorized access to another user’s data, for example. To prevent BOLA attacks, API security solutions need the ability to analyze large amounts of API traffic over time. This approach requires cloud-scale big data so that the system has sufficient storage capabilities to establish a rich baseline of normal activity across millions of API calls and users, over days, weeks, and even months. Only then will the system have the context needed to spot abuses such as BOLA attacks. 

‍Broken User Authentication

Broken user authentication allows attackers to use stolen authentication tokens, credential stuffing, and brute-force attacks to gain unauthorized access to applications. Attackers can take over user accounts, gain unauthorized access to another user’s data, and make unauthorized transactions. Authentication mechanisms present an easy target for attackers, particularly if they are fully exposed or public. Technical factors that can lead to broken authentication in APIs include, among others, weak password complexity, missing account lockout thresholds, excessively long durations for password/certificate rotations, or use of API keys as the only authentication material.

Because traditional security controls lack the ability to track attack traffic over time, they cannot decipher the different forms of advanced attacks that target authentication, such as credential stuffing and credential cracking. An API security solution must be able to profile the typical authentication sequence for every API flow to detect abnormal behavior, such as missing credentials, missing authentication factors, or authentication calls that are out of sequence. To mitigate advanced attacks that target authentication, an API security solution must monitor and analyze large amounts of production API traffic, requiring cloud-scale storage as well as AI and ML.

‍Excessive Data Exposure

When generic APIs provide more data than is needed, an attacker can exploit an application by using redundant data to extract sensitive data. APIs often send more information than is needed in an API response and leave it up to the client application to filter the data and render a view for the user. Relying on client-side code to filter or obscure sensitive data causes problems, as attackers regularly bypass client-side web application and mobile application code and call APIs directly.

Traditional security scanning and runtime detection tools will sometimes alert on this type of vulnerability, but they are unable to differentiate between legitimate data returned from the API and sensitive data that should not be returned. An API security solution must be able to baseline and track API access per endpoint and per user to identify excessive consumption of sensitive data. Moreover, a solution must also provide API context and a range of response actions, so that not every transmission of sensitive data creates an alert or blocked request.

‍Security Misconfiguration

A wide range of security misconfigurations exist that often negatively impact API security as a whole and can inadvertently introduce vulnerabilities. Security misconfigurations can include insecure default configurations, incomplete configurations, misconfigured HTTP headers, verbose error messages, open cloud storage, and more. Misconfigurations enable attackers to gain knowledge of the application and API components during their reconnaissance phase. Attackers can also exploit misconfigurations to pivot their attacks against APIs.

An API security solution must be able to identify misconfigurations and security gaps for a given API and its serving infrastructure. It must suggest specific remediation steps to employ when manipulation attempts are made and the application server itself is not configured to reject the request or mask sensitive data in the response. With the ability to analyze all API activity and establish a baseline of typical API activity, an API solution can help identify excessive data and sensitive data sent in error messages.

But don’t limit your concern about API security to the Top 10. Attackers use other techniques as well. They borrow techniques from application or network attacks. They combine different exploits for an attack. They’ll also automate attacks to increase their chance of success.

Most successful API attacks target gaps in business logic. For example, in the Experian incident, the hacker did lots of trial and error and ultimately determined that if he used all zeroes for birth date fields, he could pull back the credit score of any American. The developers writing the APIs had never considered that kind of manipulation and didn’t require that the fields actually conform to a valid calendar date – they merely require numerals.

What Security Best Practices Can We Apply to Reduce our Risk?

APIs are challenging to protect. Traditional solutions can’t handle the complexities of the API ecosystem. Attackers know this, which is why they focus on APIs.  

The following best practices can help you improve your API security posture:

Development and testing:

1. Promote secure API design and development: Create secure coding and configuration practices for building and integrating APIs. The OWASP Application Security Verification Standard (ASVS) is a good resource.
2. Reduce exposure of sensitive data: Avoid sending too much data to client apps and then relying on them to filter the data.
3. Conduct design reviews: Be sure to include business logic in design reviews.
4. Document your APIs: Documentation helps people understand how an API is built or integrated. You especially need documentation for design reviews, security testing, and protection.
5. Use a machine format for documentation: Use machine formats such as OpenAPI Specification (OAS). Then you can use the specs for basic testing and protection.
6. Maintain an accurate API inventory: Give your security teams a realistic view of the attack surface with an up-to-date inventory. The best way to capture this information is with automated API discovery that covers REST, GraphQL, and other API formats.
7. Do security testing: Use security testing tools to identify configuration issues or vulnerabilities in your APIs. Scanners aren’t good at parsing business logic, so you should analyze your APIs and conduct fuzz testing in runtime to identify exploitable code.  

Production:

1. Turn on logging and monitoring: Telemetry data helps you detect attacks, respond to incidents, and protect APIs in runtime. Use the data as your baseline for normal behavior. That way any outlier events can be quickly identified and resolved.
2. Mediate your APIs: Use mediation tools like API gateways to improve visibility and security. Extend the capabilities of these platforms with an API security solution that provides deeper context about APIs.
3. Identify API drift: Make sure you have a plan for figuring out when an API has changed. Again, automated platforms that can compare documentation against the runtime behavior of your APIs will help identify these gaps. Then update your documentation accordingly.  
4. Use the right network security controls: Some network controls can help with API security. For example, encrypt the data APIs are sending. You can also use dynamic rate limiting and IP address allow and deny lists (assuming the number of API users is small).  
5. Continuously authenticate and authorize: Make access controls and identity stores external. Include API gateways, identity stores, IAM, key management, public key infrastructure, and secrets management in this step. Avoid using API keys for authentication.  
6. Deploy runtime protection: Make sure your runtime protection can identify configuration issues in API infrastructure. It should also detect behavior anomalies such as credential stuffing, brute forcing, or scraping attempts.

Who’s Responsible for API Security?

The short answer is that API security is everyone’s problem. But often making it everyone’s problem means that no one is responsible for fixing it.

That’s why you need to assign people to be API security leads. You can start with your application security team — if you have one. They can often act as security champions within your DevOps teams, and developers, in turn, can teach your security teams about API constructs.

Your API security expertise will likely be scattered across your organization. You may find knowledgeable people in development, and others in infrastructure, operations, or security. Or you may find that experts are concentrated in API product teams.

Across all these API experts, choose a set of API security leads to drive cross-function collaboration across all the groups to ensure discovery, testing, protection, and incident response are all addressed in your API security strategy.

How Can We Protect Our APIs?  

The best protection for APIs is a dedicated platform built from the ground up for API security. The right API security platform should automatically:

• Discover new and changed APIs
• Detect and stop attacks on APIs
• Eliminate vulnerabilities in the build phase

Look for API security that can collect, store, and analyze hundreds of attributes across millions of users and API calls and, more importantly, leverage AI and ML to correlate them over time. Gaining this breadth of context will require cloud-scale big data – server- or VM-based approaches simply won’t have a broad enough data set over time to identify today’s sophisticated API attacks. Only with this depth of context will you have what you need to protect all of your APIs — even the ones you didn’t know you had.

*** This is a Security Bloggers Network syndicated blog from Salt Security blog authored by Michelle McLean. Read the original post at: https://salt.security/blog/api-security-fundamentals