Whitepaper: Hacking Banks and Cryptocurrency Exchanges Through Their APIs Download Now  

API Security

API Security Definition

API Security involves the implementation of security best practices for Application Programming Interfaces (APIs), often found in modern applications. An API enables an application’s client-side in the form of a web app or a mobile app to interact with its server-side. 

APIs make creating a client-side app simpler for a developer. This basic feature, accessible from anywhere via public networks, means that APIs are well documented and easily reverse-engineered. Along with being highly sensitive to denial of service (DDOS) attacks, this makes APIs appealing targets for bad actors. For example, an attacker might attempt to access private information or disrupt functioning for other users by bypassing an application's client-side.

API security focuses on addressing the possible consequences of direct interactions between the API and malicious hackers and secures the application layer. Web API security includes the detection and remediation of attacks on APIs, the exploitation of API vulnerabilities described in the OWASP API Security Top 10 and through API reverse engineering, as well as API access control and privacy.

API security also encompasses protecting the integrity of the digital environment from not just API cyber-attacks, but also API misconfigurations and API vulnerabilities. API security goes beyond protecting APIs from attack; it also includes protecting the digital environment and data from all the risks associated with APIs. This mental shift appears simple, but it has significant implications for API security strategies, processes, and tooling.


What Is API Security?


Because Application Programming Interfaces or APIs are critical to digital transformation strategies, securing them is a core challenge. Often misunderstood and frequently overlooked by application security managers and software developers, APIs are a rapidly expanding attack surface.

According to OWASP: “APIs are a critical part of modern mobile, SaaS and web applications and can be found in customer-facing, partner-facing and internal applications. By nature, APIs expose application logic and sensitive data such as Personally Identifiable Information (PII) and because of this have increasingly become a target for attackers. Without secure APIs, rapid innovation would be impossible.”

APIs represent a foundational element of innovation in a world driven by apps. Autonomous vehicles, modern banks, IoT, secure retail, and infrastructure such as smart cities and transportation all rely upon APIs.

APIs in a world driven by apps

APIs act as software intermediaries, enabling applications to communicate and share data while providing protocols, routines, and tools for software developers. Web APIs forge connections between applications and platforms and services such as databases, games, social networks, and devices. Internet of Things (IoT) devices and applications also use APIs to collect data, and sometimes even to control other devices.

API Security, including mobile app API Security, focuses on understanding the unique security risks and vulnerabilities APIs present, strategies for mitigating those risks and vulnerabilities, and generating solutions that address both prongs of the task.

According to OWASP, API based apps are different in several ways:

  • APIs expose the app's underlying implementation
  • Clients consume raw data
  • Additional parameters (object IDs, filters) are sent in each HTTP request
  • The server is used more as a proxy for data
  • The client, not the server, is the rendering component
  • The client usually monitors and maintains the user’s state

Businesses are using APIs more than ever to transfer data and connect services thanks to the quick expansion of microservices and the corresponding push to build more applications more rapidly. But this has also increased the web API security challenge, since it has meant more application functions, both from inside the business and third parties, in communication.

Authorization issues including broken object level, function-level, and user-level authorization; insufficient logging and monitoring; security misconfiguration; and excessive data exposure are some of the most critical API security risks.

What Is the API Security Process?


The API security process varies depending on which API implementation is in place. API implementations are most often either REST or SOAP. Another emerging API style is GraphQL, an open-source API standard project.

REST (Representational State Transfer) APIs use HTTP to obtain data and perform operations on remote computer systems. It achieves REST API security by supporting SSL authentication and HTTPS.

REST APIs also support the Transport Layer Security (TLS) encryption standard. TLS verifies that the data sent from server to server or server to client is unmodified and encrypted, keeping internet connections private. Sites with URLs that begin with “HTTPS” (Hyper Text Transfer Protocol Secure) are protected with TLS.

REST API security also uses JavaScript Object Notation (JSON), a file format that simplifies data transfer over web browsers. REST is stateless; to satisfy any given HTTP request, neither the client nor the server need retain any data, because each request contains all of the necessary information. REST does not require the repackaging of data and instead leverages standard HTTP requests, unlike SOAP, which requires routing and parsing for each request to function on a local web service. This makes REST APIs much faster than SOAP APIs.

SOAP (Simple Object Access Protocol) is an XML-based messaging protocol. SOAP APIs use Web Services Security (WS Security), built-in protocols. These protocols are defined by confidentiality and support standards set by the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS), the two major international standards bodies. SOAP APIs verify authentication and authorization using a combination of XML signatures, XML encryption, and SAML tokens.

The envelope-style of payload transport and built-in standards of SOAP APIs demand more overhead to work with compared to other implementations such as REST. However, SOAP APIs are generally praised for their more comprehensive security. For this reason, SOAP APIs are recommended for organizations that require more comprehensive compliance and security, such as businesses that handle sensitive data.

