Web Application Security - HTTP Security Headers

A bit of the same as HTTP Security Headers just for the VPN server

We have the following risk alerts from securityscorecard.com regarding Pritunl VPN webUI:

  • Site Does Not Use Best Practices Against Embedding of Malicious Content
  • Content Security Policy Contains Broad Directives

So let’s help the community by setting the same standard at the source

Site Does Not Use Best Practices Against Embedding of Malicious Content

What we are triggered on, we need a value for the “X-Frame-Options” see Recommendations for guidelines

Description

The X-Frame-Options is an HTTP header that controls whether a web page can be displayed within an iframe. It prevents clickjacking attacks by allowing webmasters to specify if their site can be embedded in frames on other domains. This header helps protect against unauthorized framing of a website’s content, enhancing the overall security of web applications.

Risk

Not using X-Frame-Options means greater vulnerability to clickjacking attacks. Without this security header, web pages are susceptible to being embedded within iframes on other domains without explicit permission. Clickjacking involves maliciously presenting a framed web page to deceive users into interacting with altered content. This can lead to various security threats, including unauthorized access, data theft, or unintended user actions on legitimate websites.

Recommendations

  • Implement X-Frame-Options with the ‘SAMEORIGIN’ directive to allow framing only from the same origin.
  • Include the Content Security Policy (CSP) directive frame-ancestors “self” to allow framing from the same origin.
  • Consider using frame-ancestors “none” to disallow all framing.

Content Security Policy Contains Broad Directives

What we are triggered on, we have set the value “upgrade-insecure-requests” but that is to broad

Description

A Content Security Policy (CSP) is a security standard implemented by web browsers to guard against Cross-Site Scripting (XSS) attacks. This policy is defined by HTTP headers sent by the web server and instructs the browser on which resources are allowed to load for a particular web page. By specifying trusted domains for script execution, plug-ins, and other resources, a CSP helps prevent malicious code injection and enhances the overall security of web applications. It acts as a crucial layer of defense, ensuring that only authorized sources are permitted.

Risk

When a Content Security Policy (CSP) is configured with overly broad settings, it opens the door to potential security vulnerabilities. In such cases, directives like ‘script-src’, ‘object-src’, or ‘default-src’ may be defined with permissive values like ‘http:’, ‘’, or ‘http://’. This allows the browser to load resources from a wide range of sources, including potentially malicious domains. This lack of specificity compromises the intended protection against Cross-Site Scripting (XSS) attacks as adversaries could inject and execute malicious scripts.

Recommendations

  • Specify exact domains for trusted sources in directives like ‘script-src’ and ‘style-src’ instead of using overly broad values like ‘’, ‘http:’, or ‘http://’.
  • Minimize the use of wildcard characters and avoid permissive settings to enhance the precision of the Content Security Policy (CSP).
  • Utilize HTTPS to secure connections and minimize risks associated with loading resources from untrusted or potentially unsecure sources.
  • Implement nonce or hash values for inline scripts to maintain security while allowing specific exceptions.
  • Regularly review and update the CSP configuration to adapt to changes in the application and address emerging security concerns.
  • Test and monitor the CSP to ensure its effectiveness, identifying and addressing any unexpected behavior or attempts to bypass security measures.
  • Educate development teams on the importance of a well-defined and specific CSP to strengthen overall web security.

The X-Frame-Options is already set to DENY. There’s a lot of protection already in place for XSS scripting including a CSRF Token included in every request. There’s no plans on changing any of the headers currently.

Hi @zach

About the X-Frame-Options, you are right, i should have looked at the source, it looks like our HAProxy is modifying that header, we will get that changed, sorry.

But about the CSRF Token included in every request, i do not see it in the request, can you help me to pinpoint where it is, is it set in the session cookie, i can see it change on every request, i was looking for the CSRF Token in the header or form data. It looks like that Nessus is not able to detect CSRF Tokens used that way.

I will ask the the Nessus result, and get back in this thread.

It’s in the response headers, the web client sets it in every authenticated API request sent to the server. This wouldn’t show up on any scanners, those are only going to look at the headers received at the login page.