[Add] Support for Feature-Policy header

[guilhem-fry]

New Features

• Add support for Feature-Policy header

Changes and Fixes

None

Refactors

None

Header options

Options are typed, which means all the directives will be suggested by IntelliSense. Configuration options are of the following structure:

const featurePolicyOptions = {
     directiveName: {
           none: boolean,
           all: boolean,
           self: boolean,
           origins: string[],
}

Example:

const featurePolicyOptions = {
    autoplay: {
        none: true,
    },
    camera: {
       self: true,
       origins: [
            "sub-domain1.com",
            "sub-domain2.com",
      ]
   }
}

Will return the following header:

Feature-Policy: autoplay 'none'; camera 'self' sub-domain1.com sub-domain2.com

[codecov[bot]]

Codecov Report

Merging #44 (9415569) into master (87f6129) will not change coverage. The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #44   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           13        14    +1     
  Lines          208       234   +26     
  Branches        85        95   +10     
=========================================
+ Hits           208       234   +26     

Impacted Files	Coverage Δ
src/index.ts	100.00% <ø> (ø)
src/rules/feature-policy.ts	100.00% <100.00%> (ø)
src/rules/index.ts	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 87f6129...9415569. Read the comment docs.

[jagaapple]

Thank you for your pull request😃 I'm busy, so I'll review this within two weeks.

This feature will be merged in v2.2.0.

[jagaapple]

@JackPoteYes Sorry for the late review. Ideally, I want Feature-Policy and Permissions-Policy will be set for backward compatibility if permissionPolicy property is set. However, in order to implement this, both of the headers should be possible to accept the same value in specification.

For example:

createSecureHeaders({ permissionsPolicy: xxx });
// => { "Feature-Policy": "xxx", "Permissions-Policy": "xxx" };

Also, I agree to support these headers because of your reasons, but basically, I don't want to support draft and unstable specifications to next-secure-headers. So I think featurePolicy option is not needed (use permissionsPolicy instead).

What do you think?

---

This feature will be released in v2.3.0.

[guilhem-fry]

Hi @jagaapple Pardon the delayed answer, your point of view on unstable specifications makes sense. I'll push a PR for permissionPolicy soon enough.

Thanks!