Skip to main content

Remote File Inclusion


Prevention of remote file inclusion attacks


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


Non compliant code

import play.api.mvc._

object Application extends Controller {
def index = Action { implicit request =>
val fileToInclude = request.getQueryString("file").getOrElse("default.html")
val content =

In the above code, we have a simple Play Framework controller that has an index action. This action retrieves a file name from the query string parameter "file". If no file name is provided, it defaults to "default.html".

The vulnerability lies in the line where it uses to read the content of the file. Here, the fileToInclude can be any URL, not just a local file path. This means that an attacker could potentially provide a URL to a remote file that contains malicious code. The application would then load and execute this code, which could lead to serious security breaches such as data leakage or remote command execution.

This is a classic example of a Remote File Inclusion (RFI) vulnerability. The application is not validating or sanitizing the input it receives in the "file" query parameter, and is directly using it to load content from a URL. This allows an attacker to make the application load content from any URL they choose.


  • Validate the input: Ensure that the 'file' parameter is a valid file path or URL.
  • Restrict access to local files: If the 'file' parameter is a local file path, restrict access to only allowed directories or files.
  • Sanitize the input: Remove any special characters or escape sequences from the 'file' parameter to prevent directory traversal attacks.
  • Use a whitelist approach: Maintain a whitelist of allowed file paths or URLs and only allow loading files from those sources.
  • Implement server-side file validation: Check the file's content type or extension to ensure it matches the expected type.
  • Implement server-side file content validation: Scan the file for malicious content before processing or executing it.
  • Use secure file loading methods: Instead of directly loading files using '', use safer methods that handle remote file inclusion securely.
  • Implement access controls: Restrict access to the file inclusion functionality to authorized users or roles.
  • Regularly update and patch dependencies: Keep the Play framework and other dependencies up to date to benefit from security fixes and improvements.
  • Perform security testing: Regularly test the application for vulnerabilities, including remote file inclusion, using tools like static code analysis and penetration testing.

Compliant code

import play.api.mvc._

object Application extends Controller {
private val allowedFiles = List("default.html") // Whitelist of allowed files

def index = Action { implicit request =>
val fileToInclude = request.getQueryString("file").getOrElse("default.html")

// Validate the input and restrict access to local files
if (!allowedFiles.contains(fileToInclude)) {
BadRequest("Invalid file request")
} else {
try {
val url = new URL(fileToInclude)
// Use secure file loading methods
val content =
} catch {
case _: MalformedURLException => BadRequest("Invalid URL")

The updated code includes several measures to prevent remote file inclusion attacks:

  1. Input Validation: The 'file' parameter is checked against a whitelist of allowed files (allowedFiles). If the requested file is not in this list, a "Bad Request" response is returned.

  2. Restricting Access to Local Files: The whitelist approach restricts access to only the files that are explicitly allowed. This prevents an attacker from accessing arbitrary files on the server.

  3. Secure File Loading: The code uses to load the file from a URL. This method throws a MalformedURLException if the URL is not valid, which is caught and handled by returning a "Bad Request" response.

  4. Error Handling: If any error occurs while processing the request (such as a malformed URL), a "Bad Request" response is returned. This prevents the server from returning sensitive information in error messages.

Please note that this is a basic solution and might need to be adjusted based on your specific use case and security requirements. For example, you might want to add more sophisticated input sanitization, implement server-side file validation, or restrict access to the file inclusion functionality to authorized users.