Build a secure API ecosystem to cater to consumer requirements in today’s business world while ensuring trust in the marketplace.
APIs have become the top-most asset for an organization’s digital transformation initiatives, empowering employees, partners, customers, and other stakeholders to access applications, data, and business functions across its digital ecosystem. According to a recent report from Akamai, 83% of web traffic today is now API driven. At the same time, hackers have increased their waves of attacks against these critical enterprise assets. Unfortunately, it looks like the problem will only worsen. Gartner has predicted that,
One API security breach can ruin an organization’s reputation within hours. For example, JustDial is an online directory for services and also offers facilities such as bill payments and bookings for restaurants, cabs, and tickets. In 2019, while implementing multi-factor authentication, they found four old APIs with leaky endpoints. Those API were left forgotten for many years and they were exposing company data outside and millions of user identities were exposed through this. Also within the past year, an API key was discovered in a public GitHub repository that allowed anyone to access Starbucks’ JumpCloud API. The researcher who found the key demonstrated how someone can utilize such keys to take full control of Starbucks’ AWS accounts. If this had happened, it would have allowed hackers to execute commands on systems and add or remove users (Starbucks Devs Leave API Key in GitHub Public Repo).
Many enterprises have responded by implementing API management solutions that provide mechanisms such as authentication, authorization, and throttling. These are must-have capabilities for controlling who access APIs across an API ecosystem—and how often. However, when building their internal and external API strategies, organizations need to address the growth of more sophisticated attacks on APIs by implementing more dynamic and smarter security. Let's examine different security measures related to APIs and how they help to implement a successful security strategy.
Rule-based and policy-based security checks, which can be performed in a static or dynamic manner, are mandatory parts of any API management solution. API gateways serve as the main entry point for API access and, therefore, typically handle policy enforcement by inspecting incoming requests against policies and rules related to security, rate limits, throttling, etc.
Static security checks do not depend on the request volume or any previous request data since they usually validate message data against a predefined set of rules or policies. Different static security scans are performed in gateways to block SQL injection, cohesive parsing attacks, entity expansion attacks, and schema poisoning among others. Meanwhile, static policy checks can be applied to payload scanning, header inspection, access pattern checks, etc. For example, SQL injection is a common type of attack users perform using payloads.
Dynamic security checks, in contrast with static security scans, are always checking against something that varies over time. It usually validates request data with some decisions made with already available data. Dynamic checks are performed for access token validation, anomaly detection, and throttling among others. While rule and policy-based security address most common security requirements, there can be more sophisticated attacks that cannot be caught by them. Let's analyze them now and see possible solutions for these as well.
Policy-based approaches around authentication, authorization, rate limiting, and throttling are effective tools, but they still leave cracks through which hackers can exploit APIs. Notably, API gateways front multiple web services and the APIs they manage are frequently loaded with a high number of sessions. Even if we analyzed all those sessions using policies and processes, it would be difficult for a gateway to inspect every request without additional computation power.
Additionally, each API has its own access pattern. So a legitimate access pattern for one API could indicate malicious activity for a different API. For example, when someone buys items through an online shopping application, they will conduct multiple searches before making the purchase. A single user sending 5 to 10 requests to a search API within a short period of time can be a legitimate access pattern for a search API. However, if the same user sends multiple requests to the buying API, the access pattern could indicate malicious activity, such as a hacker trying to withdraw as much as possible using a stolen credit card. Therefore, each API access pattern needs to be analyzed separately to determine the correct response.
To fill the cracks left by policy-based API protections, modern security teams need artificial intelligence-based API security that can detect and respond to dynamic attacks and the unique vulnerabilities of each API. By applying AI models to continuously inspect and report on all API activity, enterprises can automatically discover anomalous API activity and threats across API infrastructures that traditional methods often miss.
When you select an API management solution for your organization, you will have to pay close attention to security and the level of support. The solution should allow you to expose your APIs to the outside world in a secure manner. While it is mandatory to support standard policy and rule-based security, it also needs to be equipped with additional security measurements such as payload scanning, schema validation, and AI-based security and analysis. Community-driven open-source projects are well-known for their security strengths. Most of the time, an open-source API management solution’s code can be accessed by a wide range of users, and, hence, it will be battle-tested against possible security threats.
WSO2 API Manager is the number one API management solution available in today's market, with all the required security support. If you wish to discuss more about advanced API security-related subjects, please contact us for more information. Our API security experts can schedule a call with you and discuss all the security aspects related to your deployment.Download for Free
An API-first business model is a key driver for resilient growth. Most organizations across the globe have reaped the benefits of digital transformation by exposing their services as APIs. This enables to unlock a wide array of benefits to both the business and the consumer.
In this context, API security becomes a major concern because a particular service is exposed to a global consumer base. Security is anyway important for any IT-based application and this is the same for API-based applications as well. Service owners have to ensure that their services are accessible by only the privileged parties. If this requirement is not fulfilled, it will become a major issue in the whole information system.
That said, there are two sides to this picture. It is vital to address the security concerns in both areas.
When creating an API from a digital service, that service will be encapsulated by the API. All the operations performed by that service will be exposed as services of that API. However, this does not mean that the service is completely isolated from malicious attacks.
If an API is not secure, the whole system might become vulnerable because an API is where the service is exposed to users. When that happens, it could potentially extend that vulnerability to the service as well.
This is the next area that needs to be considered. Here, a particular API can be accessed by various end-users. Hence, there should be a mechanism to authenticate them and ensure the security of the service and resources.
These two aspects can be considered as the lifeblood of any information security system. The system must make sure that if somebody is accessing the services, it should verify their identity (verify who they claim to be). In addition to that, once the authentication step is successfully completed, the system should be able to grant only the allowed actions and service access for that particular user.
When it comes to information security or security of sensitive data assets, both authentication and authorization become mandatory. If not, there is a high risk of exposing information via a breach or unauthorized access, customer churn and legal problems.
It is important to keep this in mind when designing and implementing any kind of information system. Security attacks are unpredictable and the information needs to be safeguarded so that customers can consume that information and services confidently.
In some cases, it is not possible to completely secure a system with authentication and authorization alone. Users might accidentally send malicious requests that might harm the backend service or cause a data breach. This can happen because it is impossible to assume all users are sending legitimate requests all the time.
In API-based information systems, this becomes a high-priority requirement. Harmful requests should not reach the backend service and should be stopped immediately at an early stage. If the system is not capable of catering to this requirement, one malicious request or code can take the entire system down. Even if the user has a valid token or key to access the necessary service, it is important to protect the service and system from unintended consequences.
This is where content inspection comes in handy. The system which resides in between the service and end-user has to “scan” the request and block it if it is harmful to the backend service.
This is another key aspect that every system designer needs to understand. Even though all users are legitimate, there are cases where security can be breached. For example, if a valid credential of a valid user is exposed to a third party and if that third party is using the services without the permission of the originating user, that is a problem.
Pattern and anomaly detection is the solution to address these kinds of scenarios. Usually, if a third party is using a credential of a legitimate user, the usage pattern will show a significant deviation from the normal access pattern.
To avoid and prevent these types of attacks, it is important to deploy advanced security features such as AI-based security. That is the only way to secure the system and data from complex attacks. It is impossible to directly target the culprit; that’s why AI-driven algorithms are required in these kinds of situations.
All users of a system might be legitimate and they all have necessary access rights to respective services. However, does that mean the system is fully secure? No. Because even in this context, users might abuse the system (sometimes unintentionally). That is where rate-limiting comes into play.
In real-world applications, it is very important to manage API traffic. If this is not done properly, there will be many issues such as sudden downtimes or service overloads. This aspect is somewhat related to the scalability of the system as well.
The system should have the ability to regulate incoming traffic in a well-organized manner and make those services (APIs and applications) available to different consumer groups. This should happen in real-time across the whole deployment (in all regions if it is a multi-region deployment).
If this aspect is neglected, there will be sudden spikes, which in turn will lead to the possibility of services crashing owing to the high load within a short time.
As noted above, there are several key security facts that need to be considered when designing an API-based information system. These are important to safeguard a company’s brand name because when systems are secure, more customers use them.
However, the real challenge is implementing all these at once. It is obvious that all these security aspects cannot be handled by the service itself because then the business logic will become more and more complex (and the service will become bulky). This might also be a blocker to adopt new technologies, such as microservices-based deployments.
Fortunately, all these security requirements can be addressed using a robust API management solution. With that, it becomes easier and scalable to prevent these security attacks because the API management solution takes care of those situations. Hence, service developers can fully focus on implementing the core business logic.
WSO2’s API management offering is a practical and robust solution for these scenarios because it is capable of securing APIs from a wide variety of security threats.
When it comes to authentication and authorization, WSO2 API Manager offers the capability to secure APIs using the OAuth2 protocol. This protects the secured resources (APIs) with an access token. Also, it is possible to configure the lifetime of this token so that resource owners can limit access to the secured resources only within the intended time window.
WSO2 API Manager is empowered with advanced threat protection and bot detection features. This will make sure that the system is safe from advanced security threats, such as code injections.
To address rate-limiting requirements, WSO2 API Manager allows service owners to define multiple rate-limiting plans according to the maximum load that can be handled by the backend service. This ensures that the services are up and running without any issues.
Now you are aware of the concerns you need to address when creating a fully-secured API management solution. Keeping these in mind will help you to develop a system that your users will trust.
If you need more information on how to build a secure API management system using WSO2 API Manager, click here and request a free demo from us.
The significant increase in API adoption has led to an exponential increase in data being transferred and exchanged. Within this context, ensuring API security is key not only to prevent malicious attacks and data breaches but also to protect your brand's integrity. Here, we discuss a number of security aspects that developers should consider when developing APIs that are exposed externally.
There are many users that can be accessing APIs that are exposed via an API gateway. Here, client-to-gateway security needs to be ensured so that relevant users with necessary permissions can access their resources without hindrance.
Exposing your APIs using a secure sockets layer (SSL) ensures that the information exchanged between the client and the API stays encrypted. In this case, a man-in-the-middle (an attacker who inspects traffic) will only see encrypted content that can be decrypted only by the server or the client. This is vital to prevent attackers from acquiring sensitive information that is being exchanged.
The following are the four steps involved in establishing a secure SSL connection.
Once the following steps have been completed, the client and the server can communicate securely—away from prying eyes.
Mutual TLS/SSL authentication is utilized mostly for server-to-server communication. This is an authentication mechanism that is relatively very much secure. The authentication flow involves the client and the server both exchanging and verifying their digital certificates. This brings the chances of an attacker interfering with their communication to a bare minimum. The following diagram shows the flow involved.
A basic authentication mechanism involves credentials to be passed with every request. This means that each request needs to possess the client’s user ID and the password. Since credentials are passed with every request, the communication should possess strong transport-level security, which means a developer must make sure to use basic auth only with HTTPS and not with HTTP. With HTTP, an attacker can easily get hold of the credentials and access protected resources.
Making sure that your basic authentication credentials cannot be eavesdropped alone does not make this a secure medium of communication. Let’s take a browser application as an example. Once the user logs in, the application stores the credentials and then uses these credentials for subsequent calls. This makes the credentials vulnerable to prying eyes.
Therefore, it’s not recommended to use basic authentication unless you have dealt with these considerations. Be mindful and use it as the last resort only when other authentication mechanisms are not options for use.
Digest auth is recognized as a mechanism that is complex and much more difficult to implement compared to mechanisms such as basic authentication. This mitigates certain discrepancies of the basic authentication mechanism, such as sending the user credentials in plain-text form. Digest authentication involves a nonce challenge given to the client by the server; the client sends the user credentials hashed by an algorithm, such as MD5, along with the nonce challenge initially provided by the server.
While digest auth is more secure than basic auth and mitigates attacks such as replay attacks, it can be still vulnerable to attacks such as man-in-the-middle attacks. For more information on digest authentication please refer to Digest Access Authentication Scheme.
OAuth is an industry standard authorization protocol that gives limited access to a third-party application in order to consume a HTTP service. This can be done either on behalf of a resource owner or by allowing the third-party application to obtain access on its own behalf using different grant types.
OAuth2 also allows to limit each token’s access using scopes. Also, access tokens can be revoked to limit access to a certain application if needed. Let’s discuss some of the commonly used grant types.
Authorization Code Grant:
The authorization code grant is a commonly used and secure grant to authorize an application to access a protected resource. This process involves a user-agent (typically a browser).
The user is required to login, and then redirected to the application with a temporary code. The application then requests an access token from the authorization server. This request is authenticated with the client secret, so that an attacker cannot use the code to obtain a token.
The token response can include a refresh token, which can be used to obtain a new token once the token is expired.
This grant is mostly used by developers of single-page applications. The flow of this grant is similar to the authorization code grant, but instead of sending a temporary code that needs to be exchanged for an access token, the authorization server redirects the user to the application, with an access token. A refresh token is not provided along with the access token.
Although this may sound convenient, this does impose a security risk; a potential attacker can obtain the access token as the access token is sent along with the redirection URL.
Because of this security issue, single-page application and mobile application developers are leaning towards the authorization grant flow using Proof Key for Code Exchange (PKCE). This does not get rid of the second request, but does not require the client secret to be stored within the application. Instead of a secret, it utilizes a code challenge that is verified upon the second request. For more information on PKCE.
Client Credentials Grant:
This grant is used by an application to obtain access to itself. The application sends its client credentials to the authorization server to obtain an access token. Here there is no refresh token provided. The application will have to request another token with the client credentials, once the token is expired.
This is ssed in most server-to-server communication scenarios.
Resource Owner Password Credentials:
This grant is not commonly used as this requires the application to use resource owner credentials to obtain access. This requires the resource owner to trust the application with their credentials. For example, if the official Twitter app inquires your credentials, you trust that application with your credentials, but you will not have the same amount of trust for a third-party application (these applications use authorization code and implicit grants in these cases).
One might think OAuth was introduced to avoid this, but the difference here is that the password is used only to obtain the token, and once the access token is received, the password is no longer involved. An authorization server should enable the password grant only if it’s necessary. The token response can include a refresh token, which can be used to obtain a new token once the token has expired.
A JSON web token (JWT) grant involves a client exchanging a signed JWT with an OAuth2 access token, subsequent to contacting the authorization server. The authorization server should possess the relevant public key of the private key used to sign the JWT. Then, the access token given by the authorization server can be used to invoke the protected resources as usual.
For all the grant types mentioned above, an API gateway will have to contact an introspection endpoint to validate the token, when it is being used. In the case of self-contained access tokens, this call to the authorization server isn’t required. The reason for this is that a self-contained access token (which is a JWT) contains all the information needed for the validation. One might think that the JWT token sent can be doctored to impersonate another user, but this matter is addressed. When it is generated, the JWT token is signed (using a private key) with the relevant claims. Then, it is validated by verifying it using the relevant public key. Developers must make sure not to include sensitive information of a user, as any party who gets hold of this token can view its contents.
Encapsulating a service via an API gateway and protecting it using client-to-gateway security mechanisms does not completely protect the backend service. There still can be certain scenarios where security of the backend is breached. In order to mitigate this threat, let’s go through some of the aspects to focus on.
Even with strong authentication and authorization mechanisms in place, there is still a chance for an attacker to gain access and send a malicious payload, or a legitimate user might accidentally send one. In this kind of a scenario, the backend service should be protected from these kinds of attacks. This is where payload inspection comes in handy.
When exposing an API, the API gateway layer should be able to inspect the payload sent and look for any malicious content before the payload is processed by the actual service.
There is a throughput limit that a backend service can handle. The resources and the platform the backend is written on can determine this limit. Exceeding this threshold can cause the backend to stop servicing requests. The API gateway layer should possess the ability to regulate the throughput so that the backend keeps serving requests in a healthy manner.
We hope this post was helpful to glean knowledge on how to secure your APIs. Feel free to download our product and experience how we have supported these aspects for developers to host their APIs in a secure manner.
If you require any help with setting up, please follow our comprehensive documentation.
You can also reach us via our slack channels.
Watch the videos on OWASP top 10 vulnerabilities
Digital disruption in the financial services space is no longer the future. It is the here and now. Since 2015, incumbent financial services companies have rapidly increased their investments in digital transformation to meet the challenge of new-breed fintech firms—agile technology startups dominating market share growth by providing more timely and personal financial solutions to businesses and individuals alike.
Driven by these market forces and regulatory projects like the open banking movement, incumbents are looking both to innovate themselves and open channels for more effective collaboration with new entrants. In this backdrop, repurposing and modernizing technology has emerged as a strategic imperative. Since APIs have become entrenched as a cornerstone technology to unlock siloed legacy systems and enable new capabilities, robust and adaptable security architecture is now a key area of focus for technology teams in financial institutions. These teams are tasked with not only connecting with this new, open ecosystem, but responding proactively to the threat of bad actors within it.
There is little doubt that attacks on technology systems at financial services providers are becoming more sophisticated. Even with the industry’s innate focus on data privacy and protection and increased regulatory oversight on security aspects, according to a 2019 report by the Identity Theft Resource Center, the financial services industry contributed over 60% of data exposed in breaches in the US, while 75% of data breaches in the sector were as a result of hacking and malware. These jarring statistics put into perspective the onus to carefully balance innovation with the duty to safeguard customers’ personal financial data.
With the ever-growing demand for seamless financial services offerings by consumers, interconnected open systems allowing more avenues for collaboration are now the norm. As security risks within this space propagate, regulators are intervening in the interests of competition and consumer rights by imposing dynamic and rapidly-evolving regulatory regimes to respond to the fluid nature of the ecosystem and its security vulnerabilities. Robust and adaptable API security with knowledge and conformance with emerging best practices should, in this light, already be a core area of expertise for technology, compliance, and business teams at financial services institutions.
Naturally, banks, fintechs and regulators have been responding to these risks. A prime example of a collaborative effort yielding far-reaching impacts is in the open banking space. Open banking enables customers, banks, and third parties to use and benefit more from the vast silos of data held by banks on their customers. In technical terms, this is done via secure APIs that allow customers or authorized third parties to access data held by the bank. It is envisioned that upon wide adoption, an ecosystem of APIs would be created with various third party applications, services, and intermediary platforms integrating with banks to reinvent financial services using customer data. Emerging as an organized regulatory push first in the EU with the Second Payment Services Directive (PSD2) regime, it has now become a global movement, with Australia, Hong Kong, Singapore, Canada, Mexico, and Brazil among the countries releasing rules and technical specifications. In several countries like the US, financial institutions are looking at open banking as a model for collaboration with the fintech ecosystem even in the absence of regulation.
Of course, in any system to expose sensitive data, adding adequate safeguards to ensure only the right people may access such data is a prerequisite. Data security is an overarching concept in open banking, impacting on API templates, data standards, and security standards. Open banking regulators have in every instance worked closely with specialized technical bodies, like CSIRO-Data61 who developed the Consumer Data Standards specification in Australia, to ensure high standards are met in core functional aspects such as security. These standards represent a comprehensive and evolving reference framework for any financial institution, even outside of regulated areas, to understand and adapt best practices around data security. A prime example of commonly applicable API standards that emerged out of the open banking movement is the Financial-grade API (FAPI) standard developed by the OpenID Foundation and adopted by several regulators within their frameworks. The FAPI-RW standard utilizes OAuth2 for API authorization and OpenID Connect (OIDC) for verifying user identity based on JWT JSON data schemas, REST APIs, and privacy and security recommendations and protocols. The FAPI certification has now emerged as a standard of trust in the financial services sector beyond open banking and in other sectors dealing with sensitive data.
To learn more about emerging API security standards in financial services, browse these resources here.