GraphQL, a newer open-source API standard project, is another API style popular with front-end developers. Many developers like GraphQL because it removes fixed API methods and URI patterns in favor of the ability to customize queries based on application needs and context. This helps developers retain control, optimize performance, and provide more functional upgrades.

Both the REST and GraphQL co-exist, as GraphQL isn’t a substitute, despite its popularity. In fact, the rise of GraphQL is causing a disruption in that GraphQL uses its own query language to identify the data requested, typically embedded inside an HTTP POST body, instead of identifying the data being accessed via the HTTP URI as in REST scenario.

However, because all resources are accessed through a single URI in a GraphQL API, this creates a type of API traffic that is often unsuited for existing web API access control systems and infrastructure. GraphQL access control rules may require access to the structured data in the API payloads and the ability to interpret it for access control purposes. When selecting the right approach, API providers must consider which will be best suited to each set of requirements.

Other API technologies include gRPC and XML-RPC. Advanced API solutions should be able to support all of these.

What Should API Security Include?

The Open Web Application Security Project (OWASP) is the collaborative, non-profit online community that creates the OWASP Top 10 as well as other methodologies, articles, tools, documentation, and technologies aimed at improving application security.

Since 2019, the OWASP Top 10 project has included a version directed specifically at the top 10 API security risks and vulnerabilities and how to mitigate them. The new OWASP API security project recognizes the critical role of APIs in application security and tracks trending issues on the security radar that are API-specific.

OWASP API Security Top 10


The following are the OWASP API Security Top 10 from 2019:

“API1:2019 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.”

APIs increase the Attack Surface

APIs create a wide potential attack surface because they frequently expose endpoints that handle object identifiers. Usually implemented at the code level, object-level authorization is a mechanism for controlling which objects users can access and how they are able to access authorized objects. In modern applications, access control and authorization mechanisms are diverse and complex. Software developers often forget to apply even existing authorization checks an application implements as part of a proper infrastructure before accessing an object.

Many API endpoints are vulnerable to broken object-level authorization (BOLA). Attackers can easily exploit these weak API endpoints by manipulating an object ID within an API request that is sent. The server component of API-based applications does not track the client's state entirely. Rather, to make object access choices, the server component typically relies on object IDs and other parameters sent from the client. Therefore, these types of vulnerabilities are inherently common in API-based applications.

Regardless of data sensitivity or how data is classified, any unauthorized data access via these kinds of authorization flaws is both severe and difficult to detect. Object-level authorization checks should be implemented at every API endpoint that receives object IDs and performs actions on the corresponding objects. To verify that the user logged-in has access to perform the requested action on a requested object, these checks should continuously be conducted throughout a session.

Successful BOLA attacks can result in full account takeover. For example, an unauthorized attacker can change account credentials by compromising a password reset flow. Broken improper object-level authorization can also result in unauthorized data exfiltration, viewing, modification, or destruction.

Many traditional security controls miss BOLA attacks because they fail to establish normal API usage and understand API context. To successfully prevent these attacks, web API security solutions must master an API's business logic to detect when authenticated users try to gain unauthorized access to the data of other users. To understand what type of usage is normal and deepen understanding of the context, it is necessary to analyze large amounts of API traffic.

“API2:2019 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.”

API authentication is complicated, and can verge on confounding. It may not be clear to security and software engineers how authentication should correctly be implemented or where the boundaries of authentication lie. As well, it is not always possible in direct API communication to prompt machines or users for additional authentication factors and credentials. Furthermore, especially if the authentication mechanisms are public or otherwise entirely exposed, attackers find authentication mechanisms to be easy targets.

These issues render the authentication piece of API security potentially vulnerable to many advanced authentication exploits and attacks, including credential cracking, credential stuffing, and brute-forcing of authentication.

There are basically two reasons why authentication in APIs is a problem spot. The first is that API endpoints are not the same as standard endpoints; they are responsible for authentication and so must be treated differently, with extra layers of protection implemented.

The second is that mechanisms are frequently misimplemented, either in inappropriate cases or without proper consideration of attack vectors. An example of a misimplemented mechanism might be an authentication mechanism designed for a web app for eCommerce sites that is used for an app deployed on IoT devices.

That said, there are many technical factors that can cause broken authentication in APIs. Some of these include:

  • Insufficiently complex password
  • Missing or excessively high account lockout thresholds
  • Missing password history
  • Excessively long durations for certificate and password rotations
  • Failure to properly implement certificate-based authentication by provisioning unique certificates per device
  • Insufficient authentication token entropy
  • Exposed authentication material in GET requests and URLs
  • Failure to validate authentication material
  • Acceptance of API keys alone as authentication material
  • Use of broken or weak ciphers
  • Use of small key sizes in hashing or encryption algorithms
  • Poor choice of algorithms based on use case
  • Insecure configuration of JSON Web tokens (JWT)
  • When authentication flows are targeted, failure to dynamically challenge with two-factor authentication (2FA) or CAPTCHA, or otherwise step-up authentication


