HTTP security response headers are additional protective measures sent by a web server to a browser when
a page is loaded. They instruct the browser on how to behave and help enhance security. These headers are
vital for preventing common web vulnerabilities such as Cross-Site Scripting (XSS), Clickjacking, and
information leakage.
During the assessment, we identified the following potentially insecure HTTP response header configuration:

Content Security Policy (CSP). This header is a security feature that allows to restrict the types and
sources of content that can be loaded in the context of the web application. The CSP header can also prevent
inline scripts from executing. As a result, in the case of a properly configured CSP header, the application will
have additional protection from various attacks, such as Cross-Site Scripting (XSS) or Clickjacking.
HTTP Strict Transport Security (HSTS). The HSTS header instructs the user's browser to always use
HTTPS when communicating with the website, even if the user types "http" in their browser's address bar. It
helps to prevent man-in-the-middle and protect websites against protocol downgrade attacks, cookie
hijacking, and other security vulnerabilities that can occur when website traffic is not encrypted.
X-Frame-Options. It improves the protection of web applications against clickjacking. It instructs the
browsers that do not support CSP whether the content can be displayed within frames.
X-Content-Type-Options. When this header is set, browsers have to rely only on the “Content-Type”
header to determine and interpret the MIME type of the response. It can protect against the so-called MIME
content-sniffing attacks when browsers use to determine the “real” content type of a response by looking at
the content itself instead of the response header’s content-type value. For example, suppose an attacker can
inject their malicious code (e.g., HTML, JavaScript) into the response. When the browser “sniffs” the content,
it will identify it as “text/html” and run the malicious payload.
InK Chronos 10.0 | Detailed Observations
13 CONFIDENTIAL – For internal use only
X-XSS-Protection. This header is a security feature that was designed for old browsers that do not support
CSP to protect the web application against reflected cross-site scripting (XSS) attacks. When enabled, the
browser's built-in XSS protection mechanism will try to detect and block certain types of attacks.
Referrer-Policy. It enables the browser to allow more strict data processing in the “Referrer” request header.
Without the “Referrer-Policy” HTTP header, application analytic data may be available for potential malicious
external resources.

Implication and Impact

Without enabling the security headers on the server side, the client’s browser will decide not to allow built-in
security measures. As a result, in case of misconfigured HTTP security headers, the application does not have
additional protection from various attacks.
However, note that these headers can provide some level of protection, but it is not a complete solution and
is not a substitute for properly escaping user input and other security measures.

Affected resources

• https://XXX.com
• https://XXX.com
• https://XXX.com/access-management/ui/
• https://XXX:444

Recommendations

Consider the following:
• Set the “Content Security Policy” HTTP header by implementing the following security decisions:
- Don’t use “unsafe-inline” to mitigate the inline script injection attacks.
- Don’t use “unsafe-eval” to prevent attackers from converting static text to executable JavaScript
code.
- Use the frame-ancestors directive to prevent Clickjacking attacks.
- Use the default-src directive set to none and allow those sites necessary for the application
functionality (allow-list-based approach).
- Use the script-src directive with trusted sources and hashes to mitigate the XSS attacks.
InK Chronos 10.0 | Detailed Observations
15 CONFIDENTIAL – For internal use only
- Use the object-src directive to disallow the injection of plugins that can execute JavaScript. (set
‘none’)
• Set the “Strict-Transport-Security” header to “max-age=31536000; includeSubDomains;” value
to mitigate the risk of Man-in-the-Middle (MitM) attacks.
• Set the “X-Content-Type-Options” to “nosniff” on the server side.
• Set the “X-Frame-Options” HTTP header with the SAMEORIGIN or DENY value as an additional
layer of security.
• Enable a web browser’s XSS filter by setting the “X-XSS-Protection” HTTP response header to “1;
mode=block”. This header can be considered “optional” but is advised if there is a chance that
the application might be visited using old browsers.
• Deploy the “Referrer-Policy” HTTP header with ‘no-refferer’ or ‘strict-origin-when-cross-origin’.
This header can be considered “optional” but is advised.

References

For more information, please visit the following URLs:
https://owasp.org/www-project-secure-headers/
https://www.w3.org/TR/CSP3/#csp-directives