Skip to main content

Insecure or unset HTTP headers - X-Permitted-Cross-Domain-Policies

Need

Enforcement of secure and properly configured X-Permitted-Cross-Domain-Policies header

Context

  • Usage of Scala for building scalable and high-performance applications
  • Usage of play.api.mvc for handling HTTP requests in Play Framework

Description

Non compliant code

import play.api.mvc._

class ApplicationController extends Controller {
def index = Action { request =>
Ok("Hello, World!")
}
}

This is a simple Scala controller using the Play framework. The function index responds to HTTP requests with "Hello, World!". However, this code is vulnerable because it does not include the X-Permitted-Cross-Domain-Policies HTTP header in its response.

The X-Permitted-Cross-Domain-Policies header is used to define the policy for handling cross-domain requests in Adobe products. If this header is missing or set to an insecure value, it can potentially allow unauthorized access from other domains, leading to cross-domain attacks.

In this code, the absence of this header means that there's no policy set for handling cross-domain requests, leaving the application vulnerable to potential cross-domain attacks.

Steps

  • Add the X-Permitted-Cross-Domain-Policies header to the response.
  • Set the value of the X-Permitted-Cross-Domain-Policies header to a secure value, such as 'none' or 'master-only'.
  • Ensure that the X-Permitted-Cross-Domain-Policies header is set for all relevant routes and responses in the application.

Compliant code

import play.api.mvc._

class ApplicationController extends Controller {
def index = Action { request =>
Ok("Hello, World!").withHeaders("X-Permitted-Cross-Domain-Policies" -> "none")
}
}

The above code fixes the vulnerability by adding the X-Permitted-Cross-Domain-Policies header to the HTTP response. This header is used to provide a policy file that specifies the domains that are permitted to make cross-domain requests.

In the original code, the X-Permitted-Cross-Domain-Policies header was not set, which could potentially allow unauthorized cross-domain requests. This could lead to various security issues, such as data leakage or unauthorized actions.

The fixed code sets the X-Permitted-Cross-Domain-Policies header to none, which means that no domain is allowed to make cross-domain requests. This is the most secure setting, but it may need to be adjusted depending on the needs of the application.

The withHeaders method is used to add the header to the response. This method takes a sequence of pairs, where each pair consists of a header name and a header value. In this case, the header name is X-Permitted-Cross-Domain-Policies and the header value is none.

It's important to note that this header should be set for all relevant routes and responses in the application, not just for the index action. This ensures that the security policy is applied consistently throughout the application.

References