Attackers who successfully exploit authentication mechanism vulnerabilities can gain unauthorized access to the data of other users, take over user accounts, or make unauthorized transactions as another user. A related issue targets APIs designed for direct API communication, a type of machine communication. A successful attacker of that type of authenticated session can gain access to whatever data the machine identity is authorized to access. Cloud-native variants of this type of attack exist which compromise server-side API metadata services and workload authentication.

Broken user authentication attacks frequently include malicious API enumeration and brute-forcing attacks that use minor changes to make high volumes of API requests. Other common versions of these attacks may target broken or weak authentication.

Traditional security measures may only verify the presence of an authentication token or session identifier in a given request and often fail to enforce authentication at a granular level. API management access control policies of API gateways may enforce authentication, but only when policy is appropriately defined by the relevant teams. Operational breakdown between teams developing, publishing, and securing APIs are frequent.

API Gateway Security

Moreover, complicating API gateway security is the fact that API gateways lack contextual understanding for each use case to determine what authentication is proper. API gateway security architecture is also potentially complex, further muddying the picture.

To identify and mitigate various types of advanced authentication attacks such as credential cracking and credential stuffing, it is essential to monitor attack traffic and API endpoint security over time. Traditional security controls lack these capabilities, and often aim instead to detect basic brute-force attack attempts by relying on excessive API consumption rates.

The best API security testing tools are capable of:

  • monitoring and profiling the typical authentication sequence for each API flow to guard against broken user authentication attacks
  • detecting abnormal behavior such as missing authentication factors, missing credentials, or out of sequence authentication calls
  • analyzing large amounts of production API traffic to determine a baseline and identify behavior that is abnormal.


“API3:2019 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.”

Excessive data exposure exploits are relatively simple. APIs often rely on clients to filter data, and send more information than is needed in an API response. This means it is up to the client application to render a view for users. Typically, attackers perform these by sniffing traffic, searching for sensitive data such as email addresses, account numbers, access tokens, and phone numbers that should not be returned.

Software developers at times try to implement APIs without considering exposed data's sensitivity since APIs are used as data sources. Traditional runtime detection and security scanning tools will sometimes detect this type of vulnerability, but they lack the deep understanding of the API context and application design to differentiate between sensitive data that should not be returned and legitimate data to be returned from the API.

Traditional security tools typically employ basic message filtering and pattern matching to identify regular expression (regex) patterns, or which data types are sensitive. These filters are good at detecting sensitive data types such as social security numbers (SSNs) or fields that are well-defined. However, because they fail to comprehend business logic flows and API context, they produce too many false positives, alerts, and blocked requests, and can hurt performance. Teams often use API gateways to mediate and secure API calls that contain sensitive data and cope with this issue.

A good API gateway security solution should offer these capabilities related to excessive data exposure:

  • identify the wide range of types of sensitive data that may present in API requests and responses
  • monitor and track sensitive data
  • provide a baseline and API access per endpoint and per user
  • identify excessive consumption of sensitive data
  • offer deep API context and a spectrum of response actions
  • fewer alerts or blocked requests from legitimate sensitive data transmissions.


“API4:2019 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.”

Obviously, API requests consume CPU, memory, network, storage, and other resources—but just how many are required to satisfy a request depends greatly on the business logic of the endpoint and user input. When APIs fail to restrict the number or size of resources that users or clients can request, this can negatively affect API server performance, leading to Denial of Service (DoS). It also makes enumeration and brute-forcing attacks—including automated attacks like token cracking and credential cracking—against APIs that provide data fetching and authentication functionality more likely.

Lack of resource limiting enables attackers to launch application-level DoS attacks, by overwhelming applications with a single API call in some cases, impacting application responsiveness and performance or rendering them unresponsive. These API security attacks go beyond affecting availability, potentially exposing the API, application, or system to excessive data leakage and authentication attacks.

Lack of rate limiting enables an attacker to submit high volumes of API requests to brute force login credentials, exfiltrate large amounts of data, overwhelm system resources, or quickly enumerate through large data sets.

Traditional security controls typically provide static or basic rate limiting. At scale these are difficult to enforce, particularly since security teams may lack the application design context that would enable them to thwart attackers by enforcing limits without hurting business functionality. Many solutions fail to scan outbound requests and responses, or lack the context to understand what a normal value looks like, and will therefore miss API security attacks focused on overwhelming the application with a single manipulated API parameter value.

