Operate with the confidence of security. View our commitment to keeping your data safe at rest and in transit for your cloud, hybrid, and on-premises deployments.
Operate with the confidence of security. View our commitment to keeping your data safe at rest and in transit for your cloud, hybrid, and on-premises deployments.
Credext cares about privacy – it is engrained in our culture and built into everything we do. Our comprehensive privacy program encompasses our roles as a business and as a service provider in the delivery of our products and services.
We are committed to policies that enable us and our customers to comply with our respective privacy obligations.
Realize extensive compliance in every region. View our comprehensive list of compliance standards and regulations.
Realize extensive compliance in every region. View our comprehensive list of compliance standards and regulations.
Stay informed on the status of your solutions. Access a transparent view of global product and service availability.
| Sr. No. | Vulnerability Identified | Solution |
|---|---|---|
| 1 | Check for SRI (Sub resource Integrity) support The third-party links/scripts (i.e. tags with src from another domain) don't have integrity attribute for the browser to confirm they didn't compromise. In case the third-party server is compromised, the content/behavior of the site will change. |
To prevent compromise of application, add to each thirdparty script/link element support to SRI(Subresource Integrity). Also, all the 3rd party scripts were fetched from local server only. |
| 2 | Encryption not Enforced During the application test, it was detected that the application uses an encrypted connection to protect sensitive information. However, it was possible to receive these resources over HTTP, which means that sensitive information may be sent unencrypted to the server and/or back to the user. |
It is recommended to enforce the use of an encrypted connection (e.g. SSL), and not allow access to sensitive information using unencrypted HTTP. HTTP request is redirected to HTTPS request. |
| 3 | Missing "Content-Security-Policy" header Insecure web server configuration. The CSP header is designed to modify the way browsers render page, and thus to protect from various cross–site injections. During testing, it is observed that the Content-SecurityPolicy response header is missing, which increases exposure to various cross-site injection attacks. |
It is recommended to configure your server to set the “ContentSecurity-Policy" header for following policies with secure values:
1. ‘default-src’ OR ‘script-src’ and ‘object – src’ 2. frame-ancestors, base-uri, form-action, plugin-types, report-uri, sandbox (As these directives don't use default-src as a fallback. Remember that failing to set them is the same as allowing anything 3. Application runs |
| 4 | Missing or insecure "X-Content-Type-Options" header The ‘X-Content-Type-Options’ header (with “nosniff” value) prevents browsers from ignoring the contenttype of a response. It was detected that the "X- ContentType-Options" response header is missing, which increases possibility to gather sensitive information about the web application such as usernames, passwords, machine name and/or sensitive file locations. |
Server was configured to use the “X-Content-Type-Options” header with “nosniff” value. |
| 5 | Missing or insecure "X-XSS-Protection" header The “X-XSS-Protection” header with value “1”forces the XSS filter (built into recent browsers) into Enable mode, even if disabled by the user. AppScan detected that the X-XSS-Protection response header is missing, which may allow possibility to gather sensitive information about the web application such as usernames, passwords, machine name and/or sensitive file locations. |
It is advised to configure server to use the “X-XSS- Protection” header with “1” value. |
| 6 | Missing or insecure HTTP Strict-Transport-Security Header HTTP Strict Transport Security (HSTS) is a mechanism which enables web servers to instruct their clients (e.g. browsers) to only use secure HTTPS connection and thus, protect secure (HTTPS) websites from being downgraded to non-secure HTTP. AppScan detected that the X-XSS-Protection response header is missing, which may allow possibility to gather sensitive information about the web application such as usernames, passwords, machine name and/or sensitive file locations. |
It is advised to implement the HTTP Strict-TransportSecurity policy with a long “max-age”. The value represents period of time during which the client should access the server in HTTPS only. |
| 7 | Unsafe Third Party Link It is observed that for third-party links, rel attribute in the link element is not set to “noopener noreferrer”. Such links with target = “_blank”attribute and no rel attribute allows linked page partial access to the linking page window object. This may be exploited for phishing attacks if the linked page is malicious. |
Added the attribute rel = “noopenner noreferrer” to each link element with target=”_blank”. |
| 8 | Client-Side (JavaScript) Cookie References Reference to cookies in the JavaScript was found. The worst case scenario for this attack depends on the context and role of the cookies that are created at the client side. |
Business and security logic for cookies from the client side was removed. The session management is now based upon login/ logout and VM agent heartbeat. |
| 9 | Older TLS version and SHA-1 cipher suites were detected It was observed that the site uses weak cipher suites and older TLS versions (TLS v1.0, TLS v 1.1). It is recommended to Change server's supported cipher suites and TLS versions. |
Use of TLS v1.2 or TLS v1.3 only. Also we have implemented Client Certificate validation. |
| 10 | Use of Secure and HttpOnly Cookies The web application does not mark its session cookie(s)/access token(s) with “secure” and "HttpOnly" attribute. |
Session cookie(s)/Access token(s) marked with “secure” and "HttpOnly" attribute. |