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

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

Need

Properly set and secure the X-Permitted-Cross-Domain-Policies header

Context

  • Usage of TypeScript for type-checking and compiling JavaScript code
  • Usage of Express for building web applications and handling HTTP requests

Description

Non compliant code

        import express from 'express';

const app = express();

app.get('/', (req, res) => {
  // Vulnerable code: Insecure or unset X-Permitted-Cross-Domain-Policies header
  res.send('Hello World!');
});

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});

The vulnerability in the provided TypeScript code is the lack of an X-Permitted-Cross-Domain-Policies header or the insecure value set for the header.

The X-Permitted-Cross-Domain-Policies header is a security feature that allows a website to control how Adobe Flash or PDF documents interact with it. By setting this header to a secure value, such as "none", the website can prevent harmful requests from these documents.

In the given code, the vulnerable part is the absence of the X-Permitted-Cross-Domain-Policies header in the server response. This means that the application does not explicitly define the policy for cross-domain access from Adobe Flash or PDF documents.

Without setting a proper value for this header, the application is at risk of allowing potentially harmful requests from these documents. Attackers could exploit this vulnerability to perform cross-domain attacks or execute malicious actions through Adobe Flash or PDF files.

To mitigate this vulnerability, it is recommended to set the X-Permitted-Cross-Domain-Policies header to a secure value, such as "none", in the server responses. This will prevent any cross-domain access from Adobe Flash or PDF documents, unless specifically required by the application.

Steps

  • Install the `helmet` package by running `npm install helmet`.
  • Import the `helmet` package in your code by adding `import helmet from 'helmet';`.
  • Add the `helmet` middleware to your Express app by adding `app.use(helmet());` before defining your routes.
  • Set the `X-Permitted-Cross-Domain-Policies` header to `none` by adding `app.use(helmet.permittedCrossDomainPolicies({ permittedPolicies: 'none' }));` after adding the `helmet` middleware.
  • Restart your server and test if the `X-Permitted-Cross-Domain-Policies` header is now set to `none`.

Compliant code

        import express from 'express';
import helmet from 'helmet';

const app = express();

app.use(helmet());
app.use(helmet.permittedCrossDomainPolicies({ permittedPolicies: 'none' }));

app.get('/', (req, res) => {
  res.send('Hello World!');
});

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});

The fixed code is written in TypeScript and uses the Express framework along with the Helmet middleware to address the vulnerability related to insecure or unset HTTP headers.

First, the code imports the necessary modules, including express and helmet.

Then, an instance of the Express application is created using express().

The helmet() middleware is added to the application using app.use(helmet()). Helmet is a security middleware that helps set various HTTP headers to enhance security.

To specifically address the vulnerability, the code uses the helmet.permittedCrossDomainPolicies middleware. This middleware sets the X-Permitted-Cross-Domain-Policies header to a secure value. In this case, the value is set to 'none', which means no cross-domain policies are permitted.

Next, a route is defined for the root URL ( /). When a request is made to the root URL, the server responds with the message "Hello World!".

Finally, the application is set to listen on port 3000 using app.listen(3000). A console log message is also printed to indicate that the server is running on port 3000.

By using the helmet.permittedCrossDomainPolicies middleware and setting the permittedPolicies option to 'none', the code ensures that harmful requests from Adobe Flash or PDF documents are not allowed, effectively mitigating the vulnerability.

References