Effective API security software and other API security solutions deal with lack of resources and rate limiting risks by:

  • identifying alterations to API parameter values and calls to API endpoints that fall outside of normal usage
  • analyzing all API traffic including egress traffic
  • creating a baseline of typical behavior
  • identifying deviations from the baseline.


“API5:2019 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.”

Often, authorization flaws are often caused by misconfigured or improperly implemented authorization. Broken function-level authorization (BFLA) and BOLA are somewhat similar in that both are created by increasing complexity of roles, although in BOLA attackers target objects that APIs interact with. In BFLA, attackers target API functions, attempting to exploit vulnerabilities to escalate privileges vertically or horizontally.

API calls are predictable and well-structured, making these flaws in APIs easy for attackers to discover. Attackers can intercept and manipulate API requests originating from client applications or send legitimate API requests to an API endpoint they should not be able to access to exploit broken function-level authorization vulnerabilities. This allows them to create and delete accounts, gain access to unauthorized resources, take over accounts of other users, or gain administrative access by escalating privileges.

API security solutions must baseline HTTP access patterns that are typical both per user and per API endpoint continuously. This can allow the detection of HTTP methods sent to specific API endpoints or calls with unexpected parameters. As a result of modern development and release practices, APIs can experience rapid change, making continuous baselining crucial.


“API6:2019 Mass Assignment: Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on an allowlist, usually leads 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.”

To help speed up and simplify development within modern application frameworks, developers often use functions that bind input from the client into internal objects and code variables automatically. Attackers can turn this to their advantage by overwriting or updating properties of sensitive objects that should have remained hidden. These mass assignment vulnerabilities are also called object injection or autobinding vulnerabilities.

A deep understanding of API structure, application business logic, and objects relations are all necessary to exploit mass assignment vulnerabilities in APIs. Of course, APIs expose property names and underlying implementation by design. However, attackers can also explore other API endpoints, probe the API to intuit object properties, read API documentation, reverse engineer client-side code, or prompt an informative response from the API by providing request payloads with additional object properties.

To some extent, APIs must be exposed to facilitate data exchange and functionality. This leaves APIs and API-based applications more at risk from mass assignment vulnerabilities. Application objects today contain numerous properties. Many of these variables such as user name or address can be directly updated by the client, but user access entitlements and other sensitive properties should not be in the same category.

If an API endpoint converts data provided by clients such as JSON attribute-values pairs automatically into internal object properties without assessing property exposure level and sensitivity, it is vulnerable. Typically, mass assignment vulnerabilities arise from binding client provided data to data models without properly filtering the data properties based on an allowlist.

The result of an exploit of mass assignment vulnerabilities is an attacker who can update object properties to tamper with data, escalate privileges, and bypass security mechanisms. For example, an attacker might alter an API call to update their account, bypass the secure single sign on process, and escalating their privileges and role to “admin”.

To cope with mass assignment vulnerabilities, API platform security solutions must be able to:

  • generate a profile of normal, baseline API behavior continuously
  • identify attackers during the reconnaissance phase as they probe the API to learn the business logic and API structure
  • identify manipulated API requests with unauthorized parameters and other anomalous API activity
  • identify API calls that contain additional atypical parameters and anomalous behavior.


“API7:2019 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.”

API Security misconfiguration


This category basically includes a broad range of security misconfigurations that often inadvertently introduce vulnerabilities and negatively impact API security overall. Examples of security misconfigurations include open cloud storage, configurations that are ad-hoc or incomplete, insecure default configurations, misconfigured HTTP headers, overly permissive Cross-Origin resource sharing (CORS), unnecessary HTTP methods, and wordy error messages.

Security misconfigurations can provide attackers with application and API component knowledge during the reconnaissance phase. Stack trace errors and other detailed errors can expose sensitive system details and user data that can assist an attacker in locating technology that is potentially exploitable, including misconfigured or outdated application and web servers. Attackers can also adapt their attacks against using APIs exploit misconfigurations.

Many automated tools exist for detecting and exploiting known and common misconfigurations. However, misconfigurations can also exist in third-party dependencies, in underlying code, or in integrations with other enterprise architecture.

An API security solution must be able to:

  • identify security gaps and misconfigurations for an API and its supporting infrastructure
  • suggest remediation when the application server is not configured to mask sensitive data in the response or reject the request and attempts to manipulate are made
  • analyze all API activity to assess the nature of typical API activity and establish a baseline
  • help identify sensitive data and excessive data in error messages
  • help identify reconnaissance and other early attacker activity concerning security misconfigurations, business logic, and API structure.


“API8:2019 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.”

