Key features:
Swagger (now part of the OpenAPI Initiative) continues to help teams design and document APIs. It enables testing through code generation and mock servers.
Key features:
Apache JMeter has evolved beyond just load testing and can now be adapted for API security testing with custom scripts and plugins.
Key features:
SoapUI, both in its open-source and pro versions, is widely used for testing web services, including APIs used in enterprise systems.
Key features:
Karate DSL combines API test automation, performance testing, and mocking in a single framework using BDD-style syntax.
Key features:
Fiddler remains relevant as a network proxy and debugging tool with enhanced API testing capabilities.
Key features:
We talked to many product security experts about where they think everyone should begin their API security program. Here is what they said.
Security and engineering leaders should easily answer key questions: How many APIs are in use and where is sensitive data transferred? In 99% they can’t. It's crucial to have an up-to-date inventory of API methods and which of them handle PII and PHI data. While specialized products exist, open-source solutions like APIClarity can also aid in API discovery.
Zombie, Shadow, and Orphan APIs pose an enormous risk (see 2023 State of the API Report). Proper API Governance includes the process for producing and managing specifications in Dev, as well as identifying noncompliance with specs. OSS tool APIClary can help here, too.
Utilize API gateways for managing, monitoring, and securing API traffic (note: a lot of APIs are actually unmanaged!). This adds an essential API security layer with capabilities like Rate Limiting, Caching, Authentication, Access Control, and CORS. A lot of powerful gateways are open-sourced and have premium options including Kong API Gateway and Tyk.
It’s always better to discover dangerous security misconfiguration and other issues in dev environment vs in production. While not exhaustive, open-source tools like ZAP, openapi-fuzzer, and RESTler provide significant value. There is not best recipe but most companies have a combination of DAST, SAST, and IAST and devtools to help developers develop secure code (such as plugins for IDEs)
API secrets leakage can lead to serious incidents. Regularly scan for exposed credentials, including API keys, in GitHub repositories, Postman collections, and similar platforms to prevent unauthorized access. Code repositories are often spots where engineers accidentally leak API keys. Find leaked credentials with tools like TruffleHog.
Don’t be overwhelmed by the number of APIs to secure. Once APIs are identified, you can prioritized testing and audit based on risk factors suitable for your specific case. Consider aspects like data sensitivity (endpoints handling PII data such as names or SSN), exposure level (external vs. internal API), and the number of parameters.
Many security tools you trusted for years, including scanners and WAFs, may not fully protect your app estate emerging API threats. Moreover, often they don't provide protection for your API stack at all - for example, they may not analyze traffic in GraphQL or gRPC. Test your tools' protocol support using open-source projects like GoTestWAF (read guide) or use our online service - API Security testing platform.
The best place to get familiar with API threats is the OWASP API Security Top-10, or the summary we prepared for you (see the relevant section here). This list is a must-read for both security and eng teams and provides an extensive examination of significant API vulnerabilities and mitigation techniques.
Wallarm publishes quarterly and annual API ThreatStats reports covering emerging API threats, drawing from an analysis of all known CVEs and billions of observed attacks. Consider this a dynamic and up-to-date complement to the OWASP API Security Top-10
Do not reinvent AuthN/AuthZ methods. Rely only on OAuth 2.0, JWT, OpenID Connect, and Bearer Tokens, or other industry standards for your authentication. Couple with stringent authorization checks at each API endpoint for access control. Even minor oversights in authorization have led to catastrophic data breaches in APIs over the past few years.
APIs are developed to be consumed by software and hence inherently prone to abuse. Figure out which APIs are likely to be abused and prepare a plan of action. Rate limiting and throttling are effective but not sufficient against advanced abuses. For such cases, building protection at the application level or employing specialized products is necessary.
In a zero-trust environment, using mTLS between microservices is a best practice.
Thoroughly validate and sanitize all user inputs to avert typical vulnerabilities such as SQL injection, SSRF, and other forms of injection attacks. A proven strategy is to validate all API calls against their specs to screen out potentially harmful requests. An effective tool for this is the open-source API firewall, which functions as a reverse proxy, validating API requests and responses based on OpenAPI and GraphQL schemas.
Maintain API logs and implement real-time monitoring to detect and respond to abnormal actions (including on the session level). This can all help to isolate ongoing incidents swiftly.
Be aware of the implications of LowCode and NoCode tools, especially those with direct data access, as their security aspects are often overlooked. Most of them are using APIs for integrations.
The task of verifying users’ identity is imperative as it keeps ill-usage of API at bay and verifies user authenticity before granting him the access to the stored information kept for better Web API Security. It involves verifying the identity of someone who tries to view or edit the API resources, allowing only authenticated users for the same.
The host-based authentication schema is widely used for IOT devices and raw network authentication. It is not recommended for web technologies since it can be bypassed with spoofing. This process comprises verifying the host or server so that only the verified users can access resources deployed on the servers. It doesn’t demand any key or other means to initiate the process. However, the server should be competent to validate the login keys beforehand to keep the incidents of DNS spoofing, routing spoofing, and IP spoofing under control.
In the process and manner, it’s very much similar to RSA.
The argument used here is either yes or no. By default, no argument is set. The host-based verification of users can be done by an administrator by creating a private key for the local host or extracting the public key used for the localhost.
One of the most straightforward API identity-confirmation schemes, this method is crafted using HTTP protocol and process as the client dispatches an HTTP request with a pre-built header for verification of authenticity and demanding credentials like account’s password and username. This basic check is done in a browser-powered environment.
Being supported by every possible browser and server makes basic identity-confirmation the most common one. The credential details are shared over the network in the form of cleartext and are encoded using base64. The credential details are shared over the network in the form of cleartext (or base64) by default, this is a bad practice since it gives man-in-the-middle attack vectors. The good practice is to encrypt the credentials using algorithms such as RSA, SHA-256 or even custom made ones.
It is functional over proxy servers and grants access to resources not hosted on IIS servers. As it fails to add encryption, not much security can be expected out of it. Also, it’s more prone to replay attacks.
OAuth is the open method of identity confirmation. It is a customary API authenticity-verification technique that covers users’ identity verification and defining authorization criteria. The protocol is used widely for allowing applications to authorize their users based on tokens, published from OAuth server (such as Google).
It requires asking for a token when someone tries logging into the system. The token serves here as the means of verifying and approving the user identity. The person/request-creator has to forward the request to accessing the resource to the authentication server. Based on the quality and result of identity-verification, the server can accept or reject the request.
OAuth is safer and more secure than other processes making it the first choice for many. The three key ingredients of OAuth are OAuth provider, Google and Facebook are the common ones, OAuth Client, refers to the information-owning website/page, and owner, denotes the user making an access request.
A widely used protocol of API access management, OAuth 2.0 is an updated version of OAuth. Its functioning involves keeping the API client access limited by using HTTP services for the client application enabling. Some HTTP services needed for this sort of protocolare GitHub and Facebook. It takes the help of a code for identity-verification and doesn’t ask for user credentials.
The three factors involved in OAuth 2.0 are the user, who is possessing the data to which the API wants the view or edit permission, the application, and the API.
Using this method for identity confirmation, it’s easy to interpret user data using different resources. It can be deployed for the verification and approval of web-based, mobile-based, and desktop-based applications/devices.
SAML stands for Security Assertion Markup Language and is a standard API process for identity confirmation using single-sign-on technology. It denotes confirming the user as per the provided details. Once the process completes and the user is verified, access to assorted applications/resources is granted. Presently, its SAML 20 version is running. It’s very much similar to the ID. Only user identity assessment is done with its help.
APIs, related to the app that you own, can only be controlled. This is why security API is focused on securing APIs that are exposed to a user, directly or indirectly. APIs, offered by other parties, that a user consumes are not a prime priority of Web API security as valuable insights related to such APIs can be gained by detailed analysis of outgoing API traffic.
One another key point to note here is that API security practice implementation involves multiple teams and systems. Network security principles like throttling, rate limiting, along with key data security concepts like identity-based security and analytics are a part of API security.
Based on the requirements, APIs can be used in various forms and styles. The chosen API style (REST, SOAP, GraphQL, gRPC, Websocket or Webhooks) decides how API security should be applied and implemented. Different API protocols, such as gRPC, GraphQL, and others, introduce their own unique security threats and attack vectors. For instance, GraphQL, due to its flexible querying capability, can be prone to resource exhaustion attacks if queries aren't properly validated and rate-limited. Each protocol, with its distinct architectural and operational nuances, requires specialized security considerations to address potential vulnerabilities and defend against tailored exploitation techniques.
Modern APIs primarily follow one of two architectural styles:
Both SOAP and REST utilize HTTP requests and Secure Sockets Layer (SSL) for encryption, but their security models differ significantly.
SOAP API Security
REST API Security
Summary: SOAP inherently integrates robust security measures, whereas REST APIs require additional security layers depending on their implementation.
GraphQL is a query language that enables clients to request specific data from an API in a structured format. Unlike traditional REST or SOAP approaches, GraphQL allows clients to define and retrieve exactly the information they need from one or multiple sources.
Since GraphQL permits highly complex queries, servers must be equipped to handle potential abuse. Without proper safeguards, excessive or malicious requests can overload the server, leading to performance issues or downtime.
Key Strategies for GraphQL Security
By implementing these measures, GraphQL APIs can be fortified against attacks and optimized for performance, minimizing risks associated with excessive or malicious queries.
Use Wallarm - a dependable and complete API security tool - designed to safeguard websites, microservices, and APIs from all sorts of dangers including OWASP API Top 10, bots, and application abuse easily.
The great part is Wallarm’s zero manual rule configuration and ultra-low false positives with Wallarm. Only reliable and real-time API security analysis and viable solutions will be offered. There is a free trial and demo offered for the convenience of the users. The tool is capable of protecting APIs of all sorts such as REST, SOAP.
Our seasoned API security team is skilled enough to secure APIs in any sort of environment. We have mastered the art and science of API security in AWS, GCP, Azure and IBM Cloud ecosystem, regardless of the type of deployment.
Subscribe for the latest news