Vulnerabilities

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 (127.0.0.1) 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).

Service uses basic authentication

Query parameter contains sensitive data

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.

• 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.