Structured Query Language (SQL) injection is one of the best-known injection flaws which affect web APIs, but other varieties include NoSQL, Lightweight Directory Access Protocol (LDAP), Extensible Markup Language (XML), operating system (OS) commands, and Object-Relational Mapping (ORM).

Attackers prey on these vulnerabilities by sending the API malicious data which will then be parsed by the application server or processed by an interpreter who is tricked into executing the unintended commands. They pass the malicious data on to an integrated service, such as a database-as-a-service (DbaaS) or a database management system (DBMS), either because they expect the data to be filtered by other server-side code, or because they simply lack the direct filtering.

Injection can result in data loss, disclosure of information and sensitive data, denial of service (DoS), or complete host takeover. Attackers may be able to perform remote code execution, release masses of sensitive information, create new functionality, or bypass authentication altogether.

Effective API security services must be able to

  • analyze all API traffic to establish what typical API behavior looks like and provide a contextual baseline
  • monitor all vectors to identify attackers with potentially malicious data since injection flaws can be exploited in various locations of a request, including cookies, headers, message body variables, and URL query parameters, depending on the architecture of other backend application systems and components
  • use the contextual baseline to identify anomalous data that is potentially malicious in API requests without the need for pattern matching or signatures
  • detect even advanced injection flaws and attacks using the latest methods early and successfully.


“API9:2019 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.”

To accurately assess and prepare for potential risk and exposure, it is critical to maintain an up-to-date, complete API inventory with accurate documentation. It is more difficult to identify older versions of APIs that should be targets for decommissioning with an incomplete or outdated inventory. Replete with holes in the API attack surface, inaccurate documentation makes identifying vulnerabilities in need of remediation more difficult, and risks unknown exposure of sensitive data.

Security tools typically do not monitor or protect unknown or shadow APIs and forgotten or zombie APIs. Some known API endpoints may also have partially undocumented or unknown functionality, called shadow parameters, which are similarly at risk. These APIs and their serving infrastructure are often vulnerable to attacks, remaining unpatched, enabling attackers to gain unauthorized access to sensitive data, or even full server access.

API security systems must be able to:

  • continuously analyze all API traffic and discover APIs
  • identify all API endpoints, host addresses, API parameters, HTTP methods, and their data types
  • identify and classify sensitive data
  • provide ongoing discovery
  • maintain accurate API documentation and an up-to-date catalog of the API environment even as updates are made to existing APIs and new APIs are introduced.


“API10:2019 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: Insufficient logging and monitoring


The dangerous combination of insufficient logging and monitoring and missing or ineffective integration with incident response enables attackers to compromise systems, exploit or abuse APIs, perform reconnaissance, advance attacks, maintain persistence, and move across environments undetected. There is a direct relationship between the amount of time an attacker is present and invisible in the API environment and how likely it is that the attack causes real harm.

API security solutions must be able to:

  • monitor and analyze all API activity
  • provide actionable security events and other logging and incident response capabilities for the organization’s security information and event management (SIEM)
  • differentiate between abnormal behaviors that are benign and those that are malicious
  • reduce low priority alerts and false positives
  • provide consolidated alerts, a consolidated view of attacker activity, and detailed attacker timelines based on correlated event data to assist with incident response and investigations.


Common API Security Threats

Above the OWASP API Security Top 10, there are additional API security risks to consider. APIs frequently self-document details such as their internal structure and implementation, freely offering cyber-attack intelligence for would-be attackers. Additional vulnerabilities, such as insecure endpoints, lack of encryption, weak authentication, and business logic flaws put APIs at risk.

Beyond what we have discussed above, here are some of the most common threats APIs face.


Man In The Middle (MITM)

API Security: Man in the middle attacks

The perpetrator of a man in the middle (MITM) attack secretly intercepts, relays, or alters API messages or other communications between two parties to acquire sensitive data. For example, an attacker can interfere as a man in the middle between a user’s browser and an API issuing a session token in an HTTP header. The attacker who intercepts that session token gains access to whatever login credentials, credit card information, and other personal details are in the user’s account.


API Injections (XSS and SQLi)

The perpetrator of a code injection attack such as SQL injection (SQLi) or cross-site scripting (XSS) inserts malicious code into a vulnerable software program. For example, an attacker can insert an SQL command to delete data or other malicious commands into an API message, or inject a malicious script into a vulnerable API to target the browsers of end users in an XSS attack. Any web API that needs processors or parsers is vulnerable.


Distributed Denial of Service 

The perpetrator of a distributed denial-of-service (DDoS) attack uses multiple systems to flood the resources or bandwidth of a targeted web server or system. In the context of an API, a DDoS attack attempts to overwhelm capacity and memory by sending or requesting massive amounts of information with each request, or by flooding it with multiple connections.


Credential Stuffing

