• 22 Feb 2022
  • 8 Minutes to read


Vulnerabilities are security gaps in your API definition that threat actors may exploit to attack your API infrastructure. The Vulnerability-management life cycle process helps in identifying and remediating security risks before they can be exploited by threat actors. The life cycle includes being aware of all the assets in your organization, carrying out a vulnerability scan, assessing the risks, and taking action to mitigate those risks. 

Traceable identifies assets or the API endpoints and services in your environment through the discovery process. After Traceable discovers the API endpoints, it does a vulnerability scan on APIs and the associated services and displays them in the Vulnerability section.

 Vulnerability-management life cycle

You can carry out a risk assessment of the API endpoint based on the vulnerabilities identified. Traceable also provides possible remediation. Once you have applied the remediation, verify that your API is secure. Traceable continuously monitors the API endpoints that you have remediated and secured. It reports a vulnerability if it finds any in the future, hence continuous monitoring is essential.

Vulnerability summary

The Vulnerability page displays a summary of vulnerabilities for both External and Internal APIs. The summary page shows all the services that are associated with the vulnerable APIs. Multiple APIs may be associated with a single service. The following screenshot shows the vulnerability summaries page. When you click on a service, Traceable displays the type of vulnerability associated with that service. If a known vulnerability is not resolved, it may lead to an attack on your API ecosystem.


The vulnerability feature is currently in a beta state.

The Vulnerabilities dashboard provides the following information:


The vulnerabilities section shows:

  • New vulnerable APIs in the last 24-hours.
  • The number of services with vulnerabilities.
  • The total number of vulnerable APIs since you created your account with Traceable.


The status section shows:

  • The total number of open vulnerabilities since you created your account with Traceable.
  • Number of resolved, under review, and ignored vulnerabilities in the last 24-hours. 

Vulnerability types

The vulnerability type sections shows a distribution of type of vulnerabilities identified by Traceable since the account creation. 

Vulnerability details

You can view the details about a vulnerability associated with a service by clicking on the service name as shown in the screenshot below. The vulnerability detail window shows the type of vulnerability detected for the service and the associated APIs. The following screenshot shows that the service frontend has 9 APIs associated with it and all are in the Open state. You can change the state of the vulnerability by choosing one of the option from the drop-down window. For more information on each state, see Vulnerability status.

Types of vulnerabilities

Traceable, based on its continuous learning, detects the following types of vulnerabilities:

  • API parameter contains URL
  • Basic authentication is used
  • Query parameter contains sensitive data
  • Lack of encryption
  • Java serialization objects
  • X-Content-Type-Options without nosniff
  • Strict-Transport-Security Header not set
  • Persistent Cookie contains Sensitive Data

Vulnerability status

You can manually change the state of the detected vulnerability to any of the following:

  • Open - Traceable has detected a vulnerability.
  • Under review - Vulnerability has been acknowledged. You are taking steps to close the vulnerability.
  • Resolved - Vulnerability has been closed. Traceable keeps monitoring the asset (API endpoint or service) even after you have marked it as resolved. If Traceable finds new vulnerabilities, the vulnerability is automatically moved to an Open state for you to review and resolve. 
  • Ignored - Move the vulnerability to Ignored state when you do not want Traceable to report it. If Traceable keeps seeing an Ignored vulnerability, it does not move it to open state.

Vulnerability description

The following table describes the reason for a vulnerability and the mitigation steps you can take.


API parameter contains URL

