Permissions Policy

Enabled Decide what API's the site can access.


Permissions Policy provides mechanisms for web developers to explicitly declare what functionality can and cannot be used on a web site. You define a set of "policies" that restrict what APIs the site's code can access or modify the browser's default behavior for certain features.

ℹ Read more about this header here.

Usage

This header is enabled by default but you can change its behavior like following.

export default defineNuxtConfig({  // Global  security: {    headers: {      permissionsPolicy: <OPTIONS>,    },  },  // Per route  routeRules: {    '/custom-route': {      security: {        headers: {          permissionsPolicy: <OPTIONS>,        },      },    }  }})

You can also disable this header by setting permissionsPolicy: false. To disable certain API completely, set its value to empty array like:

export default defineNuxtConfig({  security: {    headers: {      permissionsPolicy: {        'camera': [] // This will block usage of camera by this website      },    },  },})

Default value

By default, Nuxt Security will set following value for this header.

Permissions-Policy: camera=(), display-capture=(), fullscreen=(), geolocation=(), microphone=();

Available values

The permissionsPolicy header can be configured with following values.

permissionsPolicy: {  'camera'?: string[] | string;  'display-capture'?: string[] | string;  'fullscreen'?: string[] | string;  'geolocation'?: string[] | string;  'microphone'?: string[] | string;  'web-share'?: string[] | string;} | false

And several 🧪 Experimental API's.

type PermissionsPolicyValue = {  'accelerometer'?: string[] | string;  'ambient-light-sensor'?: string[] | string;  'autoplay'?: string[] | string;  'battery'?: string[] | string;  'document-domain'?: string[] | string;  'encrypted-media'?: string[] | string;  'execution-while-not-rendered'?: string[] | string;  'execution-while-out-of-viewport'?: string[] | string;  'gamepad'?: string[] | string;  'gyroscope'?: string[] | string;  'hid'?: string[] | string;  'idle-detection'?: string[] | string;  'local-fonts'?: string[] | string;  'magnetometer'?: string[] | string;  'midi'?: string[] | string;  'payment'?: string[] | string;  'picture-in-picture'?: string[] | string;  'publickey-credentials-get'?: string[] | string;  'screen-wake-lock'?: string[] | string;  'serial'?: string[] | string;  'speaker-selection'?: string[] | string;  'usb'?: string[] | string;  'xr-spatial-tracking'?: string[] | string;}
ℹ Read more about all available APIs here.

Array and String syntaxes

Per-route configuration

All Permissions Policy options can be defined on a per-route level.

export default defineNuxtConfig({  // Global  security: {    headers: {      permissionsPolicy: {        'geolocation': [] // By default, geolocation disabled      }    }  }  // Per route  routeRules: {    '/some-prefix/**': {      security: {        headers: {          permissionsPolicy: {            'geolocation': ['self'] // Self origin allowed for geolocation on all routes beginning with /some-prefix/          }        }      }    },    '/some-prefix/some-route/**': {      security: {        headers: {          permissionsPolicy: { // With array syntax : additive            'geolocation': ['https://*.example.com']  // Self AND *.example.com allowed for routes beginning with /some-prefix/some-route/          }        }      }    },    '/some-prefix/some-route/some-page': {      security: {        headers: {          contentSecurityPolicy: { // With string syntax : substitutive            'geolocation': 'self'  // ONLY self allowed on /some-prefix/some-route/some-page          }        }      }    }  }})

Nuxt Security resolves the permissionsPolicy options using the native Nitro router strategy:

  • Additive merging with the array syntax: If you write your rules with the array syntax (e.g. "geolocation": ["self"]), the new route policies will be added to the policies defined for higher-level routes. Use this strategy if you need to add specific policy values to your route without deleting the existing ones.
  • Substitutive merging with the string syntax: If you write your rules with the string syntax (e.g. "geolocation": "self"), the new route policies will be substituted to the policies defined for higher-level routes. Use this strategy if you need to delete existing policies before setting your specific route policies.