It is easier than ever for hackers to take over legitimate accounts and access valid credentials, essentially bypassing the outer layer of rules for access control. Credential stuffing is this practice of gaining unauthorized access by using stolen credentials on API authentication endpoints. Attackers may purchase valid credentials on the dark web or engage in credential stuffing, and then extend reused passwords to other valid accounts.


API Security: Credential stuffing


Hacker Users

More advanced hackers may create the illusion of being a valid user by applying sophisticated access control rules. The attacker may actually have signed up as a user of the application using a social media account or a fake email address or may even be an insider.


Stolen Tokens

There are several ways to leak OAuth tokens, including through public repos on GitHub and phishing. This sort of lightweight bearer token can be used by anyone from anywhere until it expires.

It is possible to mitigate these risks by setting high API security standards, following best practices and deploying an effective API security platform.

What are the Steps in API Security?

Clearly, with such a broad attack surface and so many inherent challenges, it is critical to follow API security best practices. Here is an API security checklist to assist in securing APIs and avoiding security risks.


Prioritize Security

Unsecured APIs can cause serious harm to organizations. This means that API security should stay top of mind from the start, and everyone on the team should realize that it's fundamentally their problem. Make API security a priority by baking it into the design and development of your APIs throughout the process.


Identify Vulnerabilities

Only by identifying which parts of the API lifecycle are insecure can organizations effectively secure APIs. However, particularly as the use of APIs scales, identifying these vulnerabilities is a challenge.

Because APIs are software artifacts in their own right, and must therefore follow a complete lifecycle that includes retirement and maintenance, it is important to consider the API lifecycle in its entirety as an API security testing checklist is developed. The team should stay current with all drivers, network, operating system, and API components, and understand how everything functions, alone and together. This kind of insight assists team members in identifying weak spots that attackers might use to target APIs. They should also track data leaks and search for security issues with sniffers as part of this process.


Inventory and Manage APIs

An organization must first be aware of their publicly available APIs to secure and manage them, whether there are ten or hundreds of them. Conduct perimeter scans to discover and create an up-to-date inventory of all your APIs, old and new. Manage them in collaboration with DevOps teams to ensure there are five pieces of information for every API:

  • what types of sensitive data it interacts with
  • the identity of the owner
  • whether it is routed externally or internally
  • associated physical resources such as server name, instance id, etc.
  • to which business unit or app it belongs.


Develop a Threat Model

Threat modeling, most often used as a preventative measure, is a structured risk identification and evaluation approach. Threat models should also be deployed far beyond the preventative stage, with a strategy that is automated yet controlled, as a continuous cycle for identifying, mitigating, and preventing application vulnerabilities.


Use Encryption and Signatures

Certain organizations may elect not to encrypt truly non-sensitive API payload data, but Transport Layer Security (TLS) encryption is essential for organizations whose APIs exchange sensitive data regularly, such as banking and financial information, credit card details, login credentials, health information, and social security numbers.

In fact, it is a best practice for all organizations and their partners to encrypt data and cipher all exchanges using a technique such as TLS, the next-generation answer to SSL. Standard one-way TLS offers one-way encryption while two-way TLS provides safer, mutual encryption.

Developers must also ensure that only the correct users are decrypting and modifying data by requiring signatures. Neither internal nor external communications should remain in the clear, open to attackers.


Use a Strong Authentication and Authorization Solution

Many publicly available APIs have serious issues with poor or non-existent authentication and authorization. Broken authentication happens when authentication factors—things the client has, knows, or is—can easily be hacked into, or when APIs fail to enforce authentication. Although private APIs in particular, which are intended only for internal use, sometimes fail to enforce authentication, strict access control is critical since APIs offer attackers an entry point to organizational databases.


Use Web API Token Security

In general, using REST API token security or another form of web API security token is among the best ways to secure web APIs. Developers assign tokens to trusted identities and use them as a relatively effective yet simple way to control access to services and resources.


Web API Token Security: Token Based Authorization


OAuth and OpenID Connect

Whenever possible, proven authentication and authorization tools such as OAuth2.0 and OpenID Connect. OAuth, a token-based authorization framework that enables information to be accessed by third-party services such as Facebook or Google without exposing user credentials, is a powerful tool for controlling API access.

API providers rely on third-party servers to manage authorizations. The consumer offers a token from the third-party server, not their credentials. This helps the API provider, who only receives tokens and doesn’t need to worry about protecting authorization data, and protects the consumer who never discloses their credentials.

API resources can be restricted to only the users who should be allowed to access them based on access control rules applied to an incoming token. For example, a rule can determine whether the user or application should be allowed to make a specific API call.

The team uses policy definition tools to define and manage these rules, and they need to be ready to apply at runtime by the policy enforcement layer. To develop these rules, the team considers various characteristics, such as:

  • The user's identity and associated claims or attributes
  • The query being made or the resources being accessed
  • The token's associated application and OAuth scopes
  • The user's privacy preferences.