Server-Side Request Forgery (also known as SSRF) is an attack vector that allows an attacker to masquerade as the Server-Side application and perform requests to an arbitrary domain of his choosing. In typical SSRF attacks, the attacker usually targets: 

  1. accessing services available through the loopback interface ( of the exploited server 
  2. Internal systems behind firewalls that are not accessible from the external network
  3. External third-party systems
  4. To access and steal credentials and access tokens from metadata services (for example, AWS Instance Metadata Service, Azure Instance Metadata Service, GCP metadata server).
Where possible, do not let users specify URLs for outgoing requests issued by your server. In cases where dynamic URLs are required, use a list of accepted URLs and do not accept other URLs. Use internal DNS resolvers to resolve domains first and reject external domains resolving to private IPs and metadata services.

Service uses basic authentication

Basic authentication sends credentials in base64 encoding (which can be easily converted to plaintext). If the website/API does not implement HSTS, the credentials are open to being captured via MITM. The password is cached by the browser, at a minimum for the length of the window/process which can silently be leveraged by session-related exploits, notably CSRF. Further, the password may be stored permanently in the browser based on user preferences which could be compromised on a shared device.Avoid using HTTP Basic Authentication. If using Basic Authentication is not preventable, ensure HSTS is implemented to safeguard against MITM. In some cases, exploiting vulnerable HTTP basic authentication might only grant an attacker access to a seemingly uninteresting page. However, in addition to providing a further attack surface, the credentials exposed in this way might be reused in other, more confidential contexts. Ensure to limit access for the resources exposed via basic authentication and the credentials are not shared for other authentication mechanisms.

Query parameter contains sensitive data

The query string can be saved in the browser's history or cache, passed through Referrers to other websites, stored in weblogs, or otherwise recorded in other sources. If the query string contains sensitive information such as session identifiers, then attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes or launch further attacks. Simply using HTTPS does not resolve this vulnerability. Vulnerabilities that result due to the disclosure of sensitive data especially credentials can result in compromises that are extremely difficult to investigate due to obscured audit trails.Do not use query parameters to pass sensitive data. Use POST methods for such requests and pass the sensitive data in the request body. Some sensitive data like session identifiers or authorization tokens can be passed via cookies or headers.

Lack of encryption

An attacker with the ability to intercept a user's network traffic can read and modify any messages that are exchanged with the server. This allows the attacker to see passwords in clear text, modify the appearance of your website, redirect the user to other web pages or steal session information. Therefore no message sent to the server remains confidential and its integrity cannot be guaranteed. Lack of encryption also reflects in modern browsers flagging such hosts and leading to bad user experience, loss of users trust, or security.

Use a vetted encryption scheme that is currently considered to be strong by experts in the field such as TLS 1.2 or higher.
Java serialization objectsAPI endpoint accepts Serialized Java Objects as input. Applications that accept Serialized Java objects are likely to be vulnerable, even if a framework or library is responsible and not your code. Input that is not trusted cannot be enforced to be well formed. Malformed input could be exploited to abuse application logic, execute arbitrary code, or deny service, when deserialized.It is imperative to avoid serialized inputs from sources that are not trusted. However, when this is not possible, there are various safeguards that can be implemented to reduce the risks. For example:
  • If the inputs are known to be from a trusted source, a deserialization library could be used which provides a cryptographic framework to seal serialized data.
  • Use a whitelist rather than denylist approach to serialization. 
  • Explicitly define final readObject() to prevent deserialization. 
  • When deserializing data, populate a new object rather than just deserializing. This will ensure data flows through safe input validation and that the functions are safe. Override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. Libraries like SerialKiller can be used.

X-Content-Type-Options without nosniff

MIME type sniffing is a standard functionality in browsers to find an appropriate way to render data where the HTTP headers sent by the server are either inconclusive or missing. The problem arises when the attacker can control the content received by the browser even in minute ways and carry out attacks like XSS (Cross-site Scripting) by manipulating the content in a way to be misinterpreted by the browser with MIME type sniffing.

When serving resources, make sure to send the content-type header that appropriately matches the resource being served. Add the X-Content-Type-Options header with a value nosniff to inform the browser to trust what the server has sent is the correct content-type, and not attempt to sniff the any content-type.

Strict-Transport-Security Header not set

HTTP Strict Transport Security (HSTS) is a server web security policy mechanism declaring that complying user agents (such as a web browser) are to interact with the server only via secure (HTTPS) connections. The remote HTTPS server is not enforcing HTTP Strict Transport Security (HSTS). The lack of HSTS allows downgrade attacks, SSL-stripping, man-in-the-middle attacks, and weakens cookie-hijacking protections.

Configure the server to use HSTS header on all HTTPS resources. The max-age directive's value is recommended to be greater than 10368000 seconds (120-days) and ideally as 31536000 seconds (one year).

Persistent Cookie contains Sensitive Data

Browsers normally deletes the session cookies when the user closes the browser. Unlike other cookies, session cookies do not have an expiration date assigned to them,
which is how the browser knows to treat them as session cookies. Instead of expiring the cookie when the browser is closed as session cookies expire, a persistent cookie expires at a specific date or after a specific length of time. 

If a Persistent Cookie contains sensitive data, as it does not expire with the session it introduces security and privacy risk. This means that for the cookie's entire lifespan (which can be as long or as short as its creators want), its information will be transmitted to the server every time the user visits the resource that it belongs to. If the attacker gets access to the hard drive, they can extract the sensitive data from the browser's cookie jar.

Do not store sensitive information in persistent cookies. Use session cookies if the application requires the storage of sensitive information in the browser. Modern browsers provide storage interfaces to store data for a particular domain's session or local storage which should be leveraged.

Was this article helpful?