Integration and processes are essential to consistent access control across API silos in a heterogeneous environment.


Adopt a Zero-trust, Least Privilege Approach

The traditional model for perimeter security holds that what is inside the perimeter is trusted and what lies outside is not. However, especially with remote users, the network is much more complex now, and a zero-trust model (ZTM) makes more sense. The zero-trust approach shifts the focus of security from location to particular assets, users, and resources.

Practice the least privilege principle. This foundational concept of security states that subjects—processes, users, systems, programs, devices—should be granted only the minimum necessary access they require to complete their stated function. Apply this principle equally to APIs.


Budget Time for API Security Testing

Security testing demands money and time, which organizations must plan for. Allot about 5 percent to 10 percent of the budget to security testing, and take the time to learn how to do API security testing.


API Security Monitoring: Audit, Log and Version

Generate forensic reports for specific API keys, tokens, IP addresses, or user identities by recording detailed information about historical API traffic. Stand ready to troubleshoot, audit, and log relevant forensic details from the server when errors occur. Retain that troubleshooting history as long as server production capacity reasonably allows. Use these detailed logs as debugging resources in case of incidents.

Track your API consumption using monitoring dashboards. Use analytics to monitor API traffic across API silos internally. Ideally, you should be able to analyze API traffic metadata and correlate identity, parsing traffic broken down by IP, token, user, and API across API silos.

Integrate your API threat detection and monitoring into your existing security information and event management (SIEM) systems. At regular intervals, review any anomalies detected and adjust the models as appropriate. Highly visible API traffic broken down across each factor offers more insight into both malfunctions and attacks.


Monitor Add-on Apps and Software

Add-on apps and software may add value for users of many basic platforms, but this level of API sophistication also adds complexity and challenges. This popular use of APIs also often gives high levels of authorization rights to developers—in some cases system administrator privileges. These become system vulnerabilities that hackers are aware exist and seek out.


Remove Information That Should Not Be Shared

Similarly, APIs frequently contain passwords, keys, and other information during development that is later overlooked even after they are made publicly available. To limit accidental exposure of secret information, organizations should incorporate scanning tools into their DevSecOps processes.


Expose as Little as Possible

Lockdown information in content, email subjects, and answers, especially in error messages, so it is limited to predefined messages that can’t be customized. Display as little information as possible, especially IP addresses which can reveal locations.

Restrict access to resources with IP whitelists and IP blacklists, if possible. Separate administrator access into a limited number of different roles, and hide sensitive data in all interfaces.


Use Quotas and Throttling

Well-defined throttling limits and quotas are central to preventing Distributed Denial of Service Attacks (DDOS). These attacks flood the system with numerous requests originating from various sources. To help prevent denial-of-service attacks, set a threshold for the system to reject subsequent requests above. For example, if the threshold is 10,000 requests per account, per day, anything more will be rejected.

Rate limiting can also balance availability and access to throttle connections sufficiently to avoid other issues that affect security and performance, such as API spikes, and limit how often and the ways in which APIs can be called.

Quotas also help track API use over history and establish how often an API can be called. This is important because excessive API calls may be a sign of abuse, or a programming error such as an endless loop calling the API.

To protect the bandwidth of the backend system in line with server capacity, restrict system access to a limited number of messages per second. And to avoid abuse of specific APIs or the system generally, restrict access by user or application and by API.


Data Validation

Particularly in large sizes, be suspicious of what the server is set to accept. Refuse excessively large data, added content. Refuse all input via APIs through to endpoints without validation. Help prevent XML bombs and SQL injection by checking parameters using JSON or XML schema validation.

Remember, although we all focus on securing data on the front end, attackers still target the backend of the system. Establish an additional data validation checkpoint on the way out of the network.


API Security OWASP Top 10

Avoid the OWASP top 10 as described above by securing the system against all the OWASP vulnerabilities.


API Firewalling and Visibility

Use a web application firewall that comprehends API payloads. Organize API security into layers with the outer layer holding this API firewall. This outer layer of API security includes basic security processes such as HTTP layer security, verifying message size, detecting and blocking SQL injections, and other early detection and blocking of intruders. The inner layer applies advanced security mechanisms in LAN to achieve a strong level of protection.

However, there is no way to secure what is organizationally invisible. Unfortunately, there are numerous obstacles that prevent security professionals from achieving full visibility into all of an organization's exposed APIs.

API silos, as described in part above, are one obstacle. These silos affect API visibility by applying disconnected governance to incomplete lists of APIs.

The rogue or shadow API is another obstacle to API visibility. Rogue APIs are developed as implementation details and part of an actual application, but are known only by a small group of developers not considered applications themselves. Because they lack visibility into the details of the implementation process, security operatives are typically unaware of shadow APIs.

Finally, APIs have a lifecycle of their own, evolving with new versions over time, as different versions continue to operate, or become deprecated or forgotten as they receive less traffic. For whatever reason, though, there are many APIs out there that are simply off the radar of the security team.

Why is API Security Important? What are API Security Benefits?

Organizations transfer data and connect services with APIs. Exposed, faulty, broken, or hacked APIs are at the heart of major data breaches.

Attackers stole 145 million consumer records including social security numbers from Equifax and data from 50 million Facebook user accounts—and API vulnerabilities were at the root of both attacks. And now Peloton is leaking data for the same reason. These companies compromised user safety and their own security and paid a high price.

Numerous API security attacks happen every day, and most may fail—but that doesn't mean that API security is negotiable. These attacks expose sensitive financial, medical, and personal data for public consumption, leaving organizations on the hook.

Even worse, many organizations essentially run voluntarily at high risk, managing their APIs using the public cloud. This provides an ideal opportunity for attackers and points to the need for more consistent protection of API infrastructures. Ensure audits are recurring and engage in continuous analytics and periodic assessment of the traffic trail.

Of course, the right approach to API security depends in part on the type of data being transferred. An API that connects to a third-party application might need to focus more on how the app funnels information to the internet and whether it leaves the API vulnerable to revealed location, even if data is not sensitive.

Gartner predicts that “API abuses will be the most-frequent attack vector resulting in data breaches for enterprise web applications [by 2022].” Their recommended solution is baking security right into the design of APIs, and making API security a continuous process across the API lifecycle.

The bottom line is that API security is a tremendous challenge, even for juggernauts such as Facebook, Peloton, and Equifax. But APIs demand a dedicated security and compliance approach given their access to sensitive data and critical role in digital transformation.


API Security: Largest company data breaches and leaks

Does Noname Security Offer API Security?

Neither a web API security gateway nor a load balancer can protect against all API vulnerabilities and attacks. Moreover, Noname Security’s testing in customer environments consistently finds that 30% of APIs are not even routed through a gateway. This isn't the result of malicious action—just evidence that APIs are often the right tool in a moment in time to solve an immediate business challenge.

We at Noname Security break down the massive problem of API security into a few manageable pieces. Nearly all API security issues fall into one of three categories:

  • APIs with in-code or in-design vulnerabilities
  • APIs that are misconfigured or misrouted
  • APIs that interact with sensitive information, but shouldn't.

Noname approaches this with its D.A.R.T. Strategy for API security:

  • Discover
  • Analyze
  • Remediate
  • Test



In the discovery phase of the strategy, we conduct an inventory of all APIs, engage in data governance, and create a visual user journey to improve API ergonomics.

It’s important to maintain an up-to-date inventory of all your APIs, old and new. Noname's API discovery includes what type of sensitive data each API interacts with, who owns it, whether each API is internally or externally routed, what its associated physical resource is, and which business-unit or app it belongs to. Noname's out-of-band deployment supports all of this discovery for each API without agents, network modifications, or side-cars. Noname also supports all API technologies, including REST, SOAP, GraphQL, gRPC, and XML-RPC.

Noname's detailed visualization delivers a unique visual user journey to improve developer understanding, improve API ergonomics, and help the team detect anomalous journeys.



In the analysis stage, the Noname D.A.R.T Strategy for API security focuses on misconfigurations and anomalies.

There are over 100 different cases of misconfigurations to discover, analyze, and remediate, such as APIs without authentication validation or rate limits, or internal APIs that are accidentally open to the internet.

Noname verifies over a hundred different configuration policies across your hybrid environment and architecture. Remediation instructions are simple, clear, and actionable for securing internal APIs and other critical repairs.

AI/ML anomaly detection dominates discussions of API security, but it's not a cure-all. AI anomaly detection for APIs is just one, incredibly complex piece of API security design. And because anomaly detection must be online, only some techniques and models are right for deployment. Inaccurate, noisy anomaly detection is useless.



At the remediation stage, Noname enables quick action on any misconfiguration or vulnerabilities, regardless of how they are discovered or reported, so you can manage and aggregate the process through a single workflow.

Noname remediate alerts only on actual problems that require attention thanks to a heavy investment into noise-reduction. This cuts through the morass of false alerts from other API security solutions.



Noname Security’s active testing on APIs enables early discovery of vulnerabilities throughout the entire software development lifecycle. Enterprises can discover misconfigurations and vulnerabilities in pre-production, and actively test deployed APIs to validate integrity. It also improves future code safety by providing more immediate security issue feedback to developers.

Find out more about how Noname Security’s API Security solution can help protect your APIs here.